# W3C Solid Community Group: Weekly

* Date: 2023-04-05T14: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)
* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me)
* Alan Davies
* Jeff Zucker
* elf Pavlik
* michal/mrkvon
* [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/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

### Introductions
* Alan: Individual participant of CG, from Verifiable Credentials world, looking to see how we can make these two technologies work together.

---

## Topics

### Overview of today's agenda

* SC: Today's meeting will focus on the Solid WG Charter that follows 2023-03-22 meeting topic for reviews: https://github.com/solid/specification/blob/main/meetings/2023-03-22.md#solid-wg and continues on topics in 2023-03-29 meeting: https://github.com/solid/specification/blob/main/meetings/2023-03-29.md
* SC: First open PRs then issues:

### Use w3c/charter-draft's template
URL: https://github.com/solid/solid-wg-charter/pull/24

* SC: Resolves https://github.com/solid/solid-wg-charter/issues/2 . Already ack'd by PAC in https://github.com/solid/solid-wg-charter/issues/2#issuecomment-1479836619 . Assigned to PAC.
* SC: This PR is a complete update of the template, not only structure but also content. Changes are as close as possible, does not change anything new from the template recommended by W3C. There's one change suggesting by PAC which was merged. PAc already approved the PR.
* eP: I'd propose if PAc can merge it so we can see the other PR with proper diffs, open for a few days and it's been approved. Quite safe to merge.
* PAC: Happy to merge. Not sure what happened to the other PR with additional change I suggested and Sarven accepted. I put links to a diff tool with the correct URLs so the changes can be seen. I'm happy to merge right away and see what happens.
* SC: I was planning to see if the other PRs will be an issue, if the fix is simple I'd revert and push.
* SC: Any objections?
* SC: No objections.

ACTION: PAC to merge.

### Use technical terms - storage instead of pod
URL: https://github.com/solid/solid-wg-charter/pull/25

[More convenient diff](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fraw.githubusercontent.com%2Fsolid%2Fsolid-wg-charter%2Ffix%2Fcharter-drafts-template%2Fcharter%2Findex.html&doc2=https%3A%2F%2Fraw.githubusercontent.com%2Fsolid%2Fsolid-wg-charter%2Ffix%2Fuse-technical-terms-storage%2Fcharter%2Findex.html)

* SC: Resolves https://github.com/solid/solid-wg-charter/issues/3
* SC: Storage is a concept with a definitions in Solid Protocol and Pod is not.
* SC: Questions or feedback?
* eP: *thumbs up*
* PAC: I have mixed feelings about getting rid of the term Pod. Appreciate it is not a technical term but associated to Solid. Not having it at all in the charter might be confusing to people who have not followed the technical discussions. The replacement is probably appropriate in technical sentences, but I think it's a shame not to have the term *at all* in the charter.
* SC: An improvement: introducing in brackets somewhere early on the notion of a Pod somewhere. That will require an update to this PR.
* JZ: I strongly agree. It's a term in public use, so to ignore it puts us in a dangerous position. If we're gonna use it, we better define it. If we're using it essentially as an alias for storage that makes things simpler. We don't need to have an additional concept. If it's more complex, involving a relationship between WebID and storage, it gets more complicated to explain.
* PAC: Not sure the Charter is the right place to invent a new definition for something used informally. Maybe something like a parenthesis after the first introduction of Solid storage (also informally known as Solid Pods). Not precisely defining but acknowledging.
* JZ: I can live with that.
* eP: I think PAC has a good suggestion. Since we link to the current draft and it's using storage, it is less confusing to talk about solid storage since that's what's currently defined in the current Solid Protocol.
* TT: I made a [suggestion in the PR](https://github.com/solid/solid-wg-charter/pull/25/files#r1158590093) that does this.
* SC: That works for me.
* TT: There seems to be a move to eliminate the term Pod from all technical documents, and this charter is about technical documents.
* SC: eP mentions "informally", I think that works.
* SC: The notion of Pod is not just interchangeably with storage, it was meant to cover a bunch of components: storage, server, maybe IDP, etc. coming together which is something a user can have, a system that helps them manage and control their data.
* TT: ???
* JZ: I'd hope we'll arrive at a best practice that says, if you use the term Pod, have a parenthesis explaining how you're using the term. Storage is well-defined, Pod can be ambiguous, brackets are needed to explain.
* SC: That's a good clarification, it is one feature of the term Pod.
* JZ: I prefer "informally" to other words. JJ
* JZ: I like this.
* SC: If no other suggestions we can commit to this proposal.
* SC: PAC, may I add this suggestions and assign you to merge?
* PAC: Yes.
* TT: This is calling it storage as a singular. Makes sense to keep singular everywhere else.
* SC: Yes.

ACTION: PAC to merge.

* AD: *leaves meeting, sends regrets on chat*

### Update scope - remove client-client
URL: https://github.com/solid/solid-wg-charter/pull/26

[More convenient diff](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fraw.githubusercontent.com%2Fsolid%2Fsolid-wg-charter%2Ffix%2Fcharter-drafts-template%2Fcharter%2Findex.html&doc2=https%3A%2F%2Fraw.githubusercontent.com%2Fsolid%2Fsolid-wg-charter%2Ffix%2Fscope-remove-client-client%2Fcharter%2Findex.html)

* SC: Resolves https://github.com/solid/solid-wg-charter/issues/23
* SC: Part of https://github.com/solid/solid-wg-charter/issues/9
* SC: Part of a series of considerations around scope (issue #9). Original call for WG was focusing on Solid Protocol which is largely server-client.
* SC: We have PAC and eP approval. Assigning to PAC. Questions or objections?
* SC: No objections.
* JZ: Yes, client-client should be on its own not part of the WG.

ACTION: PAC to merge [pull#26](https://github.com/solid/solid-wg-charter/pull/26).
ACTION: TT to make further suggestions via PR following merge of [pull#26](https://github.com/solid/solid-wg-charter/pull/26)

* PAC: Will do those after next meeting. Need to leave now.
* PAC: *leaves meeting*

### Scope needs to be tightly defined with narrow focus
URL: https://github.com/solid/solid-wg-charter/issues/9
* SC: We have one agrements in the community about this issue, having tightly defined scope. Previous topic w(PR) was about that.
* SC: When I created this issue the scope seemed to be everything we're doing in the CG, or anything that could potentially fall under Solid Pods. That felt too broad, considering the focus was on Solid Protocol. There could be best practice guidelines which are still under development or have not been incubated in the CG. More interestingly, the part suggested to be passed as BP is out of scope for the WG.
* SC: I read "recommend a set of practices" as "best practices or guidelines". If it were requirements it'd be a deliverable, but this seems to be BP&G.
* SC: In the Charter "out of scope" has two parts: definition of identify mechanisms and definition of linked data formats. The part about set of practices is a very broad thing being thrown in. I'm not sure if we need to recommend best practices around AuthN or identity where, for example, we're also thinking those are out of scope. If we do anything about identity mechanisms, we could do best practices, but this seems to be reaching to far.
* eP: I'm not sure if the intention wasn't to somehow mention that we'd try to build on other standards. I guess it might have been formulated in this way to have flexibility around normative requirements or recommendations but not committing to requirements.
* SC: May I ask eP to chime in in this issue? For us to translate this issue into a PR we need to remove some ambiguities. If you could say in what ways something would be within a practice and which ways out of scope, we can update the language. Right now it is virtually everything we do in Solid and I don't think that's the intention of the Charter.
* JZ: Not directly on this point, but when you say identity and mention other several large topics out of scope, is there a place within Solid where that's a part of?
* SC: Good question. That is what we're doing in the CG. For example WebId-Profile falls under that category. It's a client-client spec, and we need to incubate that. What we are saying in the Charter is they are not intended to be part of it or in scope. Both in terms of client-client and also being an approach towards identity.
* JZ: I'm thinking of a conversation I had recently with someone who has big ideas on infrastructure and the relationship between an URI and identity. Not client-client and not even server-client, but something that Solid needs to be thinking about.
* SC: That's under the CG. New material or things that needs to be conceptually worked out, spec'ed, incubated, or needs adoption falls under CG, in general. For example, if we had a lot of implementations with a lot of user adoption out there for WebID-Profile spec, or Type Indexes, we could make an argument that we have a good sense of how it works but needs to be spec'ed, so we'd need it to be part of the Charter, but we're not there yet. The purpose of CG is to move us closer to that so that it can be picked up by WG. Hope that clarifies.
* JZ: Yes. WG has a specific charter and CG does everything else.
* SC: Yes. If it's mature enough to be further worked on, it should be carried out by WG towards a recommendation. CG basically graduates specs towards that. If you look at TR homepage/index of work items, we know not all of those are as mature as they can be. There's a lot of activity, but some items are not hitting all those things sufficiently. It's not about favoritism of solutions, but makes it easier for the Charter to be accepted if there is sufficient incubation.
* JZ: For example, WebID-Profile and Type Index, those are client-client, so if those are out of scope they will never graduate to WG.
* SC: In this particular charter. That's one criterion for this charter (server-client) but there's other criteria for incubation.
* JZ: That clarifies, thanks.
* eP: I have [a good example (solid-oidc/issue#219)](https://github.com/solid/solid-oidc/issues/219). Talks about security considerations regarding Solid-OIDC issuer. This is very important because it is the foundation of security. It's an example where I think there can't be one normative statement that makes sure this is taken care of, more of a best practice informing not allowing this statement to be altered. That could be a concrete example.
* SC: Comment on the issue, but do not go too deep on the issue. We shouldn't get too into the considerations around that particular issue. Just have a sense of the set of issues that are intended. You can use an example in brackets, but I wouldn't highlight it as a discussion point - not the center of this issue.
* SC: JZ, if you could also chime in with your feedback in the issue that'd be great.
* JZ: Generally it sounds good to me. I think eP is right that there needs to be a place to say something along the lines of that issue. That seems to me to be a server responsibility, who else could prevent changes to the oidc issuer? That seems to fall within the scope of WG. Who else would implement such a security policy other than. a server?
* SC: If it's about security/privacy consideration, we already have sections for it in Solid Protocol and those details can be mentioned there. That doesn't need to be mentioned as in scope. What's intended in the scope here is what other high-level material that could be potentially spec'ed. That could be a new deliverable/non-normative document that could be spun out. If it's general considerations that does not need to be mentioned as in scope. If it's a new document, I am not sure we have enough material to tackle that. Item 3 lists a lot of things, like security considerations for all those documents. Verification for example,has not been incubated or spec'ed in Solid Protocol. We do not have that material, and we're not in a position to recommend BP&G as to how verification should be. If we had a lot of material spec'ed we'd be in a better position to make those recommendations.
* SC: There's 2 items here, one about best practices to request and grant access. We covered that as something we can potentially detail in another PR. But the Best Practices of that is not something mature enough. The next item is about state synchronization regarding changes to resources in Solid Pods. I have no memory of any ort of state sync work done in the CG, whether it is being spec'ed or any implementations, or even applications demonstrating that. IT's hard to say it's in scope when it has not been incubated.
* eP: We should check with the author of this sentence if it means to talk about Notifications, as it follows the state.
* SC: Yes. We already said Notifications protocol is a part of the protocol we can expand on. If it's hinting at notifications, then it's already covered and doesn't need to be mentioned.
* eP: There's duplication in deliverables/scope.
* SC: I think I'd like to ask PAC to assist with scope and deliverables. The deliverables are concrete things that we will give. Scope will be things that are still within consideration of the work. For example, we use WebID, I'd consider the possibility of using DIDs still within scope of Solid Protocol, but I wouldn't list it as a deliverable. When the WG happens that discussion can continue and if it seems feasible to use DIDs as interchangeable identifiers, that might be what's in the scope, but right now it is not a deliverable. Similarly, out of scope is: we will not be coming up with a new identity mechanism.
* SC: Let's continue on the issue, please chime in on other issues.
* SC: eP mentioned something earlier about connecting the WG and CG more clearly. That would help. If you'd like to create an issue we can work on it and pick it up next week.
* eP: *thumbs up*

### Clarification on Solid and comparisons
URL: https://github.com/solid/solid-wg-charter/issues/5

### Update mission
URL: https://github.com/solid/solid-wg-charter/issues/7

### Review from TAG should be requested prior to Member review
URL: https://github.com/solid/solid-wg-charter/issues/15