-
Notifications
You must be signed in to change notification settings - Fork 44
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add minutes 2024-06-04 (Special Topic Meeting) (#663)
* Add minutes 2024-06-04 (Special Topic Meeting) * Apply suggestions from code review Co-authored-by: Ted Thibodeau Jr <[email protected]> --------- Co-authored-by: Ted Thibodeau Jr <[email protected]>
- Loading branch information
1 parent
29d3bfd
commit 0652566
Showing
1 changed file
with
103 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,103 @@ | ||
| # W3C Solid Community Group: Special Topic Meeting | ||
|
|
||
| * Date: 2024-06-04T14:00:00Z | ||
| * Call: https://meet.jit.si/solid-cg | ||
| * Chat: https://matrix.to/#/#solid_specification:gitter.im | ||
| * Repository: https://github.com/solid/specification | ||
| * Status: Published | ||
|
|
||
|
|
||
| ## Present | ||
|
|
||
| * [Virginia Balseiro](https://virginiabalseiro.com/#me) | ||
| * [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) | ||
| * Jeff Zucker | ||
| * elf Pavlik | ||
| * [Sarven Capadisli](https://csarven.ca/#i) (joined at 14:40 UTC) | ||
|
|
||
| ## Announcements | ||
|
|
||
| ### Meeting Guidelines | ||
| * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). | ||
| * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md). | ||
| * 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. | ||
| * Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed. | ||
|
|
||
| ### 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. | ||
|
|
||
| ### Chair | ||
| * Virginia Balseiro | ||
|
|
||
| ### Scribe | ||
| * Virginia Balseiro | ||
|
|
||
| --- | ||
|
|
||
| ## Topics | ||
|
|
||
| ### Security Best Practices | ||
|
|
||
| URL: https://github.com/solid/security-considerations/pull/9 | ||
|
|
||
| * VB: *explains comment on WebID stored in Solid storage* | ||
| * JZ: To take away the ability of a Solid app to edit the WebID document takes away from ??? and puts everything under control of the server. It'd be a huge mistake to put WebID documents in non-Solid storages. It's a terrible direction. Securty concerns need to be addressed; there should be server safeguards. | ||
| * TT: I disagree strongly. I have never thought that a WebID had to be hosted in any particular server to be usable with Solid. Doesn't matter to me what the protocols as long as I am in control of my WebID Document. | ||
| * VB: I agree with both in some ways. I agree with Ted; I have my WebID hosted in my server, and there are different use cases for WebIDs. But I also see Jeff's point in a different way. We have implementation experience and feedback. Developers complain that they have issues with that approach. Abstracting it also makes UX harder. We either need to spend a lot of resources looking at all the different possibilities or rely on another predicate which feels weird. Exploring solution when some restrictions are put on some requests are worth while. | ||
| * JZ: What possibility? | ||
| * VB: In [issue #219](https://github.com/solid/solid-oidc/issues/219), we have two options. The second option has restrictions on specific triples. | ||
| * JZ: Agree. Reason I disagree with TT is that it makes no difference to you, but most users of Solid are not going to be RDF experts and know how to edit their WebID. They will rely on apps. Those apps will need access. | ||
| * TT: Why do those apps need to edit the WebID profile? You are saying WebID is not valid unless its a "Solid WebID". | ||
| * JZ: No.. but you can't claim it is compatible with Solid client-client specs.. | ||
| * TT: What Solid app needs to write should go into my storage, not necessarily into my WebID profile. | ||
| * JZ: Client arrives at profile and follows every `seeAlso` until it finds a pointer to an index? | ||
| * eP: There's nothing in what I'm proposing preventing people from ??? Not saying not possible to have discovery mechanism. | ||
| * eP: Solid protocol gives no guarantees that WebID is writeable by Solid protocol. It's already the case that it's not required. I agree we need a few handfuls of ??? we want to edit that, but also unlikely has to edit that. We're attached with solutions and we don't have use cases and requirements. Once we have clarity on the problem we are trying to solve, we can compare. | ||
| * VB: I think that there is a balance. The are different use cases for WebID: some use it to authenticate, some for their social profile. I also see external profile as attachment to one solution. For various reasons, WebID provider may make it uneditable. It also feels a bit brittle that the security depends on one single point of failure; we should explore better solutions. If it is a Solid resource... Why can't we explore the case where it is hosted in the Solid pod and protected in specific way? I still want more considerations for the burden that is put on developers. I don't know if having one designated predicate is a good solution. | ||
| * JZ: I understand that this is a security threat. I don't have an issue with that. If people want to do that, it's fine. I want to get back to bootstrapping. Who requires that specific things are in the profile? We either need something that mandates server to put it there or clients need ???. | ||
| * eP: There's no disovery mechanism in the protocol, but nothing stopping people from implementing one. Some CG work is competing and proposed for WG. Discovery is out of scope for WG. Completely agree that we need to give clarity. But allowing any random app to edit doesn't solve the problem. Having spcial protected triples.. making WebID document a special case has a big ??? how do you know it's a WebID document? If we have proof that it's doable.. for now it feels like an idea / wishful thinking. No existing implementation. This would be required in WG, because we need to ensure it is secure. | ||
| * JZ: If we don't have something that says which predicates must be in the Solid profile, then it leaves it random. Type indexes in SAI are in that position. Other things are going to come along. If other specs require specific things in the WebID document, in order for those to be implemented, every server will have to change their webid profile documents. Not workable to say "we'll deal with it later". | ||
| * eP: You're touching an important problem. 2-3 weeks ago we talked about breaking changes. How to roll out / sunset features. That's one of the cases. If we add a new discovery / authentication mechanism, we need to have a strategy for the ecosystem to evolve. We need to treat applications as the least trusted component in the ecosystem. | ||
| * TT: I don't fully understand the idea of TI. JZ, you're saying two contradictory things: you're concerned about unsophisticated users unable to edit the RDF in their WebID, but those same users will make a sophisticated judgement about whether their app should change their TI? | ||
| * VB: It is not user who adds the type index; app would do it 'under the hood', | ||
| * TT: That should not go in the WebID. | ||
| * eP: I see a big problem with no requiring explicit authorization from user to do that. If app can do that, if malicious app injects new type index, other apps could start storing data in attacker's storage; user should at least give explicit consent. | ||
| * JZ: Good points. eP, your previous point about introducing a new predicate requiring a new safety mechanism is a good point. It's true apps are random and the most insecure part of the ecosystem, but they're also the thing that creates interoperability which is a vital part of the ecosystem. The other thing about having a profile in a non-Solid storage is that Solid protocol has nothing to say about it. We can't make definitions about it, no restrictions. If it works with OIDC, that's sufficient; no consistency that Solid ecosystem can place on that document... That doesn't make any sense. If we're recommending or even allowing profiles to be on servers that are not Solid protocol, we absolutely need a single predicate to point to where the writable profile is. If it's one extra hop... Fine. that's infinitely better than going there and wondering around until you find the TI. | ||
| * eP: https://github.com/solid/specification/discussions/632 — we should not put the burden of dealing with TI and so on on app developers. App developers should not have to read Solid specs. Libraries / servers should take more burden. | ||
| * TT: We're talking about two different kinds of things people want to store in WebID: trust anchors like public keys can be stored here. They are per user, not per application. But TI sounds like it's akin to media type regstry. Broad applicability, used by broad number of applications. | ||
| * eP: both TI and SAI rely on common references to RDF classes. TI is per user, but it's set when your account is set up. | ||
| * JZ: TI is specific to the user. Where user keeps things. | ||
| * eP: Do you think apps should be responsible for the bootstrapping? | ||
| * JZ: I agree with you that if we can enforce that through bootstrapping it would solve part of the problem. If we allow it to be somewhere unwritable, there should be a path to where it is writable. | ||
| * eP: Can we agree that we want to draw a distinction between what needs to be discoverable from WebID document (avatar, names, etc.) and something like TI / SAI? | ||
| * SC: I don't know if there's a parallel with other parts of the system like containment triples managed by the server. They're protected statements. An application can still have a way of interacting with a container (can POST to a container, PUT something) and server will manage things for you so you cannot modify special statements.. similar to this idea.. not having a direct way of manipulating OIDC issuer or pubkeys.. one option. However that's updated we need to think: how does one change the OIDC issuer / pubkeys using the solid protol? Perhaps there's a gap in the protocol? The other area is https://github.com/solid/specification/issues/31 — has to do with storag provisioning. Example, maybe not best fit for this case. This is another gap: we don't have a way of describing if/how someone can create / initialize a storage, doing some lower level lifecycle things around the storage. Ties into bootstrap: how to start a webid that's functional in the Solid ecosystem? When we talk about WebID from WebID spec itself, that's not overly intersting for Solid other than reading.. interesting uses. But writing/updating, that's just "classic" WebID that can be published on any server, is not particularly interesting to Solid because there's no defined protocol. The only thing we know is you can update a Sold WebID using the Solid protocol. There are issues if OIDC issuer is there and anyone is allowed to update. But I think we haven't really prohibited server to block any writing/updating of OIDC issuer. If we said that, it would at least prevent the attacks where a malicious app could change a trust anchor. If we introduce a requirement that "server protects OIDC issuer", all those attacks go away. If we do say that, we are not describing how that OIDC issuer is added in. | ||
| * eP: Can we agree that at this moment the protool gives no guarantee that the WebID document is exposed via Solid protocol? | ||
| * JZ: In other words, we're going to specify that you can't modify in *this* way, but nothing about how it can be modified? | ||
| * eP: Back to specific use cases and requirements. There's a mention that we're "taking away" something. Right now, there's no guarantee WebID will be on Solid protocol. | ||
| * SC: Valid question but it's missing some detail. In broader Solid ecosystem, a WebID could be used as a way of authenticating, and that's it. No way of expressing yourself there, using the Solid protocol. You can modify yourself. Out of scope of Solid protocol. Could partiicpate in Solid ecosystem by adding the triples required like `pim:storage`, OIDC issuer.. authenticate, dicover storage, etc. Other one is the focus of Solid WebID Profile: how do we have this work by using the Solid protocol? That includes, from the use cases, controlling your own profile, your own data. And that needs a reliable way for Solid apps to do it. We can't say WebID can be done anywhere and our protocols don't let you describe yourself on the web. Two separate cases we should cover to different extents. Of course, we cannot cover all WebIDs. To participate in Solid protocol, you either have your WebID on a Solid storage, or your participation will be limited to the properties you expose. | ||
| * eP: Do we have those use cases documented anywhere? As we evaluate we can say if they are met, how to extend implentation experience, etc. | ||
| * VB: We have some here: https://solid.github.io/webid-profile/#use-cases and | ||
| https://github.com/solid/webid-profile/blob/main/notes/use-cases.md . We can expand. | ||
| * SC: https://github.com/solid/user-stories/ . We should be careful wtih the scope of this security considerations. Our first focus should be: because of the ways our specs are set up, they lead to security issues. We can cover those. I am not sure how we can cover things outside of that. If a WebID is outside a Solid server, I don't know how much more we can say. Maybe keep first to the issues in the way our specs are. | ||
| * JZ: Concerned about giving go-ahead for profiles that are not on solid protool servers without specifying the bootstrapping. In terms of use cases, not sure the value in that. We agree some things people need to write and some need to be protected. We don't need more proof. We need a way that they can be protected, and people can write to the non-protected in a clearly defined way, and find what they need to find, as quickly as possible without poking around. TI is one thing in that category. What's your proposal for bootstrapping? Where would that go? | ||
| * eP: Solid storage should be its own spec. Protocol should be just gluing stuff together. There's no place that specifies. Eventually, umbrella Solid protocol should link to how to bootstrap. We keep talking about implementation experience. This is based on implementation experience. Solid protocol doesn't say whether WebID protocol is writable, but we rely on it for authn/authz. | ||
| * VB: re implementation experience: experience from one server implementation may not be adequate. Listening to app developers is equally important. Adding a recommendation nudging people towards one solution re oidcIssuer without implementaiton feedback from developers may fall short. | ||
| * JZ: There's also plenty of implementation feedback on TI. Nuber of apps using them for years. Two key functions of WebID profile are in conflict: security concern needs to be dealt with. But the other concern is how to quickly get to info you need. We need to tackle both. | ||
| * eP: Need to evaluate all proposals taking the two into account. VB, can you clarify on issues? | ||
| * VB: Disocvery, where to write, etc. | ||
| * JZ: Feedback from app dev was the confusion on where to write ??? Number of people expressed this concern | ||
| * eP: Which use cases? | ||
| * VB: Use cases are clear.. problem is that it is convoluted. Burden on app developers. Need to figure out which server did what and have different branches for each. | ||
| * SC: Agree with JZ's earlier point. Also want to add implications on the system where identity is essentially controlled by (third-party) identity provider — the one having the highest authority to modify the primary WebID Profile Document. | ||
| * SC: re solution provided by proprietary system vs. what's spec'd. That definitely creates a split in the ecosystem and forces devs to figure out why there is no interop. They are confused by figuring out where to update their profile because the solution is counterintuitive. The intuitive thing is that the same URI is used for reading and writing. Except, in this case, a solution says modifications on this resource happen somewhere else, and even then it is not complete but only part of a description. | ||
| * TT: What is the basic core feature people are interested in? I don't think it's the control of identity. Solid is about control of your data. WebID profile document is ??? not the provider who is a storage location for the WebID. Solid has had the same problem since it began. It wants to be everything for everyone. Things are being reinvented by Solid instead of being embraced and extended. | ||
| * VB: Don't disagree with any of this. Good idea to have security considerations. I'm worried that if my WebID is anywhere, and mine is on my site, and can update there, and Solid storage is a valid place. I'm worried that we may be saying that because of the security considerations, we are saying don't host it on the Solid storage (?) I've been working on WebID editor and it has been difficult because of all these issues. Hard to move forward when landscape is so uncertain and the solutions seem to be workarounds which don't include everyone except server implementers. | ||
| * eP: Definitely agree on many things. We all can appreciate discovery mechanism that is ??? Agree we need to provide something coherent for develpers. Happy to scrap SAI and put experience into building something else. Future STM we could focus on discovery. | ||
| * SC: To TT's point, if we don't describe writing the WebId Profile Document, only the data models (including stuff like issuer, keys, storage, inbox, type indexes). That might not be overly helpful to store / update WebIDs under Solid storage, to VB's point. | ||
|
|
||
| --- | ||
|
|