diff --git a/meetings/2022-11-09.md b/meetings/2022-11-09.md new file mode 100644 index 00000000..779a72c3 --- /dev/null +++ b/meetings/2022-11-09.md @@ -0,0 +1,120 @@ +# W3C Solid Community Group: Weekly + +* Date: 2022-11-09T14: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) +* Jeff Waters +* [Ted Thibodeau](https://github.com/TallTed/) +* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me) +* elf Pavlik +* Arthur Joppart +* [Henry Story (bblfish)](https://mathstodon.xyz/web/@bblfish) +* [Wouter Termont](https://github.com/woutermont) +* [Huw Diprose - (GDS)](https://github.com/huwd) +* [Tom Haegemans - (Digita)](https://use.id/tom) +* Laurens Debackere (Flemish Government) +* April Daly +* [Matthias Evering(ewingson)](https://solidweb.me/testpro/) +* Eric Jahn + +--- + +## Announcements + +### Meeting Recordings and Transcripts +* 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. + + +### 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 +* Jeffrey +* Virginia + + +### Introductions +* AD: Hi, my name is April Daly, I'm in NY area, in my corner of world, I'm knowledgeable of web technology, but i'm new here and my formal background is chemistry and I've been doing lab automation for most of my career. Thank you. +* SC: Happy to have you. Other intros? (none) + +--- + + +## Topics + +* SC: Today's topics are intended for awareness and build engagement as opposed to solving technical details here. + + +### Agenda and Minutes + +* SC: Agenda is typically PRd at https://github.com/solid/specification/ +* SC: Reviews on the PR are welcome. +* SC: Previous meeting's minutes are at https://github.com/solid/specification/blob/main/meetings/2022-11-02.md and you can always find prior minutes at https://github.com/solid/specification/blob/main/meetings/. +* SC: Please note that unless there is a decision to change the meeting datetime, it is always on UTC time (and daylight savings time is not observed, as it stands). + +* SC: Please speak clearly and slowly to help with transcribing. +* SC: Feel free to note things to say while in speaker queue below scribe's live transcription. +* SC: Editorial help with transcription is welcome, e.g., where scribe marks `???`, adding links, fixing grammar, or typos. However, do not change or elaborate on earlier transcription, especially what was not explicitly "aired" by the group. +* SC: These meetings are not recorded; they are transcribed. If you do not wish to be transcribed, please indicate such when you put your hand up or `q+` in sidebar. We follow [Solid](https://github.com/solid/process/blob/main/code-of-conduct.md) and [W3C](https://www.w3.org/Consortium/cepc/) Codes of Conduct. Links are there; happy to answer any questions. We try to make these calls accessible to you; if you have time or other concerns, please mention, and we'll look into it. If this is your first time, welcome, and you are invited to introduce yourself. Jeff has volunteered to scribe today. + + + +### Forming a W3C Solid Work Group +URL: https://lists.w3.org/Archives/Public/public-solid/2022Nov/0001.html + +* SC: [TimBL wrote an email](https://lists.w3.org/Archives/Public/public-solid/2022Nov/0001.html) last week, suggesting that the work we are doing to date has matured to the point where we should try to transition some of the work items to a Working Group setting. Please read [the post](https://lists.w3.org/Archives/Public/public-solid/2022Nov/0001.html). That will take some time — need to draft charter; W3C needs to accept; we'll see on timing in the new year, not too soon. If Tim joins, he can give overview and direction. Any comments? (none) +* + + + +### Client identification +URL: https://github.com/solid/web-access-control-spec/issues/81 + +* SC: Topic proposed by TH (and nudged by WT). +* SC: I'll give Tom a chance to air their thoughts and concerns. +* TH: For us, important topic because we are implementing an interop spec, and in Solid, it is law that everything you do with data through a client or client app. If client identifier exists, whether WebID or `client_id`, it could be useful to include it in Web Access Control, because we can then restrict access not just on social agent but also on client, like — when Tom uses application_x, he can only edit or see this data and not other data. This would be an important feature for us. +* EP: I'll drop a link — [`uc-2.5.2-client-constraints.md`](https://github.com/solid/authorization-panel/blob/main/proposals/evaluation/uc-2.5.2-client-constraints.md). We talked of something similar when access policies take into account the agent (end user, social agent) and the client (application, software agent; potentially including specific instance thereof). Is that what you are referring to? +* TH: Yes, but ... +* WT: Access control rules, +* SC: Summarized months ago, a unit, a part of authorization, the actor is one of the parameters of authorization. We have the agent (social entity); the question is, do we want to introduce this other unit about client, to distinguish the software as opposed to the living thing. There are different access models you may be familiar with. I'll drop [this link](https://github.com/solid/authorization-panel/issues/121) here, not to diverge from this topic, but to take into account the scope of authorization methods. This gets into heart of whether the actor aspect is within the scope of something like WAC or ACP - they're. We are not considering all of 121; don't want to get into that now. Question is whether Solid can have other access models; that's what we can look into in 121. Part research, part implementation; we don't need to solve that problem now. So, why client might be relevant or within scope? There is a separation of social entity from software, so it's within scope. Do we have it? Do we need it? What would conformance look like? I raised questions for what we need to look at. +* HS: It makes sense to identify user agent, but it would be helpful to have use cases for why you want this, because there are other mechanisms to get you what you want, rather than having the server decide which client should access resources, which gets complicated, a maintenance nightmare, and some decide their website only works with Mozilla not Chrome. Who maintains that? Not a good web. Exceptional circumstances where that makes sense. Better that agent that is signing request is making decision. If use cases you can describe are real, then one could say this could work this other way, and we could add to the use cases, and that would be helpful. +* EP: I think we should work with use cases. I posted a link; also the first thing I heard before — ACP for client and end user was a good exercise. Given the example, how does the proposal address the use case? The one before, [use case 2.5.1](https://deploy-preview-152--authorization-panel.netlify.app/authorization-ucr/#uc-trusted-applications) — how does ACP address this use case? A good exercise where we have use cases for requirements, then checking if ACP or WAC addresses that use case. [2.5. Permissioning Applications](https://solid.github.io/authorization-panel/authorization-ucr/#uc-applications) +* TH: Actually the reason we wanted this is we ran into trouble. We are implementors, but a lot of use cases request this feature; not a single one of the use cases we support in production; they want impersonation, so we want to avoid that any app used by uses can access all data of the user. So if you use a fishy app to check something, it shouldn't be able to access web browser. This is our use case — to avoid impersonation, and that any app can use your token to view any data. So we need a client_id in access control rules. We aren't the only ones. UMA also (User Match Access). +* SC: Quick comment: the access models of ACP and WAC. If you look at framework, they are in the same category, so if distinguishing is useful, the argument still holds for WAC or other access mechanisms that are actor-centric. The question of having the client identifier is a solution to the use cases that Pavlik shared. Whether a single property or many or a whole spec is a separate question. +* HS: I think Elf made a good proposal, that one should clarify the use case, which in this case is impersonation; and then one can look at how to deal with it. Different ways, for example would be ACP, WAC, WAC+ (minor enhancements to WAC). You can usually get far with very little +* HS: That's a good exercise. What are the pros and cons? OpenID is widely used and uses HTTP connections. +* SC: We don't have to go through how that would work at these meetings. There is always a solution on paper, but eventually it comes down to a commitment to implement. Maybe one property is not a good way to do it. Drop some information into the issue to move it forward. That includes proposed solutions. We'll continue. Your contributions are helpful! + + +### Spec Conformance, Quality Assurance + +#### Update conformance model +URL: https://github.com/solid/specification/pull/478 +* SC: So this is more of a heads up or intro to the group to develop this initiative. I'm using these as examples, [PR for updating conformance model in protocol and Spec Terms](https://github.com/solid/vocab/pull/84), classes and properties to describe the spec, concepts, requirements, so the document is human and machine readable, so each comment has a URI, self-describing, human readable statement about it, conformance clause, and it will say what is subject, what needs to be implemented. We can expand that, relate one requirement to another requirement, so we have that possibility. Spec Terms allows us to get into that level of how we express our specs and the test suites, how they are using the info in the specs. The test coverage would include the spec terms. We have applications using these. There are ways to look at the requirements and see which requirements don't have a test case and whether we have implementation reports, or different consumers of the spec to improve the conformance model, test suites, application developers or other consumers of spec. + + ... So to come back to the PR, I will share my screen. This is the version that is PRed. We have a conformance section, so we create issues to clarify the conformance classes; what is spec asking? what products? what conforms to those requirements? like a server, or identity provider. The better we can distinguish the products, the better we can test, products could be swapped. Up to now, Solid protocol expresses everything as a server or client, but that is just one way of looking at the protocol. There is an issue about that, and I'll drop that link in the minutes. + + ... So this is the issue #480, asking if we stop with server/client or need more granularity on products tested. Right now we test server and client, so new requirement says "Server must ..." or "Client must ..." but you could say "Consumer must ...". It's talking about storage, but server is target of conformance at the moment. Should we split server into storage, processor, etc? We have a section on N3 patches; there is a model syntax; there is a processor at the end of this, an N3 patch processor to inspect payload. Question is whether that should be a requirement about the processor as opposed to the server. Right now we test server and client. You are welcome to give feedback if those definitions should be developed further. Specification categories, so we can say that spec is about some set of events, some processor behavior, what is considered interoperable in solid protocol is server and client, but relationship of products can be different. Maybe I will show quickly why we are doing all that. +* SC: A whole quality assurance and variability spec. Authors should consider how they structure their specs; classes help with conformance. Not an exhaustive list. The recommendation from W3C is that each spec should specify its own class of products. This is what we are doing here. URI/concept. What you are looking at is spec terms vocabulary and linked in PR, classes and properties of how you describe a spec. This is at the moment in some of our specs which allows us to do, I won't get into it much now, but if you can see my screen, once it is machine readable, you can extract requirements from the spec as you can see table here. Another example, I shared a screencast of this. What it does is these three columns (requirement level, subject, statement) are coming from the spec, and the coverage is coming from a separate document, it only has coverage and test cases and it refers to a requirement, linking back to the spec. Here you can see as editor/author, we don't have a test case for that particular requirement, or that requirement doesn't seem to be specified well. So a simple view of how that info comes together. I'll stop there. +* EP: Thank you. Great work for formal definitions of things, important for me to see how we do it across specifications. Sold protocol says Solid IDC defines how ???, just an excerpt, doesn't say how the classes are composed, storage needs to implement IDC server, or something needs to be implemented, so good to formalize, rather than from gut feeling, so good to have formal definitions of how we compose specs together. +* SC: spec and identify the requirements. I agree it's an art how you can express conformance clauses, guidance in one template, one template useful for one class of products, but maybe a different one for another product. The other part is some things, we need to work together on test suites. Solid IDC has its own tests, a uniform way of communicating the tests, how we prove them, publish the implementation reports, and so on. I'm not saying it is all figured out, but we need to experiment as far as technology allows us to and cross fingers. +* EP: I think a good starting point in Solid protocol; the resource server matching is not explicit. My implementations have to come with conformance tools to apply to both. +* SC: A lot of things were works-in-progress; part of it comes down to committing to canonical or term. If you are referring to product in another spec, as an editor, you have license to be creative about it, use language; if not too creative, use terminology from spec itself. You can distinguish Solid protocol server from another server from another spec, by linking to it in terminology section. You can experiment, but _Solid server_ in terminology spec refers to _Solid protocol server_, so there is consistency in that document. Perhaps that comes closer to what you are asking about? +* EP: It brings to my mind the inheritance Vs. composition discussion. Solid OIDC could define a subclass of Solid server which also conforms to Solid-OIDC Resource Server class, or Solid protocol vX.X defines that Solid server has to implement Solid-OIDC vX.X RS. How we are coupling those specs? +* SC: Can I ask that we continue this discussion. These distinctions that you want to make, if we can develop some conventions in our own specs, we can go from there. We may need to do it differently for some documents than for other documents. Interplay between how we want to do the tests. Let's continue this. +* LD: Can you put your links in the notes? +* SC: They are in the PRs. +* LD: I see, thank you. +* SC: I know it is overwhelming. Let's continue to have chat discussion as to what is where and if you are missing something. Hoping we can lean on W3C work. There is a lot we can do with basic linked data and spec terms. If we can take advantage of it, that would be great because a lot of units of info in our specs. When we are going into a working group, the work we are doing so far, although in a community group, it's a long prep of the group to be comfortable with language and practices of working group so we are comfortable. No demand that things are machine readable, but when we propose specs transition from working draft to proposed recommendation, the more we check these boxes, the more templates we use for conformance clauses, the better it looks and the easier to show we've done our homework. To communicate to a human, we don't need that, but it is more attractive and shows we've done our homework. Let's continue in the chats. We do need to work with [test suite team](https://github.com/solid/process/blob/main/test-suite-panel-charter.md). There is a charter. It gives an outline of where we are going with some of that work. We have the specs machine readable, policies and procedures for authoring the tests, and testing and implementation reports. So at some point we need to show interoperable implementations, that we have adequate implementation of each feature, and what classes of products — is it a data model spec, or protocol spec? — and that helps to write the spec. +* SC: You are welcome to chime in on PRs or otherwise. We have 2 minutes left, I'll pause if any last remarks. (none) Thank you everyone.