-
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.
Co-authored-by: Ted Thibodeau Jr <[email protected]> Co-authored-by: Sarven Capadisli <[email protected]> Co-authored-by: Michiel de Jong <[email protected]> Co-authored-by: Virginia Balseiro <[email protected]>
- Loading branch information
4 people
committed
May 30, 2024
1 parent
9390154
commit c093df4
Showing
1 changed file
with
133 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,133 @@ | ||
| # W3C Solid Community Group: Weekly | ||
|
|
||
| * Date: 2024-05-15T14: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 | ||
| * [Michiel de Jong](https://michielbdejong.com) | ||
| * [elf Pavlik](https://elf-pavlik.hackers4peace.net) | ||
| * [Virginia Balseiro](https://virginiabalseiro.com/#me) | ||
| * Hadrian Zbarcea | ||
| * Tim Berners-Lee | ||
| * Rahul Gupta | ||
|
|
||
| ## 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. | ||
|
|
||
|
|
||
| ### Scribes | ||
|
|
||
| * Virginia Balseiro | ||
|
|
||
| ### Introductions | ||
|
|
||
| * | ||
|
|
||
| --- | ||
|
|
||
| ## Topics | ||
|
|
||
| ### WG Status | ||
| * VB: Skipped until we have PAC in the call. | ||
| * HZ: Is there anything blocking that PAC needs to wait for? | ||
| * RG: Drafts included in CG need to be changed to CG-DRAFTs. | ||
| * HZ: That is not a blocker. | ||
| * RG: No but W3C said nice to have.. The blocker has been sorted by Sarven's PR. | ||
| * HZ: Nothing PAC expects from us? | ||
| * MdJ: AFAIK, no. | ||
|
|
||
| ### Strategy for making breaking changes | ||
|
|
||
| * VB (last week): Let's pick this up again next week. | ||
| * eP: Keep in mind we plan to hand work over to WG. WG has full mandate to make breaking changes. This is just CG findings. What will we do when breaking changes happen? Few approaches/experiences: Websockets, Solid-OIDC. We need a clear strategy and communicate to implementers. | ||
| * MdJ: For example, adding SAI to spec would be a breaking change and not too far into the future. | ||
| * TBL: Websockets example: any breaking change has a negative impact on the ecosystem. They should be implemented rarely, and when they are ??? need a way to make sure we are backwards-compatible. Working with SAI is very different. | ||
| * eP: See with implementers and deployments — communication loop to be more aware of actual adoption. Harmful for the ecosystem, but an argument is the ecosystem is slow, so, if need to make breaking changes, now is the best time. Good to have strategy to be able to make breaking changes later; now is a good time to test drive deprecating or sunsetting parts of the protocol. | ||
| * MdJ: We already have a mechanism. Introduce the new one, say the insecure one is deprecated. I don't think that's really your question, Pavlik? | ||
| * TBL: If there's a breaking change, number before dot should change. So we should use semver >= 1.0. | ||
| * MdJ: I think eP's question is not how do we number, how do we sunset. It's more we have all these different implementations, side-by-side. which are not compatible with each other. How do we keep having a single spec even with contradictions? Some people work on WAC, some on ACP, some on SAI, some on Inrupt's access requests, etc. We have different ways of doing policy registries, how can we move to a spec that includes SAI? | ||
| * eP: For example, what if slash semantics go away? what's the strategy? Looking at things we'd like to anticipate changes on, how to communicate. | ||
| * MdJ: With Websockets we all agreed ??? We cannot say to make a breaking change without excluding ??? | ||
| * eP: I think it's a good exercise to say if a breaking change needs to happen, how to approach. | ||
| * MdJ: The WG will be very different from CG. WG will need to arrive at one protocol, and CG is an incubator. If someone in the CG still wants to do X (e.g., use slash semantics), I don't think we should deprecate it. | ||
| * TBL: If people want to deprecate slash semantics, there would be a fork. If you wanted to make a spec that included ??? you'd have different levels of ??? that you can negotiate between client and server. | ||
| * eP: We should clarify the difference between fork and next version with breaking changes. All specs in CG are CG drafts. More important for WG. WG publishes the actual recommendations. We need to clarify fork, breaking changes, CG drafts, recommendations from WG, etc. Those can have breaking changes, assuming everything would be a fork? We need a clear strategy. | ||
| * RG: TBL you're breaking up. | ||
| * MdJ: TBLs and my answer, maybe you have clarification/answer to your question if you add them together. | ||
| * eP: We can move on. | ||
| * MdJ: To summarize, if the CG were to pick one of five parallel experiments as the next version of Solid, then it'd be up to the experiment to say they're excluded. Because in 2 years, there will be a version published by WG anyway, there's no use trying to converge before that happens. Let's stick with multiple options. | ||
| * RG: Can we have the answwer written down so people know what to expect? | ||
| * TBL: Cost of breaking changs to the community is huge. We should not do it. Exercise for this group would be to re-introduce ACP and suppose they wanted a different version of WAC. That could be done in a way that was much more interoperable. WAC 1.0 and 2.0 for example. Look at what ACP spec would look as an extension of WAC. About slash semantics: you don't have to use. | ||
|
|
||
| ### Add Solid Application Interoperability (SAI) as a mechanism for authorising access to protected resources | ||
|
|
||
| URL: https://github.com/solid/specification/issues/650 | ||
|
|
||
| * MdJ: I opened it after talking with Pavlik on Friday about Policy Registries. We have more types of Policy Registries than WAC and ACP. Why don't we mention all of tham rather than only WAC and ACP. | ||
| * VB: What do you mean by, we have documented implementations we have feedback on? | ||
| * MdJ: There are few implementations of WAC and ACP; there is one partial implementation of SAI. Inrupt has Access Grants implementation. Digita has their Access Grants implementation in production. | ||
| * VB: What worries me as front end implementer is that clients have to implement all of this. We don't have a library covering all of this, and the library we have for WAC-ACP is not ideal. I am also unsure what the status is on ACP spec. Haven't seen much development recently. | ||
| * MdJ: So you say it would be better to go back to just WAC? | ||
| * VB: Yes :) | ||
| * eP: I have one access management client, so it wouldn't affect most apps. 99% of clients should implements WAC/ACP. | ||
| * MdJ: So which Policy Registries would you say the spec should mention? | ||
| * TBL: I disagree that you should have separate apps for managing access control. When I share stuff on macOS, that is done by the app (for example, photo app). I would worry that, as an app developer, I need control of that ??? to guarantee the integrity of the data. | ||
| * VB: +1. | ||
| * eP: TBL, is your assumption that an app developer will require the user to let the app edit the access policies to use the app? | ||
| * TBL: When you set up something (meeting, access ??? tracker) app gets ability to set access control on ??? When app has resposibility for one folder, it works well. They don't have to have control access to rest of pod. | ||
| * MdJ: We have people who want both. We should allow people; they're both valid use cases. Whether there's an authorization agent or apps edit directly, should we mention just one policy registry (WAC, would be overruled by WG)? Should we have the two we have now and ignore eP's work on it and Inrupt's work on access grants? OIDC spec already mentions UMA. Lots of separate efforts happening in the community. Do we want to update the spec to acknowledge all the things? | ||
| * eP: I dont think SAI should be included for personal/sentimental reaons. ACP/WAC don't meet certain requirements. | ||
| * VB: I will post my thoughts on the issue; this is a big change. Introduction of ACP already created many issues for front end developers. We should actively involve Practitioners in this discussion. | ||
| * MdJ: Can we agree as the CG that this is a missing part of functionality? There are currently 6 different ways that are being explored. | ||
| * TBL: No, we shouldn't say that there are 6 different ways of doing something. The only thing that actually works is WAC. There was a push to move the community to ACP but ??? we don't see a way to have ??? Implementers have to choose ACP/WAC, and clients have to implement both. This is not "the cat is in the bag". We have kittens. But there's only one cat. SAI has ??? lots of issues with SAI. I can see SolidOS moving from WAC to ACP or WAC to WAC 2.0... | ||
| * eP: If we have UCRs and proposals that meet them, we can say expected behavior are met in this way. When we say WAC works, I haven't seen how the requirement I mentioned is met. | ||
| * RG: We need to get ??? we need an STM. | ||
| * VB: More implementation feedback would be useful, so that we have more insight into potential issues, security concerns, and so on, that we should be aware of before requiring it in the spec. | ||
| * eP: It'd be useful to have UCR so that they can select the work that addresses their requirements. | ||
| * TBL: Useful to have different use cases. Before we go down into lots of micro use cases, we focus on high level use cases. | ||
| * VB: +1. | ||
| * MdJ: We already gave SAI more visibility through hackathon. At CG level, we could inform of use cases and present SAI. So people know where to find it, keep protocol as it is, make sure people know where SAI is. | ||
| * eP: It's not about SAI. Do you clearly describe references between the 6 different approaches you have mentioned? Would be good to have a way to find a way to evaluate all of them. | ||
| * RG: Having some discussion (STM) to bring us closer, even if not to a conclusion. So much info that needs to be digested. | ||
|
|
||
| ### CG-DRAFTs PRs | ||
| * VB: Please review: https://github.com/solid/specification/pull/651 and https://github.com/solid/specification/pull/652 | ||
|
|
||
| --- | ||
|
|
||
| ### Eating our own cookings ([dogfooding](https://dbpedia.org/resource/Dogfooding)) | ||
|
|
||
| URL: https://virginiabalseiro.github.io/solid-ecosystem-monitor/ | ||
|
|
||
| * eP: CG meetings are one of the few things we do together. Instead of scraping the text with minutes, we could use the power of Linked Data and maybe even Solid. | ||
| * eP: I started a simple prototoype which I would like to use to track my participation: https://github.com/janeirodigital/sai-js/tree/main/examples/plenary#readme | ||
| * eP: In short, minutes are managed as an external attachment, meeting description links to them, all the rest can be managed based on shapes, shapetrees, etc. | ||
| * eP: An interesting case for role-based permissions! For example, chair can make more changes than a regular CG participant. | ||
| * VB: Postponed to next week. | ||
|
|
||
| ### User Profile and Contacts | ||
|
|
||
| URL: https://github.com/solid/webid-profile | ||
| URL: https://github.com/solid/contacts | ||
|
|
||
| * eP: Besides aligning those two efforts, we should also align them with | ||
| * https://www.w3.org/TR/contact-picker/#contact-property | ||
| * https://github.com/fedidcg/FedCM/issues/559#issuecomment-2057657128 | ||
| > Beyond name/email/picture which is currently supported, some of the most commonly asked extensions are allowing RPs to request the user's phone number (as opposed to email addresses) or the user's language preferences. It is not clear where we could go from there, but we expect a subset of the OIDC's Standard Claims or HTML's autocomplete to be things that the browser could potentially mediate in a constructive way (e.g., organization, country, websites). | ||
| * VB: Postponed to next week. |