From 29d3bfdc03baeaf4c4ec30e0e2a32b2ad320c352 Mon Sep 17 00:00:00 2001 From: Virginia Balseiro Date: Thu, 6 Jun 2024 06:34:11 +0200 Subject: [PATCH] Add meeting minutes 2024-05-28 (Special Topic Meeting) (#661) * Add meeting minutes 2024-05-28 (Special Topic Meeting) * Apply suggestions from code review Co-authored-by: Ted Thibodeau Jr --------- Co-authored-by: Ted Thibodeau Jr --- meetings/2024-05-28.md | 165 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 165 insertions(+) create mode 100644 meetings/2024-05-28.md diff --git a/meetings/2024-05-28.md b/meetings/2024-05-28.md new file mode 100644 index 00000000..29698ec5 --- /dev/null +++ b/meetings/2024-05-28.md @@ -0,0 +1,165 @@ +# W3C Solid Community Group: Special Topic Meeting + +* Date: 2024-05-28T14: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) +* [Rahul Gupta](https://cxres.pages.dev/profile#i) +* [Sarven Capadisli](https://csarven.ca/#i) +* [Ross Horne](https://personal.cis.strath.ac.uk/ross.horne/) +* Hadrian Zbarcea +* Tim Berners-Lee +* elf Pavlik +* John Kirkwood + + +## 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-bp/pull/2 + +* VB: There were some suggestions in the PR. Last STM, we said {a bunch of stuff}, and had some {actions}. +* eP: I did not add additional info, SC added some details. This is better for a separate PR. If we add your suggestions, would you be okay to merge? +* SC: ... +* eP: Change title? +* RG: Leave title as is and say it is WIP. +* eP: We can signal with version. +* TBL: Subtitle to reduce expectations. Early document, addresses a very small amount of the possible security issues. +* SC: We had some considerations for this work already. Something like "Security Considerations" can work. Not necessarily "best practice" but stuff people need to weigh/consider. +* VB: +1 +* RG: Added a comment. +* eP: Not sure about title. +* TBL: Security best practices implies you must address or danger. +* eP: Objections to change to Considerations? +* No objections. +* eP: Version 0.1? +* SC: Yes. +* eP: Abstract reflects discussion, document describes a few issues. +* SC: Works for now. +* eP: Solid-OIDC with links to open issues? +* No objections. +* eP: Suggestion re: multiple agents? +* SC: Clarify the cases / prerequisites. Example, if a storage is intended for one agent only, this doesn't apply. +* eP: It was implicit but okay with change. +* TBL: Add an example to the text. +* RH: Not sure. This is just an attack vector. You give the attack vector and that's sufficient. Keep the writing simple as it is now. +* SC: Current text implies server intended for single user should also be taking the recommended measures. Countermeasures for those cases are not meaningful. Should communicate who this recommendation is for. +* eP: If someone read they can decide. We need to reestructure that different countermeasures apply to different attacks. "agents" here might mean users not agents, so we need to define terminology. +* SC: We should be as specific as possible. We can address elsewhere or some other time. +* RH: We need model saying what capabilities are, etc. and have something more explicit. +* eP: Okay with adding the suggestion. We can revise structure later. + +ACTION: HZ to create issue to revise structure + +* eP: Considerations? +* VB: Good. +* SC: We should expand on this. If there's a structure we can bring in to these considerations. Can be per threat/countermeasure. +* eP: +1. +* eP: Like side effects. You fix something, you break something else. For each countermeasure, we'll list the side effects. + +ACTION: VB to create issue to add considerations to countermeasures + +* SC: Link to ??? +* eP: Should I merge? +* No objections. +* SC: Update biblio with references. + +ACTION: eP to merge suggestions and merge. + +* VB: Should OIDC issuer be included? https://github.com/solid/solid-oidc/issues/221 +* RH: Two different types of issues. One is in the flow of authentication protocol. Then, there are information flow issues. This document seems to be about the latter. For OIDC, this is not the right place. This should be in the OIDC document. +* RH: Not sure the status of OIDC. There was a (private) conversation after ESS addressed this. Why not push into the OIDC spec? Seems the most logical way to address. +* SC: Individuals are members of the CG? Working on OIDC? +* RH: AC is aware, Jesse implemented. https://github.com/inrupt/solid-client-authn-js/pull/3225 +* eP: Don't remembr why we didn't add. Can you make a PR, RH? +* RH: I can give it a shot. I can coordinate with eP. Should not be part of this document. +* RH: Solid doesn't scope to pods but whole of solid. +* eP: Which tokens? Access tokens are global, but Solid-OIDC changed that. Access token should be issued by authorization server on same domain as resource server. +* RH: I think ID token. Scoped to specific domain? I think not. +* eP: ID token is intended to ??? +* RH: might be possible to restrict scope. +* eP: Would you require user interaction? Would be terrible UX. +* RH: Agree. Not obvious what countermeasures are. Something like same origin. +* SC: Layperson's version of this issue? +* RH: Client scope. In ACP, we can restrict access to a resource to a user with a specific client. Same WebID across many applications. These do not necessarily trust each other. Need to make sure information does not flow from one app to another. Without client restriction, the assumption is that all apps are equally trustworthy. +* eP: Using ACP rather than WAC because of client matcher. Unacceptable for any random client to have user-level access. SAI implements that. +* SC: Client-specific access is tied to Solid-OIDC. Authorization is tied to a particular authentication; as soon as it changes, that entails update to authz. Coupling authn and authz is something we should not do. WAC added `acl:client` to distinguish from agent. Coupling WAC which is not tied to even Solid Protocol, general web access control mechanism. If we require client then WAC is tied to a particular solid authn mechanism. Henry was looking into HTTPSig. The idea is, user carries credentials with them. +* RH: Makes sense, but separation can be clean. Token can be issued by whatever mechanism. Two issues can be separate. Using different clients even with earlier stuff was possible. Even Henry's applications would involve multiple applications using same credentials. Agree with eP. This document should make everyone aware of the issues. Not entirely obvious what the solution should be. +* eP: One way of raising awareness is to create an open source wordle(?). AS soon as you log in, it deletes your data on all your pods. +* eP: authz/authn separation: we shot ourselves in the foot by having separate panels. Some work in data interop. If we have something representing delegation of the user, that could also be ??? authenticating parties with access policies based on identities; then you have authorization based on authentication. +* RH: What eP says points at what Henry wanted to do. Having ??? Much more complicated than adding terminology for ??? Can have as many delegations as you want, but too complex and fewer people adopting, therefore more insecure versions. +* RG: Two levels at which user has to identify: user having some "master" ownership; and various actors going into your pod, like a doctor, or insurance. They need different views. Their client should not leak info about the person's view. Does that mean there is authentication happening of the client through an app, client identified first, and then app second? Lots of complexity. User should not see that complexity. +* eP: App is the client. +* RG: User acting through a client and entire thing needs to be authenticated, each with limited access? +* eP: *explains terminology in https://github.com/solid/specification/issues/650 * +* eP: Two different end users might use the same client. +* RG: ??? +* RH: Authz and Authn must match. Authorize based on things that are authenticated. Authn has a different purpose but matches in that what's authenticated must be used in authorization. +* RG: Resource owner has to authenticate and whenever a requesting party needs access they need to authenticate. Requesting party might ask resource owner what they need authorized, and resource owner authorizes that limited data. +* eP: Requesting party doesn't mean request has to happen. RO can proactively share. +* HZ: Conversation gets confusing without discussing trust models. +* RH: Back to first thing we discussed from SC's request: we need more information and that is probably a trust model, where we have clients, pods at different security levels, notion of confidentiality. A trust model is defining which clients are honest, which are dishonest. +* HZ: I would phrase it differently. If somebody is authorized, do we consider them trustworthy? +* RH: No. +* HZ: ??? +* eP: We shouldn't talk about trust in a binary. Maybe client is not malicious, but not meeting my standards. If someone wants to create something from scratch, but rather build from oAuth. +* SC: Agree. Context is what is Solid trying to solve? What led us in this project? Don't mean to define the vision, but... How do we enable people to control their own stuff, work together on the web? Varying degrees of control. If we go on this path where the agent/user, other party, issuer, it gets into a model where you are extending this control to other parties. Not necessarily bad, sometimes needed. But putting all our eggs in the same basket is not a great idea. Who will implement these issuer parties? +* HZ: +1 +* SC: Alternative is users having their own credentials, Web of Trust... Credentials close to the device. Enable that type of model. Helps get closer to ultimately user controlling. Don't want us to lock ourselves from how we ended up here. Coming up with those solutions keep in mind. Web of Trust is not unique to Solid, and that is in some ways closer to the vision. +* VB: 2 cents as developer: to the point of not locking ourselves into stuff. Something like OIDC also has issues and valid why some may not want to go in that direction too. UX issues. Also well-known security issues. I think good for Solid to err on the side of not tying itself to something in particular. +* eP: We need balance between how we make breaking changes now and in the future, design in a way it can evolve. Having something operational: for next 3 years we need something ???, and maybe then it can evolve. For authentication there's FedCM. Heavily worked on by Google. Also participation from Mozilla and Safari. Also ??? using IndieAuth. We need to see other efforts at W3C. We need to be realistic and work with technologies that are being used. +* HZ: I don't understand rationale behind these proposals. Because of nature and sale in Solid, it is obvious we must support multiple authn and authz mechanism in parallel. I don't think Solid should be tied to one mechanism. We should not have a conversation as to what technology to use, but what characteristics those technologies should have. +* RG: RH what do you think about [HTTP Signatures](https://www.ietf.org/id/draft-ietf-httpbis-unprompted-auth-06.html) which is [being proposed in HTTP](https://datatracker.ietf.org/meeting/119/materials/slides-119-httpbis-http-signature-auth-00.pdf)? +* RH: This should be in Solid even ??? separate project. Separate from these security recommendations. +* HZ: +1 +* SC: [AP and HTTP Signatures](https://swicg.github.io/activitypub-http-signature/), and also Mastodon's use of it. +* SC: Completely agree with eP that we get a lot of mileage if we use tech that a lot of people are working on. Multiple mechanisms is important and useful. Similar to how signing HTTP messages is worked on by various parties. Cool stuff in FedCM but also worked on by an org that wants to control people's identities. I know we don't have the bandwidth to solve all of this, but let's be mindful that dismissing approaches carries a lot of assumptions in the reasons to dismiss. +* HZ: +1 +* eP: SC, HTTP signing mostly used by server-side? Something on the browser using it? +* SC: No, partly to do with in the browser you need something like a wallet. Some APIs. Something that can securely release your credentials to anything that needs them. There are specs like [Universal Wallet](https://w3c-ccg.github.io/universal-wallet-interop-spec/) in the Credentials group. EU has projects on topics of wallets, e.g., [Digital Identity wallet](https://digital-strategy.ec.europa.eu/en/funding/european-digital-identity-wallet). And note that not all uses of "wallet" mean the same thing. [Solid Wallet](https://nlnet.nl/project/SolidWallet/), [Solid-Control](https://github.com/co-operating-systems/solid-control). +* eP: WG and what can be published, what we can have as normative references. If we want something published in 2 years with only mature normative references, we need to use what is already available or has a WG that can be delivered within two years. OIDC, FedCM. If there's wallet that is not at least chartered, it cannot be used. Thinking 15-20 years from now is one thing; in 2 years, it is different. Keep things in a way we can evolve. +* VB: I think most of us are suggesting not tying ourselves to something in a way we cannot pivot later on. +* HZ: +1 +* eP: Implementors need to implement something. Need a sweet spot between temporary dependency and having it composed in a way we can sunset. We cannot always keep everything open. +* HZ: Not sure that's what VB and others said. I agree we want to use a set of technologies today, specify how to use. But Solid is a protocol; define minimal set of those dependencies and allow for variations in the future. I don't see how it can slow us down. Define the principles, choose what to use today. Interop doesn't mean everybody has to use the same technologies. +* VB: +1 +* SC: Some specs say interop is defined by this or that product. Thinking along those lines helps figure out what needs to be communicated. Solid protocol is just server and client. Then we have a nicer way of expressing Solid notification. We have 5 products, sender, receiver, subscriber... There's an [issue for solid spec](https://github.com/solid/specification/issues/480) where we need a bit more detail on these products. +* SC: Right now we say server and client, but maybe it needs more details. Consumer, storage, thing doing the patching... You can combine these in different ways. In other specs we have authz server, application, and so on. +* VB: WebID Profile has Reader Application, Writer Application, and so on. +* SC: Maybe we say app that lives in the browser, app that lives in the seerver... Ways of being more specific about the types of products that could be built. If we get stuck on just server or authn server, we are going to assume what that product is capable of. Stuck on whether it should (or should not) have issuer... +* VB: +1 +* eP: Prefer we use established terms. oAuth has well established terms. +* HZ: +1 + +--- +