# W3C Solid Community Group: Weekly

* Date: 2023-03-22T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* elf Pavlik
* Matthias Evering (https://solidweb.me/testpro/)
* April Daly
* Huw Diprose
* Kurt Cagle
* Tim Berners-Lee
* Michal Z.

---

## 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/solid/specification/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]( )
* [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
* name

### Introductions
* name: text

---

## Topics

### Implementation Feedback
* SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.

### AuthN and AuthZ Server side clients (apps)
URL: https://github.com/solid/specification/issues/504

* eP: Mostly focused on solid clients, running on servers. The backend is acting as the solid client for this.
* eP: Listed a few clients but the list is not complete.
* eP: working on authorization agent that uses solid storage. In some cases it acts as a server side client.
* TBL: if a pod implements WAC then it has to provide access top the group (root?)(???)
* eP: In that case the solid server itself will act as a client
* eP: I propose to focus on three design principles, and see if we can agree on them. Hope these will act as "stakes in the ground".
1. Server-side clients can manage the private key
* Security is based on signing (???) between the server ..
* DPoP is a secondary signing (short lived keys for the session)
* Reliable management of private keys is possible, we don't have to have the delegated authority to some ID Provider, the client can maintain their own keys.
2. Server-side clients should be able to authenticate independantly fro the end-user
* Currently, there is the WebID claim for the end user, there is also the ACP claim thats identifying the client itself. The client has their own clientid / webID. so the openID provider.
* In the case of server side, we don't need this coupling of client and user, it could have it's own ID, and we might not want to couple these two for authorisation
3. Resource Server has an associated Authorization Server
* There's also the issue of delegation. There's still an aspect taht whenever we had a requst we'll need to know that "this client" acts on behalf of "this user", here we're stepping beyond (??).

ACTION: eP to create an issue with overview of end user delgating to app (client) cases, requirements and prior discussions

### Auxiliary Resources with own Access Controls
URL: https://github.com/solid/specification/issues/501

### Resource state changes and differences
* SC: We can revisit the state of below issues (topics) and look at next steps.

#### Standardizing state changes in resources (history, undo, sync)
URL: https://github.com/solid/specification/issues/161

#### Evaluate existing RDF delta/diff formats
URL: https://github.com/solid/notifications/issues/157

* SC: Move work to solid/specification?
* eP: Question to PAC about latest work on deltas in RDF, maybe the cannonicalization wg
* TBL: rdflib can handle deltas already, data doesn't have an ocean of blank nodes, no need to panic about blank nodes and diffs. If we have a format which client sends a patch to the server, the same format can be interpreted by the client if received in the notification.
* PAC: I totally agree with Tim, blank nodes are not so bad in practice. The cannonicalization algorithm could be a one way to use in patch. Again as Tim said it could be an overkill, in most cases WHERE clauses are easier to identify those blank nodes.
* TBL: Maybe the metadata that is added to notification, the changlog is not only the changes but also the basic stuff you need to undo, blame, basically offline first.
* eP: Authorization system would need to take it into account if we disclose who made the change to the resource.
* TBL: concept of who is the creator of the document is impmortant

---

### Solid WG
URL: https://github.com/solid/solid-wg-charter

* Proposed by PAC
* PAC: The work is progressing, soon we are going to submit proposal to horizontal review group. When this is done it will go to members for the approval. Don't hasitate to have another look at the charter.
* PAC: I would like to setup pool which was done for previous charter. It was called expression of support / expression of interest. People and origanizations could record interest in the future working group.