Create 2024-06-26.md (#669)

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.