Skip to content

Latest commit

 

History

History
151 lines (110 loc) · 14.5 KB

2022-10-26.md

File metadata and controls

151 lines (110 loc) · 14.5 KB

W3C Solid Community Group: Weekly

Present

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

Scribes

  • Virginia Balseiro
  • Wouter Termont
  • Matthieu Bosquet

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 X-rays. We created a cloud-based system, a peer-to-peer environment with centralized environment in ???. I became interested in orthopedics, and realised X-rays were the diagnostics of ????. In Michigan, for example, the system has an equal right to maintain the data as the patient. The permissions 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. Had 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. The dilemma for me is ... immutable keys that can't be replicated is like throwing your data in a black hole when you lose your keys. Any ideas 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 thereof gets a unique code which makes it billable. This is where Blockchain could come op. WHEALTH, a combination of wealth and health. They're inexplicable in many aspects. The 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 to build awareness and engagement as opposed to solving technical details.

Agenda and Minutes

Authorization focused meetings

URL: solid/authorization-panel#325

  • SC: This 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: solid/authorization-panel#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: #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. It seems to me there are 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 server to say this container can do Memento, and a way for the client who wants to and is allowed to then 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 something 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 server's abilities.
  • SC: Example: do we want to allow a 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? Definitely 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. Everything 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 of 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: #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 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 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

Add Inbox Discovery on Client Error

URL: #253

  • SC: This has a long history / grounded on issues and implementation experience going back to 2017 (if not much earlier).
  • SC: The idea is 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: #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? For example, 403 can be for 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: #347

  • SC: Currently Solid protocol expresses things using URIs, partly because of some of the requirements are starting off HTTP and not necessarily from an RDF perspective. This issue is about bringing focus to IRI and whether they would be mapped to URIs and round tripping.
  • 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 other. Would server take request as is, or do the mapping. If one or the other, they might not match unless there is a mapping. We need wider insight from a bigger circle re: security considerations.
  • WT: Elaborate on example. Why would such a transition be necessary if the client asks for access? The request would already be containing an IRI; so 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 would be an limited set of scenarios, because most of the time identifiers (IRIs or not) are sufficient. Only when an IRI needs to pass in HTTP 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 meant 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 in my ACL I have the IRI of some agent, a request to the 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 or token.
  • SC: This whole issue is about hashing that out. Check assumptions to see if we are working with the same assumptions. Issue is here: solid/web-access-control-spec#93