W3C Solid Community Group: Weekly

# W3C Solid Community Group: Weekly * Date: 2023-03-29T14: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) * elf Pavlik --- ## 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 * name: text --- ## Topics ### Content of meetings * SC: Do you all feel content of meetings is helpful? * PAC: Don't have enough overview on subgroups work to say. * VB: Maybe we could have panels do status updates. ### 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 * SC: Some of these are easy to resolve, some need discussion. * SC: First open PRs then issues: ### Quote and cite content URL: https://github.com/solid/solid-wg-charter/pull/4 * SC: Editorial change. Multiple paragraphs are copied/pasted from the Protocol directly into the Charter but lacks proper citing. Proposal is to update that. Suggestions/objections? * PAC: I thought this was merged. Very minor thing but stylesheet as it is today makes quotes very prominent (blue background). We could change. Otherwise good to cite. The way the citations are presented now is a bit too disruptive. Even the quotes break stream of the text. Maybe there's a less disruptive way of putting this. Otherwise, no objections to this PR. * SC: Noticed the background color. I can update the PR. * PAC: One quote has been inserted in the PR, but that's from a different PR. * SC: There were two PRs. The other one got merged. ACTION: SC to update stylesheet and merge. ### Clarify and reference Solid Protocol, CG, use cases URL: https://github.com/solid/solid-wg-charter/pull/8 * SC: We have one approval (PAC). This is just changing Solid specification to Protocol, and the other one is reference to Solid Community Group, and the other one where it says Pods I think it means to say server. Fourth is repository with use cases and user stories. We want to put there as much as possible of what the group has done. * VB: Approved. * eP: Approved. ACTION: Merge. ### Fix success criteria (testing, interop, horizontal review) URL: https://github.com/solid/solid-wg-charter/pull/10 * SC: This is trying to align content with the latest Charter template W3C is using. This PR links to an issue mentioning that. And then responding/filling in content based on that. Key areas: testing and interop, horizontal reviews. Main additions are clarifying what will count as interoperable (can be verified with open test suites) and committing to the fact we're willing to work on tests/have a testing plan as early as possible and how to promote interoperability in testing. We have work in the CG around testing, QA. Some of the specs have already been moving in that direction and we already have test suites that are testing that. Building on the W3C QA activities which goes back two decades of work. This is important for any group to show properly how interoperability can be verified and how implementation reports are obtained, etc. The last part is not too different from previous template. * PAC: I see a sentence you did not copy from the template: https://w3c.github.io/charter-drafts/charter-template.html#success-criteria (second to last sentence of this section) * PAC: Was wondering if it was deliberate to omit the sentence, now I see it was not. Since it's part of the template we might as well include. * SC: I noticed in the source code, when you clone this Charter template and look at it I see a different version from the one on the GitHub pages one. Which may explain why we missed each other there (in this PR's comments) * PAC: Maybe GH pages is lagging behind? * SC: The repo says you should clone the GH pages branch, and that's where changes will happen. I can investigate and if you feel we should do what we see now on the website then happy to do that. * PAC: I don't think it hurts. * SC: I can update. Do you want to review after that? * PAC: Happy to approve the PR. * SC: You can out a condition. ACTION: SC to update PR, PAC will approve on the condition that the above is added. * eP: No objections. * SC: Some of the language I use is from prior experience of what I've observed in W3C formal objections to Charters. ### Make deliverables grounded on incubated work in the CG URL: https://github.com/solid/solid-wg-charter/pull/11 * SC: This is one where there were different views (in the comments). My main point is the difference between CG and WG. CG is one of the groups that could propose work towards a WG and it is intended to be where work is incubated, implementation experience and adoption. This is something that the Members/reviewers look for. * SC: Two things in here: one is about acknowledging notifications about resource changes and linking to that. PAC already agreed. Any other objections to including that part (linking to Notifications protocol)? * eP: No objections. * SC: The other part is about the Verifiable Credentials. This is about access grants using VCs. The issue was that there is no spec about access grants. And it is not sufficiently incubated in that we don't have multiple implementations interoping that demonstrate this. This type of thing is being equated on the same grounds as something like WAC, Notification Protocol, ACP, OIDC and so on. There's no spec for access grants, it is not implemented and Solid Protocol does not mention anything about access grants. All the other things suggesting things that will be detailed are fine, because there are specs, work, etc. but that's not the case for access grants. AGs is not checking a bunch of boxes and I think that will be easily caught by reviewers. * eP: In interop spec we have access grants and data grants and they are not exactly the same Inrupt came up with. ??? meeting last month about access grants. I suggested the authorization to access should be represented with a VC. There is work that does not talk about VC directly but will require VC to complete. * SC: There's no interop between the notion of AG and the one that's been worked on by another group? * eP: Yes and they cover different parts iof the problem. If we reconcile they can provide different parts of the ??? In interop there's discovery covered by those. In some ways those parts (scribe note: which parts???) are complementary. * SC: There is nothing that is reconciled in the sense that ??? For example, Solid Protocol refers to many things (WAC, ACP, WebID, etc) but does not refer to any notion of AG in any of the versions you described. There's no single spec/work that is there. I understand there are considerations on how they can work out, but the question is is there enough implementations that are interoping? I understand there are servers that are working, and we have enough implementation feedback, but there's no spec and we need to do that as an indication of well incubated work. I don't see that here. There's hardly one implementation that is also not open source. That's the perspective that I'm looking at. * PAC: There's in fact some implementations, some documentation about Inrupt's ESS, but as you said it is one implementation that is not open source and might be too restricted to be considered proper incubation. * SC: To be fair, it's not that the closed-source is not sufficient for incubation, but that version/implementation differs from the other incubated work that has been done in the interop spec/panel. Not sure what the implementations on that are either. * SC: Bottomline is we could throw all random things that we've been experimenting with or thinking about into this charter. The notion of requesting access is now new in Solid. I even proposed one based on Inbox, and have implemented that work. But I will not ask the group that we should put this in the charter, even though conceptually it is the same ??? There's a list of things we have been experimenting with, but we need to be careful not to throw everything into the charter and expect that it'll actually be taken up. * PAC: I agree with you that we should not include any random idea in the charter. That said, some people have put that here, I hear there are different people working on the idea of including VCs. I think it'd be a shame to close that door, if several people are working on it. Granted, this is not as mature and incubated as the other points on the list, but we don;'t have too many of those either. Also this list of things are points that MAY be addressed by the group. Not too committing. Group might still decide in the middle that this is not ready and will not be included. Success criteria says we need two independent implementations so I'm in favor of keeping it here, as there are not too many random ideas in this charter that it'll be too risky. * eP: Just to emphasize, I don't think it's a random idea. We have a use case in AuthZ use cases about user authorizing a client, which is not currently addressed completely. Combined with Inrupt's AG implementation, this could be addressed. There are some issues, but I don't think it's just about VC but other problems with implementations. I don't see it as a random thing. One of the reasons why Solid Protocol doesn't address it is because it is incomplete. It doesn't address this use case. "Trusted apps" is not a proper solution to this problem. It is definitely not random. * SC: I am aware. You may remember that the Solid CG has a joint meeting with Credentials CG, and one of the reasons why I set that up was because works in that group could be useful to Solid. Prior to that we had not incorporated any of the CCG group's work into Solid, more of less after those meetings was where the group started taking more of their work items into consideration. I'm well aware and in support of using the specs out there that other groups have developed. I was just looking at it from what the Charter is supposed to signal. No judgement about the technology itself. I'm glad we are doing that and we should continue. * PAC: In terms of signal, we could just put some link in the Coordination section. Not having any mention of VCs in a project that emphasized privacy will be a mistake, but I take your point and maybe it should be better to have it in the Coordination section. I'm in favor of keeping it also for the signal that we send that we should coordinate with VC people. * SC: No objection to leaving it in. Just was looking at from the perspective of what the charter communicates that's coming from a CG and its incubation. Let's see how it goes with the Members. * SC: Integration is specific, not a blanket statement about whatever is available from a particular Group, Charter, Homepage, or Whatever - we don't "integrate" specification details with arbitrary documents but instead do it with actual Specifications. (There is a whole thing on Coordination with other W3C Groups which seems more suitable as a general interest.) An exhaustive list of TRs is not required either as there is the notion of normative references that will pick them up. * SC: I don't think we should link to a group or charter. * eP: In that case I think we could link to the VC 1.1 (current) and then coordinations link to the VC WG, I think it's valid that by the time 2.0 is ready, there won't be a problem with charter linking to 1.1. * SC: Isn't the TR latest, and that'd be covered? I doubt anyone would care about the versions. * PAC: latest: https://www.w3.org/TR/vc-data-model/ , specific version: https://www.w3.org/TR/2022/REC-vc-data-model-20220303/ * SC: Is it okay if we only link VC data model? * eP: Yes. * PAC: Yes. ACTION: SC to update PR and merge. * SC: Would it be more appropriate to say AG is within scope of work instead of part of a deliverable? Because it seems that it's well within the scope, see issue #9. * PAC: I see your point. The current phrasing does not entail a strong requirement to include all these parts in the final specification(s). WG might decide to split specs into several in the end. Current phrasing does a good job of including it in the scope. Not sure worth moving to another part. ### Clarifies necessary coordination with W3C Groups that Solid Protocol reaches URL: https://github.com/solid/solid-wg-charter/pull/12 * SC: It fixes all links (existing ones in original version). PR uses proper links of WGs and CGs. The other is a mix of different groups listed, I don't expect heavy coordination with these groups. In the past we have only coordinated with two groups (CCG, Web Platform Group). And we got an understanding, CCG helped a lot. It's good to list some of these. N3 CG as example: possible some of this work like the N3 Patch could be offloaded to them. It is not something that the Solid Protocol should necessarily standardise but looking in the direction of N3-CG or RDF-DEV perhaps. * SC: I will follow PAC's guidance on this. * PAC: I think it's more convincing to have short sentences on why we think coordination is important. As to the number of group, such a long list is a bit unusual but all of it makes sense so I have n objection to merging as long as we make it homogeneous and have a short explanation of the rationale behind each group mentioned. * SC: If we update the details, is it okay to merge? You can review the descriptions of course. Any group strikes you as should/should not be there? * PAC: Solid CG should be listed. Nothing there strikes as out of scope. ACTION: add Solid Community Group, remove Web Applications, update descriptions. * SC: Do you want to review after this update? * PAC: I would rather review after those changes, and have a different person merging than the author. I can do that. * SC: How about the other PRs? * PAC: In general. Everything we decided to merge, I can merge. * SC: I'll update the PRs and hand it off to you. * eP: Agree on having rationale. What I see missing is something like external coordination (for example like, https://www.w3.org/2022/06/verifiable-credentials-wg-charter.html#external-coordination). Such as OpenID Connect and ??? * PAC: I totally agree about adding OpenID Connect. Coordination with other groups might be good but let's not put too much on our plates. I'd be more reluctant to include ??? * eP: Makes sense. * SC: Should PR from eP go ahead then? * PAC: Yes. * SC: eP, if you want you can make a change request or separate PR. If you make a separate one, make it after this. * eP: Not urgent. Let's finish this one up and I will make a small PR. * SC: You can request changes on this PR too, simpler. * eP: Sure. ### Update AC Review of a Charter section URL: https://github.com/solid/solid-wg-charter/pull/18 * SC: This is just editorial. There was a section number different with the template. * eP: I did approve. Various PRs changed the ??? maybe the draft was an older template? * SC: There is an issue about using latest template. * PAC: The structure of the new template changes some sections that are not in the same place, I suggest we reorder the sections once it is stabilized. However, these minor changes re: section numbers should be done ASAP. Approved. ACTION: Merge. ### Acknowledge Solid apps as part of incubation URL: https://github.com/solid/solid-wg-charter/pull/22 * SC: PAC already approved. * VB: Approved. ACTION: Merge. ### Timeline for submitting the Charter * SC: What should the timeline be to submit the charter? * PAC: I think we should definitely send the advance notice to AC ASAP. We can end it with some PRs pending. It is to let them know work is ongoing. We should not wait, and then continue amending. Once this is done, this is the team's decision to submit to vote when things are stable. I'd not be too eager to define a schedule. * SC: Some of these issues could be important for the charter. Example: the issue with the "pod" term (issue #3). There's wide consensus in the CG about not using "pod" in technical texts. I don't think we should communicate a term that's used elsewhere and not well-defined. Not a term controlled by Solid CG. I strongly suggest issues like that should be PRd and make sure AC sees the terms that are actually technical/mentioned in specs, not a marketing or informal term. * SC: Would you welcome a PR for that being merged before AC looks at it? * PAC: I don't have a strong opinion. I see what you mean about the term. The term might be used in the wild, but this is a technical Charter. No strong opinion either way. * VB: Agree on not using "pod". * SC: There is one other agreement from LD. * SC: People doing review might join the call to discuss their own issues/PRs once reviews start. We can take them up along with other open issues/PRs. ### Use latest charter template URL: https://github.com/solid/solid-wg-charter/issues/2 * SC: Already ack'd by PAC. ### Use technical terms from Solid TRs URL: https://github.com/solid/solid-wg-charter/issues/3 ### 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 ### Scope needs to be tightly defined with narrow focus URL: https://github.com/solid/solid-wg-charter/issues/9 ### Review from TAG should be requested prior to Member review URL: https://github.com/solid/solid-wg-charter/issues/15 ### Fix Timeline view to list deliverables, not sections of a deliverable URL: https://github.com/solid/solid-wg-charter/issues/20

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.