# W3C Solid Community Group: Weekly

* Date: 2022-10-26T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* [Matthias Evering(ewingson)](https://solidweb.me/testpro/)
* [Matthieu Bosquet](https://id.inrupt.com/matthieu)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* [Ted Thibodeau](https://github.com/TallTed) (he/him) (OpenLink Software)
* Jeff Waters
* [Wouter Termont](https://github.com/woutermont) (Digita)
* [Kjetil Kjernsmo](http://kjetil.kjernsmo.net/)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* [Stijn Taelemans](https://github.com/lem-onade) (Digita)
* [Henry Story](https://bblfish.net/people/card#me) (bblfish)
* Arthur Joppart (Digita)
* Laurens Debackere (Flemish Government)
* [Tom Haegemans](https://use.id/tom) - [e-mail] (Digita)
* Michiel de Jong
* Abel Van den Briel
* Sindhu
* Bob Bishop

---

## Announcements

### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Join queue to talk.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
* If this is your first time, welcome! please introduce yourself.

### Scribes
* Virginia
* Wouter
* Matthieu

### Introductions
* Matthias: Maintains an NSS + CSS instance.
* Sindhu: Working on a project dealing with personal data. National Science Foundation (US). Consumer side. Looking into it from the user's perspective. Background in data architecture for big companies. Looking into Solid as a potential for ??? or data warehousing. Need use cases.
* SC: https://github.com/solid/user-stories , https://solid.github.io/authorization-panel/authorization-ucr/ , https://solid.github.io/notifications-panel/notifications-ucr , ... there are also use cases mentioned in https://github.com/solid/specification
* BB: Bob Bishop from Michigan. Solving a problem in medical imaging. In VS in 90s, film-based acquisition of xrays. We created a cloud-based system, a peer-to-peer environment with centralized environment in ???. I became interested in orthopedics, and realised xrays were the diagnostics of ????. In Michigan, for example, the system has an equal right to maintain the data as the patient. The permissioning environment about this combined ownership is where the complexity arises, and this is the trigger to watch Solid. I'm an entrepreneur, not a computer scientist, but I'm trying to accomplish an environment where patients can maintain their own data, and frankly I have not seen from the community to predominant users in this segment. Has there been a system to support this for my sister, she could have carried with her the records of the treatment with her over moves. Tke dilemma for me is ... immutable keys that cant be replicated is like throwing your data in a black hole when you lose you keys. Any ides to make this real would be wonderful.
* Sindhu: I had a lot of experience with medical records, which were heavily regulated and jointly owned (provider+patient), which makes them a very good use case. ??? I think attempts have largely failed, so I think they are a great use cases (after financial records). We have to prioritise use cases, and financial records were one of them.
* BB: In a way I don't envision a difference between financial and medical records. 20% of GDP in US comes from health care. Every case thereoef gets a unique code which makes it billable. This is where Blockhcain could come op. WHEALTH, a combination of wealth and health. They're inexplicable in many aspects. They idea of maintaining... On the technical side, folks are saying they want nothing to do with my medical records.
* SC: We should mind the time.

---

## Topics

* SC: Today's topics are intended for awareness and build engagement as opposed to solving technical details here.

### Agenda and Minutes

* SC: Agenda is typically PRd at https://github.com/solid/specification/
* SC: Reviews on the PR are welcome.
* SC: Previous meeting's minutes are at https://github.com/solid/specification/blob/main/meetings/2022-10-19.md and you can always find prior minutes at https://github.com/solid/specification/blob/main/meetings/.
* SC: Please note that unless there is a decision to change the meeting datetime, it is always on UTC time (and daylight savings time is not observed, as it stands).

#### Authorization focused meetings
URL: https://github.com/solid/authorization-panel/issues/325

* SC: [This](https://github.com/solid/authorization-panel/issues/325) is a call to organise a new meeting slot with specific items to work on.

### Current and Former Editors of Work Items
URL: https://solidproject.org/TR/
* SC: Revisit Work Items to see what needs updating. Here is one:

#### Update authorization-ucr's editors
URL: https://github.com/solid/authorization-panel/issues/309

* SC: MB showed interest and commitment. It'd be great to have another 1 or 2 co-editors. Please show your interest in the issue.

### URI persistence, ownership, and representation management
URL: https://github.com/solid/specification/issues/462

* SC: Would like to get a sense. Where to draw the line (for now). High-level view.
* SC: Certainly technically possible. This particular discussion is not about how.
* HS: I've implemented parts of Memento in [Reactive Solid](https://github.com/co-operating-systems/Reactive-SoLiD). There are it seems to me two parts to this problem: 1) the server needs to say it can support some of these features, and 2) a way for client to ask to set those features. This is similar to access control: A server can specify that it supports setting ACLs via a link header, allowing the client to set it by writing an access control rule. It seems we have the same here: we need some way for the serverto say this container can do memento, and a way for the client then who wants to and is allowed to set that feature. This needs to be solved in a generic feature.
* SC: Depends on what "metadata" we refer to. Response metadata or auxiliary resource that is referring to the primary resource (description resource metadata). Could be the metadata in response headers. LDP has interaction models, link with relation in header
* HS: An extra example is one that came up recently: say you need a resource to have a certain time to live - the server cannot really know when the next update should be. It is likely this is somthing the client writing the resource will know best. Is this a resource with a day's time to live, or a year? We have a pattern similar to access control. You always have the server be as generic as possible. All a server can do is specify its abilities somewhere allowing a client to read the servers abilities.
* SC: Example: do we want to allow an client to instruct a server to set redirect rules. People change WebIDs, resource move, and that comes up... if you want to be able to move stuff. Is this within the scope of the protocol? Def in the scope of web architecture. The alternative is: we don't want clients to have that type of control, the server should have control of those resources, whether through a link in the headers or redirects.
* HS: Everything normal servers (e.g. Apache) can do, we should be able to do too. Every thing you can set by hand on the server should be available on LDP/Solid. Not every server will be able to implement all these features, so you need the server to be able to declare what a client is allowed to do. We should come up with a general solution to edit features so that once the protocol is set the rest can be done using ontologies (i.e. specific vocabularies).
* MB: I agree with HS, it would be interesting to be able to define redirection rules, but it should be taken care in a different specification, not the Solid protocol. Maybe a new kind of auxiliary resource.
* WT: +1
* TH: No opinion, but in our experience we are looking into account deletion, and looking into how to handle. We need to make sure that same URI cannot be created again. We plan to show 404.
* SC: Follow up on some issues around marking resources as Gone (pointers?)
* KK: Aux resource would be a good idea. We should survey the different properties of aux resources. For example, access control resource has its lifecycle tied to resource. In case of audit resource, not tied to lifecycle. Redirect resources, not tied. It is possible to delete, and audit resources are read/append only. Some things are properties of certain aux resources: generic properties and make it easy for users to design and specify.
* WT: +1
* SC: https://github.com/solid/specification/issues/306 is one issue that looks into Kjetil's comment.
* TT: This seems another reinvention instead of modeling what is already deployed and works well. Apache web server has evolved in controls and attributes that people can set or delegate.
* TT: `.htaccess` files are (relatively) well understood (by some number of acolytes). For example, `w3id` has a wide range of redirection rules, from simple global substitution to very fine-grained logical processes running over request URIs. A temporary redirect is a very different thing to a permanent redirect and it has implications on the rippling effects of setting such rules. User names are not generally perpetual, but that's largely how we're treating WebIDs. In similar kinds of services where people have chosen "vanity" usernames/handles, they get some period of inactivity before the username is "freed up" for someone else to use. Permanently retiring WebID URIs upon first use is likely to be problematic in the long term. If a WebID is based on a serial number, that is different. But permanently consuming a handle just by being the first one to do so... it will not happen often, but some users will grab whole ranges of URIs, setting redirects that could end up rendering a whole the service useless and vulnerable to DDOS. (Consider domain squatting as a similar/related issue.)
* SC: To clarify, I meant whether to allow setting Redirects in the first place.
* SC: There are some proposals linked from the issue.
* MdJ: The https://github.com/pdsinterop/solid-migrator project by Muze is also relevant here.

### Client Errors

* SC: HTTP affords a few ways to communicate client errors; status code, status message, response headers and body.
* SC: This is related to Constraints and Problem Details: https://solidproject.org/ED/protocol#constraints-problem-details

#### Add Inbox Discovery on Client Error
URL: https://github.com/solid/specification/pull/253

* SC: This has a long history / grounded on issues and implementation experience going back 2017 (if not much earlier).
* SC: The idea that the recipient of the error can reach out to the originator of the data (?)
* SC: Requesting access is another use case for this.
* SC: General problem is structured error messages.

#### Structured Error Messages
URL: https://github.com/solid/specification/issues/28
* SC: Rough agreement that error messages should be in RDF and client can find people you can to request access for, or something else. Specific consideration is: can we do that in RDF? Do we need a data model to have messages be useful for clients? Example 403 can be many different reasons. Can we be more explicit on what the error is? Some security considerations... how much to reveal about the error. Key thing is having a model to provide that.
* SC: If needed to, familiarize yourself with the issues/PRs.

### Use IRIs for resource identification
URL: https://github.com/solid/specification/issues/347
* SC: Currently Solid protocol expresses things using URIs, partly because of some of the req starting off ??? not necessarily from an RDF perspective. This issue is about changing the focus to whether IRIs can be requested, and whether they would be mapped to URIs.
* SC: Example: you need to give access to someone's WebID. Request comes in, should the server give rights to the IRI version or the URI version in the authorization rule, and would the server be doing the mapping between the two. In RDF it'd be one or the opther. Would server take request as is, or do the mapping. If one or the other, they might bnot match unless there is a mapping. We need wider insight from a bigger circle re: security considerations.
* WT: Elaborate on example. Why such a transition be necessary if client asks ??? request containing an IRI why should there be a translation, if it is just an identifier at that point?
* SC: When you make an HTTP request, what's going over the wire is just a URI. If it was originally an IRI the client will map it to a URI, so the server is getting a URI. Question is for the server, do I convert to IRI, or take as is? If as is, and put it in an access control resource, how would that be interoperable? Solid protocol doesn't specify whether that should occur. One server might do the mapping, another server might not. There would be a mismatch.
* WT: That scenario would be an unlimited set of scenarios, because most identifiers (IRIs or not) are sufficient. Only when an IRI needs to pass in HTTP that it has to be translated.
* HS: I've found the inbox discovery from earlier more real. Sounds like you need to gather use cases with problems that would arise. URIs are ment to be just IRIs encoded in a particular way. Doesn't make a different how that is encoded locally.
* SC: If one server find a match they might grant access. Same rule used on a different server, they might not match.
* HS: Server should be consistent.
* WT: Authorization example: if my ACL I have IRI of some agent, a request to that resource bound by that ACL would contain an IRI, not a URI because it is not part of the HTTP protocol, it is in the body.
* SC: This whole issues is about hashing that out. Check assumptions to see if we are working with the same assumptions. Issue is here: https://github.com/solid/web-access-control-spec/issues/93

### Trust between owners on same origin with multiple storages
URL: https://github.com/solid/specification/pull/290

### Add license document
URL: https://github.com/solid/specification/pull/412

### Social profile as discovery mechanism
URL: https://github.com/solid/webid-profile/issues/65

* SC: Topic proposed by VB.
* VB: Thanks to WT for opening this discussion. Comments are welcome.
* VB: Is profile data different from other data and should it be discoverable in one particular resource?