# 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.