Create 2025-01-15.md

meetings/2025-01-15.md

@@ -0,0 +1,124 @@
+# W3C Solid Community Group: Weekly
+
+* Date: 2025-01-15T14: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)
+* [Rahul Gupta](https://cxres.pages.dev/profile#i)
+* Hadrian Zbaracea
+* [Erich Bremer](https://ebremer.com/profile#me)
+* [TallTed // Ted Thibodeau](https://github.com/TallTed/) (he/him) (OpenLinkSw.com)
+
+## 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.
+
+### Solid Symposium
+
+#### Solid Together Session
+
+https://cxres.inrupt.net/public/SoSy25/solid-together/
+
++ RG: The [Solid Together](https://cxres.inrupt.net/public/SoSy25/solid-together/) session, organized by Solid Practitioners, aims to highlight the various projects around the world that use Solid to serve the greater good in society.
++ RG: Contributions Welcome! 
+
+
+### Scribes
+* Hadrian Zbarcea
+* elf Pavlik
+
+## Topics
+
+### Vote about charter change
+https://github.com/w3c-cg/solid/pull/21
+* MdJ: This is a change of the text of the charter. I don't think the previous text was talking about interim chairs. This change of the charter aims to express that we want staggered co-chair terms, which means that elf Pavlik who joined after Virginia left will have a 2 years term. I think you're allowed to be reelected once, so you have a maximum of 4 years.
+* RG: I would keep the text of line 168, just remove the term elections. That is in case you cannot run elections for some time.
+* MdJ: What would be a good reason to not hold elections?
+* RG: For instance, during the summer vacation.
+* MdJ: I don't see that much use for that mechanism. It would be tricky to specify what a valid reason for not holding elections would be.
+* RG: This is meant only for an interim election.
+* HZ: Let's not overcomplicate it; this situation already happened, and the existing two chairs were able to handle responsibilities. 
+* RG: It's only for interim appointments.
+* eP: Is this is comment or an objection to the current phrasing?
+* RG: I only want to remove the word 'election'.
+* MdJ: We only have an election once we have an empty seat.
+* RG: That's also not a good idea.
+* MdJ: We are now in a staggered elections phase.
+* RG: We want to restrict the number of elections.
+* MdJ: If you do a temporary election until you do the election of all chairs, it's the same thing.
+* RG: What about election cycle.
+* MdJ: There is no election cycle. There are three seats, whenever there is a seat vacant, there is an election. Every chair becomes a chair through election, and stays a chair for the full term.
+* RG: You may have elections at an odd time of the year.
+* HZ: This PR has two approvals, if you don't like it Rahul please make a formal objection.
+* eP: as long as we have at least 2 chairs, I don't think there's a problem in practice. It doesn't mean there will be elections every time somebody there is absent. During vacation periods, there is not enough activity.
+* MdJ: I agree with that.
+* RG: I think that if we have an opportunity to make it more thorough, we should take it.
+* MdJ: Are you making an objection?
+* RG: I will make a principled objection.
+* MdJ: It's not helping.
+* HZ: Rahul, please add the comment and then we can have a vote. We are spending more time on process than work in the last year. 
+* eP: I think I understand your approach. It feels a bit like defensive programming, where one tries to anticipate and handle all possible error cases. At the same time, it feels to me like premature optimization. Let's go with this, and if we have a real problem in the future, we can address it in the future. I don't think it will happen.
+* MdJ: https://github.com/w3c-cg/solid/pull/21/commits/8b13eb8481e478d206c4877f4694dcd518768b02
+* TT: I don't think it solves the staggered requirement.
+* MdJ: Yes, it relies on randomness to have the staggering. With current situation, if we appoint Pavlik for 2 years, it will provide continuity when two other chair terms expire in a year.
+* RG: "Any such interim appointments ~~or elections~~ shall hold the seat until the next election."
+* MdJ: Are there any principled objections against this PR?
+* ...: Hearing none we are merging it.
+
+
+### Inaugurate elf Pavlik as new co-chair
+
+MdJ: We had nominations. There were two candidates, but one of them has withdrawn. This leaves us with one candidate.
+RG: Congratulations!
+
+### Identifying clients through `acl:origin` and `acp:client`
+
+* MdJ: Other than identifying clients (bots) who act as agents and have their own WebID, both WAC and ACP have a mechanism (`acl:origin` for WAC and `acp:client` for ACP) to specify a client in addition to specifying an agent for an Authorization (WAC) / Matcher (ACP).
+* ...: However, [historically](https://github.com/solid/web-access-control-spec/issues/34) we haven't had a good way to extract the client's identity from a DPoP authorization. This is still an open issue.
+* ...: In [Pivot](https://github.com/solid-contrib/pivot/issues/64), I'm now trying to fix this for our current system of DPoP-on-storage, but this same fix should also work for UMA-based storages.
+* ...: My conclusion is that Origin header doesn't really work. OIDC doesn't require identifying clients. The dynamic registration uses ephemeral identifiers. The default in WAC is to allow any origin. One fix is to identify applications, the Origin header is not enough. We could look at the audience of the identity token. Using `acl:origin` in a meaningful way is hard; it only works if you add it to all the authorizations in the entire pod — if there is even one without origin, then the unwanted app will have access to it.
+* ...: I don't know how exactly to move past it. CSS silently ignores `acl:origin`, which may give a wrong sense of security.
+* ...: We could implement `acl:orgin` in CSS with a proper way of identifying clients.
+* eP:
+* MdJ: It makes sense for organizations to have bot that acts as a client that has it's own WebId and runs its own IdP. All those 4 things together would be used to access Alice's pod.
+* ...: You can have use case where Tax office gets access to the pod. Alice wants to interact with a bank via the website of the bank. Alice logs in to the website, and the website connects to Alice's pod. The storage doesn't check if the bank is leaking Alice's application anywhere else.
+* eP:
+* MdJ: This only works if there are no authorizations without origin.
+* eP: My conclusion is that as soon as End-user differs from Resource Owner WAC and ACP don't support delegation and we need a mechanism that supports it.elegation is chained further, A
+* Rahul: I can maybe understand 1/4 of what you are saying, maybe this would fit in a special topic meeting?
+* MdJ: That's a fair point.
+
+
+### Blank nodes
+
+* RG: Can we have someone understand us the blank nodes better?
+* JW: What do you want to know?
+* RG: We need a diff format for the solid notifications. It is unclear how to handle blank nodes. I'm pretty confused about them.
+* JW: Blank nodes don't have unique global identifier, by design. There is some entity, we don't have an identifier for it. If you want to do diffs, where you need to identify the blank node in other context, my suggestion is to skolemize the blank node and give it an IRI. We may want to look at Linked Data Event Streams (LDES) 
+*<https://tree.linkeddatafragments.org/linked-data-event-streams/>*.
+TT (Chat): Think of blank nodes like pronouns.
+
+### Web app with its own WebID
+
+* MdJ: While thinking about DPoP I also came up with [this approach](https://github.com/solid-contrib/data-modules/issues/137) where DynReg is disabled on all IdPs, but a user authenticates to an app, and that app then uses its own IdP to generate its DPoP token, so that it can access the user's storage and present a proof of possession of its full identity token without actually leaking it to the storage. Maybe this is a better approach? Let's discuss.
+
+### Call for Review: Adding `solid:storageDescription` to Solid Terms
+URL: https://github.com/solid/vocab/pull/95
+Proposed by SC.