# W3C Solid Community Group: Weekly

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

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* elf Pavlik
* Arthur Joppart
* [Wouter Termont](https://github.com/woutermont)
* [Oz Olivo](https://id.inrupt.com/oz)
* April Daly
* Dirk Roeleveld
* [Matthieu Bosquet](https://github.com/matthieubosquet)
* Maxime Lecoq
* [Ted Thibodeau](https://github.com/TallTed) (he/him)
* Henry Story

---

## 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](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
* Virginia
* Pavlik

### Introductions
* DR: Just listening in. Part of the group for a few years but haven't attended the meetings. Haven't done any development but following activities, and really like ideas behind it. It's got good momentum. Interested in moving Gitter to somewhere else... not sure if in agenda.
* SC: Not in the agenda but we can add it to the bottom and discuss if there's time.

---

## Topics

### W3C Calendar
* SC: It is possible to subscribe to specific calendar events (irrespective of recurring) in W3C Solid CG Calendar.
* SC: The subscription URLs can be obtained by:
1. Go to https://www.w3.org/groups/cg/solid/calendar
2. Select an event and follow/click "More information".
3. Follow/click "Export".
4. Copy the URL of "Download all occurrences as ics".
* SC: Some subscription links:
* [W3C Solid Community Group: Weekly Call](https://www.w3.org/events/meetings/3e68a544-0fe2-407f-9b1e-2032880088a3/export)
* [Solid Test Suite](https://www.w3.org/events/meetings/0b451e91-287a-4987-8905-2ee92cd27355/export)
* [Solid WebID Profile](https://www.w3.org/events/meetings/6641b228-7e45-4762-986e-472aa8deb6db/export)
* [Solid Notifications](https://www.w3.org/events/meetings/8c2508ab-5b61-4203-86ee-81cc7cc84d79/export)
* SC: Let's get the other panels/teams up on the calendar. Ping me when finalised or let me know if I can help resolve.

### PRs on Solid Protocol and Solid Notifications Protocol
* SC: Reminder about some open PRs and to contribute, e.g., review, raise questions/issues, propose changes on the Editor's Draft, or even to raise an objection.
* SC: This is also a great time to contribute with implementation feedback, help with the development of tests.

#### Add TR/2022/notifications-protocol-20221231
URL: https://github.com/solid/specification/pull/491

#### Add TR/2022/protocol-20221231
URL: https://github.com/solid/specification/pull/492

### Agent-Specific Discovery
URL: https://github.com/solid/data-interoperability-panel/pull/291

* SC: Proposed by eP, WT.
* eP: Not sure if we want to discuss in general or a comment in particular (https://github.com/solid/data-interoperability-panel/pull/291/files#r1064623075). My suggestion is to at least refer to SolidOIDC, but in general we try to keep specifications loosely coupled. It'd be good if some spec can stay ??? until there is some loosely coupled mechanism. Authentication should be in place but not provide any details (there should be a good ??? to authenticate... not get into details). Not tying into details of SolidOIDC. We should aim to define something in abstract that other specs can refer to. SolidOIDC provides a specific definitions of how ??? is handled by different specifications. If in the future we migrate to something different from SolidOIDC this spec ???
* HS: I'm writing a client to do Authentication. Trying to write so it is generic and people can fit in implementations for protocols I don't have time to do. [Here](https://github.com/bblfish/SolidCtrlApp/blob/CommandLine/Architecture.md) I have been thinking about AuthN architecture from the client's perspective.
* HS: Trying to show how you can tie together various forms of authentication: Password, Solid-OIDC, OpenID, HttpSig, even e-mail, or others. You can tie all of these together, as shown in the [Client-Sequence Diagram](https://github.com/bblfish/SolidCtrlApp/blob/CommandLine/Architecture.md#client-sequence-diagram). This is from implementation point of view. If I can implement it, that proves abstraction is correct from implementation POV. And we could use the ideas there to build a document.
* WT: It definitely gives an indication of the different mechanisms that could be candidates from being ??? in a list saying which mechanisms are allowing Solid. Foremost question is, do we make another document with this list that we can refer from all other specs, do we add to the Protocol document as a section... ideas?
* HS: There's a general something that can be pointed, this ??? is extensible. You get a `401` with access control rules, client selects AuthZ system, and ???. What's missing is a diagram showing that they are all compatible. You want to build a client that will work on all of these together.
* eP: I think besides having diversity for implementers, too many possibilities and variants, it is a burden to implement all of them. We should narrow things down in visible ways but also be able to evolve. The question is, in the future with new technologies, how do we keep migrating? A way to update the ecosystem specifications, listing all the specs and versions, without having to update every single spec would help. How do we keep reusing the specs and updating the relevant parts?
* SC: eP, can you repeat the concept that is needed at the moment in this particular set of specs, or the one you think needs a general definition?
* eP: The thing I see in different places is distinction between client and user. That's common across OAuth, OpenID Connect, and GNAP. Distinction in ACP is made between agent and client. Also in WAC. Something at this level where we can talk about authenticated client and authenticated end user. For instance, in SolidOIDC here's how you can identify client and user. There are common concepts not linked across all specs. Example: issuer, client, end user... it'd be nice to define those terms, and specs can refer.
* SC: One action we should follow up with is whether those terms or other terms may need to be added to Solid Protocol or glossary. It needs to be in spec at some point. Example of issuer: I understand it is beneficial for its use when defined in SolidOIDC, but I am not aware of other specs using the term.
* eP: ACP has a matcher. Issuer matcher.
* SC: Would ACP work without it?
* MB: Notion of issuer is who is asserting a claim that you are presenting. For example, if it's an identity claim, if you say I own a WebID, I'd have an OpenID provider I point to and trust to prove the request was initiated by me. They will assert I am myself when issuing requests. We need this in ACP but potentially a notion that needs to evolve. Different claims can be asserted by different or multiple issuers.
* eP: When we talk about OpenID Connect and ID token used by SolidOIDC (and I assume ACP), we have work on access grants using verifiable credentials. There's a broader concept of issuer.
* MB: A useful mental model is: in order to access a resource you can ??? different claims, and each claim can be proven by different issuers, or many. WebD is one, VC is another... there can be many different types.
* WT: Maybe you're too deep into specific term. Take PR as a base; see what terms we want to be able to refer to; see which other specifications use these; and, based on that, we can make a proposal to add to either Protocol or separate document.
* SC: I recommend processing that PR separately from definitions. From there, you could extract the definitions. If it's referring to terms from other specs or terms that are missing, we should have an issue, and then figure out where to put them. At some point, it needs to be defined in one spec. If general concept of issuer needs to be in Protocol, we can do that. For that PR, don't worry about that definition. You don't need to wait for those definitions to appear anywhere else before a work item progresses.
* eP: I remember for ??? panel, channel describes sender, we have not yet fully defined it, and we need to have common definitions that we can refer to. Now implementors need to make an educated guess, as opposed to specs using the same concepts consistently.
* SC: Sometimes we do end up using different terms and indicate equivalence. Example, when we mix different ??? in a payload, it is possible for terms to overlap. Like the term "object" used in different ways. Similarly to agent, sender, etc. That happens, but it is spec's responsibility to say when terms are equivalent. When you say "sender", the context is the notifications protocol, so when you say "sender" is talking about the sender in there... or we link to somewhere else and say "sender" is same as "Agent" in Solid Protocol spec, etc. Too much astronomy because in reality we may end up reusing same terms across specs, but in some cases we do need to use the same terms and indicate equivalence.
* WT: You make a great point, but the issue we are discussing is not about using the same term, but about not wanting to define in our specs and there is not yet a definition to point to.
* SC: Start with defining it on your own in that spec. Claim that's your term, and if we find it is a term we need to use in other specs, we can link to it as an authoritative source, or decide we need to move to Protocol or another appropriate place. For now, just go for it and define it.
* HS: Agree. Make your own definition. Can we have a link to rendered version of PR?
* SC: HTML preview?
* eP: We can set up a GitHub action to do that, also to render with bikeshed for the PR.
* VB: There's an issue for that: https://github.com/solid/specification/issues/410. I'm working on it but help is welcome :)
* SC: It is on our "to-do".

### Considerations on Quads and Graphs
* SC: Contributions to existing issues/work welcome.
* SC: Dive into by searching (as per [contribution guidelines](https://github.com/solid/specification/blob/main/CONTRIBUTING.md)):
* https://github.com/search?q=org%3Asolid+quads+OR+graphs&type=Issues
* SC: Plenty to add to. Here are some:

#### Subject-Location Restrictions
URL: https://github.com/solid/solid/issues/81

* SC: Issue by Sandro Hawke, 2016-02-29.

#### Quad support in Solid
URL: https://github.com/solid/specification/issues/291

* SC: Issue by Kjetil Kjernsmo, 2021-07-27.
* SC: Notion of having different graphs is not unique to Solid or Linked Data in general. That's the way of moving things forward. Implementations help, showing how different ways of expressing knowledge in real apps vs hypothetical usage. It'd be good to move these existing issues forward.
* WT: I think it's great to give this overview to start action. On the other hand, I want to mention attempts at actually providing grounds for addressing these issues are not met with friendly welcome as we have seen in the past weeks. I am referring to [Ruben's blogpost](https://ruben.verborgh.org/blog/2022/12/30/lets-talk-about-pods/) and Tim's draft response to it.
* SC: Is this a separate topic on tone or way of approaching?
* WT: It's about the content, namely, Ruben argued for a change in how we view the structure of a Solid Pod, shown with arguments and examples that could address several of the issues in this list.
* SC: Havent seen a single link to these issues.
* WT: He didn't link but he addresses the same issues.
* SC: The issue is not so much that this functionality is wanted or not. This CG exists, issues exists, and the way to make pressure and make CG aware is to either move the issues and things outstanding, PRs (there are a number of PRs on this topic), showing up to this meeting. Not everyone is aware of random blogposts on the web. I'm pointing to issues that existed 7 years ago. No reason not to respond to them.
* eP: I was trying to follow this and read Tim's response but it was empty HTML.
* SC: You can probably find it. I don't want to share because the author might not want to share and we need to give the author some respect. It is about the priority of these things, not one of them needs to be singled out and a blogpost doesn't need to be singled out either.
* HS: Are we sure Ruben wrote that blogpost?
* SC: No conspiracy theories.
* HS: This is not a conspiracy theory, just a question. Ruben's thesis was on hypermedia, and the blog post contains nothing about hypermedia at all. That is odd. If someone could find out that would be nice: it is possible he didn't because it is a bit bizarre.
* Blogpost is all about naming of resources and this is how we come to this questions about quads.
https://www.w3.org/community/rdfsurfaces/
* SC: Let's pause. We have limited time.
* WT: Let's not discuss much further, but I want to mention that there are a number of issues that depend on how we treat graphs in Solid. either sticking with current view or moving to another view has huge effects on how we treat those issues. It's a base thing we need to do before handling those issues.
* SC: If you have strong views or want to tell people how to get involved in pushing existing considerations forwards... We have a CG weekly call, existing issues that we can pick. We cannot have this open forum where we're saying "they said that"... we cannot deal with that in CG. I just want to bring attention to these existing issues.

### Topic Proposal
URL:
Topic: Next Chat framework
Proposed by: Dirk Roeleveld