From 6e1acdc5f4a4e04a486a9d0054be2b5870fb4366 Mon Sep 17 00:00:00 2001 From: Michiel de Jong Date: Tue, 2 Jul 2024 16:52:23 +0200 Subject: [PATCH] Create 2024-06-26.md (#669) --- meetings/2024-06-26.md | 87 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 meetings/2024-06-26.md diff --git a/meetings/2024-06-26.md b/meetings/2024-06-26.md new file mode 100644 index 00000000..bfa42c5e --- /dev/null +++ b/meetings/2024-06-26.md @@ -0,0 +1,87 @@ +# W3C Solid Community Group: Weekly + +* Date: 2024-06-26T14:00:00Z +* Call: https://meet.jit.si/solid-cg +* Chat: https://matrix.to/#/#solid_specification:gitter.im +* Repository: https://github.com/solid/specification +* Status: Agenda + + +## Present +* [Michiel de Jong](https://michielbdejong.com) +* [elf Pavlik](https://elf-pavlik.hackers4peace.net) +* Grace Elcock +* Jesse +* Maxime Lecoq-Gaillard +* [Rahul Gupta](https://cxres.pages.dev/profile#i) +* Rui Zhao +* [Ted Thibodeau](https://github.com/TallTed/) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) + + +## Announcements + +* MdJ: Solid PoC presentation from SEMIC next Monday: +* https://joinup.ec.europa.eu/collection/semic-support-centre/event/solid-poc-final-webinar + +### 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 +* Michiel + +## Topics + +### Some drafts need active editors + +* https://solidproject.org/TR/acp +* https://solid.github.io/authorization-panel/authorization-ucr/ +* https://shapetrees.org/TR/specification/ +* eP: I could help with the last two, also planning to do some implementation work with `acp:vc` matchers +* eP: I've been going over different drafts, to apply the template and the copyright, and it seems that some of them don't have active editors +* eP: So I think we should try to figure out who wants to take ownership of each. For ShapeTrees, maybe Justin or Eric, I'll check with them, +* eP: and willing to use with that one too. +* eP: With the use cases one, I can also look how we can move it forward. It might be better to have one pool of use cases. +* eP: The bigger question mark is ACP. Is Matthew still working with Inrupt? Is someone willing to keep iterating this spec? Someone other than me. +* eP: I was hoping Hadrian would be here. +* MdJ: thanks for working on this! +* MdJ: if nobody's working on ACP then let's just leave it for the working group. + +### Mapping Solid Ecosystem + +* eP: Jeff suggested that he will be able to present some of the work he has been collaborating on +* eP: I started prototyping https://elf-pavlik.github.io/solid-efforts/ +* eP shares his screen and gives a demo + +### A Solid implementation where each app gets their own folder +* MdJ: After reading Noel's blog post, I wondered whether we should add this feature as a (security) recommendation. I can see pros (security) and cons (it steps off the path to, one day, inter-app interop). +* eP: What's the degree of sandboxing? Could you do it with WAC. ACP has a client matcher. Can someone else access it too, then? +* MdJ: I think with WAC, you would use ORIGIN, and with server side app, you would use WebID of that app. For other people to access data, isn't that an orthogonal problem? +* eP: It depends what the app would let you do. if you access data you don't own, then it's not sandboxing. It's self-confining, you could also use cookie-based sessions or FTP then. You don't need the complexity of Solid. +* MdJ: Ah, but you would separate the storage from the application. +* eP: If you only want to use it with your own data, this could work. +* MdJ: So what about the [autonomous data manifesto](https://autonomous-data.noeldemartin.com/architecture.html#the-autonomous-data-manifesto)? +* eP: You mean like IndieWeb? +* MdJ: Let's think of apps you use by yourself. Image editor, shopping list, ... +* eP: Even here, I may want to let my spouse add something to the shopping list. +* MdJ: Think of a normal app where you can create an account. Now, you apply autonomous data manifesto. Then, I choose to store it in my pod. Provider can't store this data, and has to describe model of that data. With Google, one could download a zip archive of the data. +* eP: Ok so it could work if everyone is using the same app, how does it take us closer to them more ambitious goal of users haing freedom to choose their app? +* eP: Which party is responsible for setting access on that app-specific container? +* MdJ: NSS has this trusted apps array, which provides ... There is a dialog which asks if you want to let app access your pod. +* eP: That should work where IdP and storage are coupled. Together they could set the permission during the auth redirect flow. +* eP: WAC origin will fail if malicious app is running server side. + + +### How is app origin linked to OIDC audience +We talked about this link, and thought it's probably useful to add to the security best practices that a server should never trust the HTTP Origin +header as a way of determining the app's origin. Instead, it should use the audience or azp of the OIDC token.