Add 2022-11-09 agenda and minutes

meetings/2022-11-09.md

@@ -0,0 +1,116 @@
+# 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, please indicate, put your hand up or plus queue in sidebar, we follow solid and w3c code of conduct. Links are there, happy to answer any questions. We try to make these calls accessible to you, if time or other concerns, please mention and we'll look into that. If this is your first time, welcome and you are welcome to introduce yourself. Jeff volunteereed to scribe. 
+
+
+
+### Forming a W3C Solid Work Group
+URL: https://lists.w3.org/Archives/Public/public-solid/2022Nov/0001.html
+
+* SC: TimBL's announcement, Tim wrote an email last week suggesting 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. 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 cause we are implementing interop spec and in Solid it is law that everything you do with data through a client or client app, so if client identifier exists, webid or client id, it could be useful to include it in web access control, cause then we can restrict access not just on social agent but on client, like when Tom uses this application, 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 (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; as well as 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, it 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.  So there are different access models you may be familiar with. I'll drop this link here, not to diverge from this topic but to take into account scope of authorization methods. https://github.com/solid/authorization-panel/issues/121 . This gets into heart of whether actor aspect is within the scope of something like ??? or ???, solid is not considering, attribute based access model, don't want to get into that now, if question is can solid have this other thing, that's what we want to look into. 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 have server decide which client should access resources which gets complicated, maintenance nightmare, and some decide your 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 which 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 and for client and end user was a good exercise. Given the example how does proposal address the use case. The one before, Use case #251, 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, we run into trouble, we are implementors, but alot of use cases request this feature, not a single one of use cases we support in production, they want impersonation, so we want to avoid that any app user 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 model, 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 plus (minor enhancements to WAC). You can usually get far with very little <https://github.com/solid/authorization-panel/tree/main/proposals/evaluation> 
+* 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 out at these meetings. There is always a solution on paper, but eventually comes down to a commitment to implement. Maybe one property is not a good way to do it. Drop in some information in the issue to move that 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, and we can expand that, relate 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 also the test suites, how they are using the info in the specs. The test coverate would include the spec terms. And we have applications using these. And there are ways to look at the requirements and see which requirements don't have a test case or if 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 may share my screen, if you can see my screen, say ok or no. (ok)  So this is the version that is PR'd. We have a conformance section, so we create issues to clarify the conformance classes, so 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. And 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 should that 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 vairability spec, authors should consider how they structure their specs, classes help with conformance. Not exhaustive list. The recommendation from W3C is 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 ??? is coming from another document, so this is 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 defnitions of how we compose specs together.
+* SC:  spec and identify the requirments. 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, and publishing 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: Alot of things were a work in progress, part of it comes down to committing to canonical or term, if you are refering 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 inhertiance v composition discussion. Solid OIDC could define a subclass of sold 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. Some documents we may need to do it differently than 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 alot we can do with basic linked data and spec terms, if we can take advantage of it, that would be great cause alot 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 looks and 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. I'll drop a link: 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. And 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.