Meeting minutes
<bendm> I'll be 10 minutes late
Introductions and Announcements
acoburn: No new attendees. This is the 2nd of 3 weeks with EU timezones an hour earlier than usual
… it will go back to usual local time week after next.
Action Items
<acoburn> Action Items
acoburn: There a 3 action items. Can pass over #11 as it is a perennial issue, #15 is owner and controller, #16 is also perennial
<gb> Action 15 introduce both the term owner and controller in the glossary, and clarify their meaning. (on hzbarcea) due 2025-02-24
<gb> Action 11 add categorization to the needs discussion labeled issues (on hzbarcea) due 2025-01-13
<gb> Action 16 present a weekly overview of closed issues in the https://github.com/w3c/lws-ucs/issues repository (on hzbarcea) due 2025-03-17
hadrian: I am inclined to close #11 as we are doing categorisation anyway
<ericP> +1
acoburn: I agree unless anyone objects
hadrian: #16 is about reporting on closed issues. I don't now how the report should be presented - should we add it to the agenda to present?
<ericP> +1
TallTed: Make a running agenda item that can be passed to Hadrian or others. Specific issues don't need to be set in advance.
Hadrian: I can paste the list of issues under than running agenda item each week
acoburn: We could use the wikis on various repositories
TallTed: Issues on GitHub wikis is that notifications are not delivered for wikis
Hadrian: This is not an issue, the idea is to have the information copied from the wiki to the agenda
TallTed: Agreed, unless someone tries to edit the list down prior to the meeting
Hadrian: What we take to the meeting is authoritative. If someone made that change there is a reason.
TallTed: Could also be errors or vandalism. So if you're doing this work; you will not have advance notice that this has happened.
Hadrian: I think we can handle those imperfections
ericP: I suggest we go with Hadrians judgement and adapt if issues arise
Hadrian: TallTeds point is also well taken
<bendm> +1 to adapt improve overcome when the problems arise :)
<TallTed> One benefit of process is it is usually constructed to minimize impact by known defects. Such minimization requires knowledge of those defects. Which I've now provided.
acoburn: Agree with Hadrian, lets starts simple and fix if problems arise
Hadrian: Want to talk about csarvens point about glossary terms pointing to solutions
… I don't think these point to solutions, so I don't understand the issue, think there is a miscommunication
csarven: CID documents are a good example. If we replace the W3C SID definition with WebIDs would people raise an issue
ericP: The difference we want to capture is if we are talking about IANA identifiers or Ledger Identifiers
… however our identifiers are formulated, those are the two different choices we are going to have to make in terms of technologies we use
csarven: The point is not about referencing a definition from a spec. The moment you refer to a term from a spec it is locked in - meaning that the requirement can only be about CIDs. Similarly we should not approve the use of the term WebId which is also well defined. Instead we could generalise and say there is a controller with a given set of
rights and responsibilities; and that controller is uniformly identifiable. From this controller definition we can accept proposals which are based on CIDs, WebIds and other technologies.
… key point is that the use case and requirements document is to capture the needs without tying to the technologies. I think NIST definitions are fine because they don't generally refer to specifically technologies.
… I think the requirement that will come out will be along the lines of "a sever will allow a controller to assign rules to different entities"
… I think the authorisation definition we have is fine because because we are not tying the definition to WAC/ACP/, and similarly the glossary is not tying authentication to Solid-OIDC
… Similarly we should not tie authentication to solid-oidc
TallTed: Yes the CID addresses a very specific set of requirements - which is not the same as listing the set of terms used when collecting these requirements.
… use cases should be fairly high-level descriptions such as "the user needs to change permissions on a particular file" to which there should be a low level set of requirements such as "the system should be able to update or delete particular controls".
… Neither the use cases or requirements should be tied to a particular solution, because we don't know if a particular solution satisfies all of the requirements that we may have
hadrian: I think I wanted to say the same thing. We know this is not a normative document. I agree we want to make progress. I agree that nothing should point to a solution.
… However, this is a definition of a term - I am referring to that CID definition because CID is a well understood to indicate that we use understand that term in the same way that the CID group uses it
… My use of CID is not to indicate that we should use CID as a solution
TallTed: The problem with using that definition which stems from a "religious writing" (specification) is that it is difficult to separate that definition from its context.
… Humans are naturally inclined to infer more than you intend
<uvdsl> +1 to what TallTed says
TallTed: Even if you say in the moment that all you want from the other thing (CID document) is the way CID is conceptualised
hadrian: I understand and agree. How do we make progress?
<pchampin> https://
<gb> Pull Request 137 Definitions for owner and controller (by hzbarcea)
TallTed: See suggestion in #137
<gb> Issue 137 not found
hadrian: Looks good
TallTed: Should use the same principle as #137 in general to avoid unnecessary objections
<TallTed> +1 avoid controversial definitions and/or projects
hadrian: So for things that don't have a widely accepted definition - we should avoid possibly contriversial references
… such as my reference to the CID document
… and just provide a definition
csarven: Yes, and that is the general convention of use cases and requirements
… I think generally the glossary does not need to include every single term. Just needs to clarify things that may be ambiguous to people.
… In this glossary there are 5 terms; Controller, Controller Identifier Document, Identifier ... ??? ... I think we could minimise this to just have a "Controller" and make it a requirement that the Controller is identifiable
… a controller does not necessarily need to have a Controller Identifier Document even if the controller is identifiable along with other core characteristics and capabilities.
… This is not to say that CID isn't a good solution. We just don't need to drill into this in the glossary definitions. We can address all that when spec requirements are proposed.
<csarven> :)
acoburn: When there are suggestions for changes, could we make specific PRs like #137 where possible to speed up getting us to consensus
<gb> Issue 137 not found
Requirements and Links to Use Cases
<acoburn> DID UC&R
acoburn: Last week we discussed the matrix which came from the DID Use Cases and Requirements document
<TallTed> +1000 useful table design!
acoburn: It is a matrix which describes use cases along one axis and requirements across the other to understand where the overlap between use case and requirements are
… would like to discuss where this stands and next steps to get us to this spot
hadrian: I covered about 40 of the use cases, but got stuck this weekend because I used Markdown, which is not easily rendered by the ReSpec tools
… does anyone have suggestions how to make these render better in ReSpec
… I also wanted to note that there is a requirements list in ??? which is an alternative to the Matrix
jeswr: conversion formatting can be done really well with LLMs
… give the LLM an example, e.g. to convert to HTML
<pchampin> my mic is disabled for some reason, but I'm happy to help with the markdown-in-respec issue
TallTed: LLMs are different. Teaching them what you want is challenging. Giving an example of the prompts in one of these PRs would be useful.
acoburn: I think you can also embed HTML in markdown
… Changing topics, can we make sure that we keep links from requirements to use cases in the GitHub repository
… Please take time this week to add these so we can start from a position of greater consensus
… Hadrian could you provide a summary of where we are time-frame wise - and what can people do to move things along
hadrian: I have approx. 40 use cases which I've processed. Once the matrix is in place I would like people to verify. In the meantime adding the backlinks as proposed by acoburn would be appreciated.
acoburn: No more topics, we can end early. Please remember to add links as proposed above.
… remember daylight saving issue persists next week
kaefer3000: I have a breakout day in my calendar - is this happening?
<pchampin> I didn't hear about anything related to LWS
acoburn: I think the answer is no
<TallTed> use the W3C calendar whenever possible, to minimize issues from timezone and daylight saving changes! e.g., https://