13:53:46 <RRSAgent> RRSAgent has joined #lws
13:53:50 <RRSAgent> logging to https://www.w3.org/2025/06/02-lws-irc
13:53:50 <Zakim> RRSAgent, make logs Public
13:53:51 <Zakim> please title this meeting ("meeting: ..."), laurens
13:54:10 <laurens> Meeting: LWS WG Meeting - 2025-06-02
13:54:17 <laurens> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250602T100000/
13:54:17 <agendabot> clear agenda
13:54:17 <agendabot> agenda+ Introductions and announcements
13:54:17 <agendabot> agenda+ Action Items
13:54:17 <agendabot> agenda+ LWS Protocol Editors
13:54:17 <agendabot> agenda+ Use Cases & Requirements Updates
13:54:19 <agendabot> agenda+ Discussion: Authorization
13:54:39 <laurens> chair: laurens
13:58:17 <gibsonf1> gibsonf1 has joined #lws
13:58:47 <hadrian> hadrian has joined #lws
13:58:59 <acoburn> present+
13:59:03 <hadrian> present+
13:59:54 <eBremer> eBremer has joined #lws
14:00:40 <gibsonf1> present+
14:01:20 <TallTed> present+
14:01:30 <AZ> AZ has joined #lws
14:01:38 <AZ> present+
14:01:48 <pchampin> present+
14:02:10 <eBremer> present+
14:02:22 <uvdsl> uvdsl has joined #lws
14:03:20 <hadrian> scribe+
14:03:26 <uvdsl> present+
14:03:51 <hadrian> laurens: first agenda items and announcements
14:03:53 <hadrian> ... no new people today
14:04:08 <ryey> ryey has joined #lws
14:04:09 <hadrian> ... no announcements form my side
14:04:11 <Beau> Beau has joined #lws
14:04:16 <RazaN> RazaN has joined #lws
14:04:17 <acoburn> zakim, open agendum 1
14:04:17 <Zakim> agendum 1 -- Introductions and announcements -- taken up [from agendabot]
14:04:32 <Beau> present+
14:04:34 <ryey> present+
14:04:49 <RazaN> Presnet +
14:04:53 <jeswr> jeswr has joined #lws
14:05:00 <jeswr> present+
14:05:08 <hadrian> jeswr: SolidWorld next week
14:05:26 <jeswr> Solid World link https://theodi.org/news-and-events/events/solid-world-june-2025/
14:05:38 <kaefer3000> kaefer3000 has joined #lws
14:05:48 <acoburn> scribe+
14:05:50 <hadrian> * [#13](https://github.com/w3c/lws-ucs/issues/13) - done
14:05:50 <hadrian> * [#15](https://github.com/w3c/lws-ucs/issues/15) - done
14:05:50 <hadrian> * [#52](https://github.com/w3c/lws-ucs/issues/52) - done
14:05:50 <hadrian> * [#89](https://github.com/w3c/lws-ucs/issues/89) - done
14:05:51 <hadrian> * [#96](https://github.com/w3c/lws-ucs/issues/96) - done
14:05:51 <hadrian> * [#107](https://github.com/w3c/lws-ucs/issues/107) - done
14:05:51 <hadrian> * [#131](https://github.com/w3c/lws-ucs/issues/131) - done
14:05:51 <gb> Issue 52 not found
14:05:51 <gb> https://github.com/w3c/lws-protocol/issues/13 -> CLOSED Action 13 define a requirements template for the lws-ucs repository (on hzbarcea) due 2025-02-03
14:05:51 <gb> https://github.com/w3c/lws-ucs/issues/13 -> CLOSED Issue 13 [UC] bring-your-own-data native apps (by michielbdejong) [usecase]
14:05:52 <gb> https://github.com/w3c/lws-ucs/issues/52 -> CLOSED Issue 52 [UC] Home monitoring for elderly  (by fongenae) [usecase]
14:05:52 <hadrian> * [#132](https://github.com/w3c/lws-ucs/issues/132) - done
14:05:52 <hadrian> * [#135](https://github.com/w3c/lws-ucs/issues/135) - done
14:05:52 <hadrian> * [#141](https://github.com/w3c/lws-ucs/issues/141) - done
14:05:53 <gb> https://github.com/w3c/lws-protocol/issues/15 -> CLOSED Action 15 introduce both the term owner and controller in the glossary, and clarify their meaning. (on hzbarcea) due 2025-02-24
14:05:53 <hadrian> * [#142](https://github.com/w3c/lws-ucs/issues/142) - done
14:05:54 <kaefer3000> present+
14:05:57 <gb> https://github.com/w3c/lws-ucs/issues/15 -> CLOSED Issue 15 [UC] Community-based sharing app <DRAFT> (by mrkvon) [triage] [usecase]
14:06:00 <gb> https://github.com/w3c/lws-ucs/issues/89 -> CLOSED Issue 89 [UC] Share data with a (potentially large) community/group of people (by mrkvon) [triage] [usecase]
14:06:00 <acoburn> zakim, open agendum 2
14:06:00 <Zakim> agendum 2 -- Action Items -- taken up [from agendabot]
14:06:04 <gb> Issue 96 not found
14:06:06 <gb> https://github.com/w3c/lws-ucs/issues/96 -> CLOSED Issue 96 [UC] Offline Support / Local-First (by Laurin-W) [usecase] [review]
14:06:09 <gb> Issue 131 not found
14:06:11 <gb> Issue 107 not found
14:06:14 <gb> Issue 89 not found
14:06:16 <gb> https://github.com/w3c/lws-ucs/issues/107 -> CLOSED Issue 107 [UC] General purpose data storage (by hzbarcea) [usecase] [review]
14:06:19 <gb> https://github.com/w3c/lws-ucs/issues/131 -> CLOSED Issue 131 [REQ-F] Storages should be transferable (by hzbarcea) [review]
14:06:22 <gb> Issue 132 not found
14:06:25 <gb> Issue 135 not found
14:06:27 <gb> https://github.com/w3c/lws-ucs/issues/132 -> CLOSED Issue 132 [REQ-F] Delegation of control (by hzbarcea) [needs-discussion]
14:06:28 <acoburn> hadrian: many issues closed (see list above), several PRs are ready
14:06:30 <gb> https://github.com/w3c/lws-ucs/issues/135 -> CLOSED Issue 135 [REQ-F] Guaranteed globally unique identifiers for Resources (by hzbarcea) [review]
14:06:33 <gb> Issue 141 not found
14:06:36 <gb> https://github.com/w3c/lws-ucs/issues/141 -> CLOSED Issue 141 [REQ-F] Consent based sharing (by hzbarcea) [needs-discussion]
14:06:39 <gb> https://github.com/w3c/lws-ucs/issues/142 -> CLOSED Issue 142 [REQ-F] Auditable trail (by hzbarcea) [needs-discussion]
14:06:42 <gb> Issue 142 not found
14:06:46 <acoburn> ... many covering authN, authZ and algorithms
14:07:19 <acoburn> ... algorithms running close to the data are not exactly part of the protocol
14:07:19 <cpn> cpn has joined #lws
14:07:28 <cpn> present+
14:07:32 <acoburn> ... or could be plugins
14:07:44 <gibsonf1> q+ to propose third option - capability of server for "algorithm"
14:07:48 <acoburn> ... for example, format conversion, which must run inside the server
14:08:21 <laurens> q+
14:08:24 <acoburn> ... as discussed, these are out of scope for the protocol, however, we will likely need to say something about this class of use cases
14:08:38 <acoburn> ... otherwise will be confusing for implementers
14:08:52 <acoburn> ... would like to hear from the group
14:08:53 <laurens> ack gibsonf
14:08:53 <Zakim> gibsonf, you wanted to propose third option - capability of server for "algorithm"
14:10:02 <acoburn> we will continue the conversation in the use cases update
14:10:05 <acoburn> scribe-
14:10:21 <acoburn> zakim, open agendum 3
14:10:21 <Zakim> agendum 3 -- LWS Protocol Editors -- taken up [from agendabot]
14:10:52 <hadrian> laurens: meaningful progress in ucs, it's time to start working on the protocol, we decided on editors
14:11:14 <hadrian> ... jeswr and eBremer are the editors. It doesn't mean they
14:11:27 <hadrian> ... will be editors throughout the full lifecycle
14:12:02 <hadrian> acoburn: great intro, thanks laurens. Ideally the editors are people who can drive us to consensus
14:12:26 <hadrian> ... that is to emphasize that we hope that everyone here will be actively contributing to the document
14:12:57 <hadrian> laurens: thanks jeswr and eBremer for taking on this task
14:13:14 <hadrian> ... any questions or remarks?
14:13:17 <uvdsl> q+
14:13:33 <laurens> ack uvdsl
14:13:40 <laurens> ack laurens
14:14:11 <hadrian> uvsdl: could you give more background on eBremer and jeswr experience? I expect the discussions will get quite heated
14:14:53 <hadrian> laurens: chairs will be supporting editors as well.
14:15:00 <TallTed> q+
14:15:06 <hadrian> ... they will not be the only ones working on the deliverables
14:15:31 <hadrian> jeswr: in terms of editing experience I've been involved in w3c for 3-4 years now
14:15:56 <laurens> ack TallTed
14:16:01 <hadrian> ... reaching consensus will be a challenge in this group, because of the complexity of the topic
14:16:04 <uvdsl> thanks, jeswr! :)
14:16:17 <ericP> ericP has joined #lws
14:16:25 <ericP> present+
14:16:36 <hadrian> TallTed: the editors' job is not to drive consensus, but to implement the group's consensus in the document
14:17:11 <hadrian> ... the content is based on the input of the group, it's not just polishing. The consensus is driven by the chairs
14:17:13 <cpn> q+
14:18:01 <hadrian> jeswr: about self nomination, I did send a email to the chairs, volunteering, but willing to step back if there are enough volunteers
14:18:10 <hadrian> ... self-nomination was not on the public list
14:18:14 <kaefer3000> thanks jeswr
14:18:29 <ericP> q+ to say that imo, the principle editor job is to know the doc through and through and be able to, in real time, manage intra-document dependencies when generating text and reviewing PRs
14:18:42 <kaefer3000> q+
14:18:43 <hadrian> laurens: chairs decided to start with jeswr and eBremer
14:18:47 <laurens> ack cpn
14:19:35 <hadrian> cpn: the roles of the chairs are different. Chairs drive consensus and editors make sure it's reflected in the document
14:19:56 <laurens> ack ericP
14:19:56 <Zakim> ericP, you wanted to say that imo, the principle editor job is to know the doc through and through and be able to, in real time, manage intra-document dependencies when generating
14:19:59 <Zakim> ... text and reviewing PRs
14:20:00 <hadrian> ... we need to capture that csarven self-nominated on the public list and this should be captured in the minutes
14:20:16 <acoburn> q+ to respond to cpn's comment
14:21:33 <hadrian> ericP: editors need to do responsible babysitting
14:21:43 <laurens> ack kaefer
14:21:56 <uvdsl> s/uvsdl: /uvdsl: /
14:22:39 <hadrian> tobias: we have very experienced people in the group, self-nominated. How can we put these people in a good role
14:23:00 <hadrian> ... we need a clear guiding light in terms of process and consensus finding
14:23:11 <ericP> q+ to talk about conflict resoultion
14:23:19 <hadrian> ... I don't know if we need somebody experienced in that role
14:23:20 <laurens> q+
14:23:23 <laurens> ack acoburn
14:23:23 <Zakim> acoburn, you wanted to respond to cpn's comment
14:24:02 <TallTed> q+
14:24:06 <hadrian> acoburn: one thing, briefly, in terms of people with explicit experience with the process, pierre antoine is the w3c rep and he's very experienced, and that's his role
14:24:19 <hadrian> ... there are other people on the call with experience who will help out
14:24:55 <hadrian> ... the main concerns that we had is that we wanted to make sure that editors are a group of people who can work together and listen
14:25:16 <hadrian> ... there is plenty of experience in the group. we have to make sure the group produces something in the end.
14:25:45 <hadrian> laurens: we are all members of this group, it's a shared responsibility to work towards deliverables
14:26:10 <hadrian> ... the thing that we're proposing now is a way to steer towards that end
14:26:13 <laurens> ack ericP
14:26:13 <Zakim> ericP, you wanted to talk about conflict resoultion
14:26:47 <hadrian> ericP: the process does not help you get to consensus
14:27:11 <hadrian> ... typically we want people who have a good understanding of the situation, counts on integrity and good communication skills
14:27:31 <hadrian> ... the group delegate trust to these people. sometimes we use tools like wikis
14:27:54 <kaefer3000> by saying "process" I did not just mean W3C processes but also getting to consensus
14:27:56 <hadrian> ... sometimes there are disputes between the members of the group and we have to use integrity and compromise
14:28:08 <laurens> ack laurens
14:28:09 <hadrian> ... don't look at the process as the magic solution
14:28:11 <laurens> ack TallTed
14:28:32 <hadrian> TallTed: I am more than a little concerned about this conversation
14:28:59 <hadrian> ... we have 2 people who self-nominated in private and are busy
14:29:29 <hadrian> ... the person who self-nominated is not on the call and he's very frustrated
14:29:47 <laurens> q+
14:30:05 <hadrian> ... I don't feel good about my participation right now
14:30:31 <hadrian> ... I contribute to every group I'm in, mostly about language. right now I am not comfortable
14:30:34 <uvdsl> hadrian, why was the part about the self-nominee not being heard in the minutes?
14:30:45 <kaefer3000> thanks for your open words TallTed
14:31:22 <uvdsl> s/not being heard/not being heard not/
14:32:20 <hadrian> TallTed: ... not comfortable that my contributions will be used in the spirit they were offered
14:32:48 <laurens> ack laurens
14:32:50 <hadrian> laurens: choosing people is not a popularity contest, it would be wrong to feel about it that way
14:32:52 <laurens> q?
14:34:26 <RRSAgent> I have made the request to generate https://www.w3.org/2025/06/02-lws-minutes.html TallTed
14:34:33 <hadrian> laurens: this are not final decisions or decisions that happen behind closed doors. This conversation gives us reasons for reflection and we'll come back to it
14:34:33 <acoburn> zakim, open agendum 4
14:34:33 <Zakim> agendum 4 -- Use Cases & Requirements Updates -- taken up [from agendabot]
14:34:44 <acoburn> scribe+
14:34:46 <gibsonf1> q+ to talk about algorithms
14:34:56 <laurens> ack gibsonf1
14:35:24 <acoburn> gibsonf: related to algorithms, the question is how you define an algorithm. Would that also include authN and authZ?
14:36:02 <acoburn> ... mandatory algorithms, such as authN/authZ. what about other algorithms that are not MUSTs in the spec
14:36:13 <acoburn> ... could re refer to these as capabilities?
14:36:22 <hadrian> q+
14:36:27 <acoburn> ... e.g. discoverability of capability
14:36:46 <laurens> ack gibsonf
14:36:46 <Zakim> gibsonf, you wanted to talk about algorithms
14:36:49 <laurens> ack hadrian
14:37:16 <acoburn> hadrian: this is very much related to what I was referring to. AuthN/AuthZ are core capabilities
14:37:43 <acoburn> ... beside the core ones, we had conversations about what is in scope is the protocol, not necessarily how the technology is built
14:37:46 <laurens> q+
14:38:07 <acoburn> ... we cannot say (e.g.) that a storage server must be a modular one
14:38:18 <acoburn> ... but you are right in terms of interop and portability
14:38:27 <gibsonf1> q+ to clarify on capabilities - no intentions to dictate implementation details - but protocol interop
14:38:46 <acoburn> ... for portability, what claims can be made about the capabilities of different servers?
14:39:30 <TallTed> I would expect that an LWS server SHOULD optimally be an RP of an Authn IdP, where it might also serve as that IdP; Authz requires Authn, because authenticated entities must be granted permissions on resources stored in LWS....
14:39:43 <laurens> ack laurens
14:39:51 <TallTed> (Authn does not require Authz)
14:39:53 <acoburn> ... we will still need to find consensus on how we describe capabilities
14:40:18 <acoburn> laurens: there are a number of use cases that go beyond the basic functioning of an LWS server
14:40:34 <acoburn> ... they could be use cases for a v2 of the LWS protocol
14:40:51 <acoburn> ... that's not to say that they should not be included, but they could be labelled as out of scope
14:41:04 <laurens> akc gibsonf
14:41:05 <acoburn> ... as much as we can, I believe we should capture these use cases
14:41:14 <uvdsl> +1 to what TallTed says...
14:41:26 <hadrian> q+ to clarify that the proposal is to call them capabilities and include them as use cases, potentially out of scope
14:41:33 <acoburn> gibsonf: to clarify, I'm not referring to implementation details, rather strict protocol operation
14:42:07 <acoburn> ... this would have major impact on interop. Search or query could have major role in interop
14:42:12 <laurens> ack gibsonf
14:42:12 <Zakim> gibsonf, you wanted to clarify on capabilities - no intentions to dictate implementation details - but protocol interop
14:42:47 <acoburn> ... in our use cases, the key feature for us is the ability to have our data interoperate
14:43:13 <acoburn> ... if there are well-defined capabilities (e.g. optional capabilities), this would help
14:43:17 <laurens> ack hadrian
14:43:17 <Zakim> hadrian, you wanted to clarify that the proposal is to call them capabilities and include them as use cases, potentially out of scope
14:44:08 <acoburn> hadrian: I agree that query/search is important capabilitye. It may not be core
14:44:24 <uvdsl> q+
14:44:25 <acoburn> ... at some point we will need to deal with capabilities that we don't think of today
14:44:39 <acoburn> ... we will need a way to describe the capabilities of the storage server
14:45:04 <acoburn> ... discovery could be within the scope of the protocol
14:45:04 <laurens> q?
14:45:08 <laurens> ack uvdsl
14:45:39 <laurens> q?
14:45:42 <acoburn> uvdsl: we should be cautious of our terminology, such as non-repudiation
14:45:55 <acoburn> hadrian: there exists a use case for non-repudiation
14:46:16 <gibsonf1> +1
14:46:21 <acoburn> ... there are use cases for many of these items
14:46:34 <TallTed> q+
14:46:39 <acoburn> ... seems that the best approach is to capture the use cases and then let the group decide what is in scope
14:46:43 <jeswr> q+
14:46:48 <ryey> q+
14:46:51 <acoburn> laurens: yes, there are use cases that we haven't yet considered
14:47:03 <acoburn> ... or we may want to down-scope certain capabilities
14:47:04 <laurens> q?
14:47:08 <laurens> ack TallTed
14:47:43 <acoburn> TallTed: the general idea is to go from a use case/user story to a list of requirements in order for those use cases to succeed
14:47:55 <acoburn> ... there will be some number of requirements for each use case
14:48:06 <acoburn> ... some use cases can be combined
14:48:19 <acoburn> ... across the board, we have a requirement for stable identifiers
14:48:44 <acoburn> ... e.g. if I port data across providers and the identifiers change, everything breaks
14:49:18 <acoburn> ... we have spoken about a photo album use case, where the photos come from, say five different storages
14:49:42 <acoburn> ... need an identifier for the owner, delegation permission to other users, both read and write
14:49:53 <acoburn> ... also editing metadata about the resources
14:50:03 <acoburn> ... elucidating those requirements is key to this document
14:50:27 <acoburn> ... historically, I have found it useful to have the requirements be listed with each use case and then tabulated elsewhere
14:50:52 <acoburn> ... an implementation must be able to satisfy the requirements of a use case in order to move one
14:51:23 <acoburn> ... some will be simple and some might be advanced; search may be an advanced use case
14:51:41 <acoburn> ... for example search by date range
14:52:04 <hadrian> q+
14:52:06 <acoburn> laurens: I believe this is largely the approach taken in the use cases document
14:52:10 <laurens> ack jeswr
14:52:16 <acoburn> ... and how I would hope this deliverable takes shape
14:52:49 <acoburn> jeswr: re scoping of capabilities, I think we need to consider what is in scope and out of scope
14:53:01 <acoburn> ... for example, is there a SPARQL endpoint?
14:53:25 <acoburn> ... we may provide a way to discover those services without specifying those services themselves
14:53:37 <acoburn> ... for hadrian: do we do this now in our UCR doc?
14:53:45 <acoburn> ... for ted: how do other groups handle this?
14:53:51 <laurens> ack hadrian
14:54:18 <acoburn> hadrian: Ted made a good point that after each use case, there will be a section with a list of requirements
14:54:24 <acoburn> ... I will get that done
14:54:53 <acoburn> ... to Jesse, in terms of capabilities, I want to be able define capabilities of the protocol, rather than capabilities of the server
14:55:32 <gibsonf1> q+ to say on Ted's point about UCs vs Reqs, that in that context, search would potentially be a requirement of UCs rather than a UC itself.
14:55:35 <acoburn> ... in looking at the list of other UCR documents, these are less detailed that what we have (one is more). It is hard to get the right level of detail
14:56:05 <acoburn> TallTed: I haven't looked at many other groups, but the most common protocol that we're dealing with is HTTP
14:56:20 <acoburn> ... there, servers don't broadcast their features, but one can query them
14:56:32 <ryey> q-
14:56:32 <acoburn> ... one can dereference a URI to find out what is available
14:56:46 <pchampin> https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/OPTIONS
14:56:48 <acoburn> ... for example these are the verbs that can be used at a given URI
14:57:06 <acoburn> ... this is a very functional and scalable way to do this
14:57:28 <acoburn> ... narrowing down on the keywords that are relevant for LWS will be important
14:57:53 <acoburn> ... for example, the server might say you can only store documents of a certain size or quantity in a given location
14:58:14 <acoburn> ... we will need to be somewhat cautious in what we design
14:58:17 <jeswr> s/I think we need to consider what is in scope and out of scope/I think we need to identify what requirements are in scope to define within the specification (e.g. specific authz mechanisms), what requirements we afford for in the specification, and and what is out of scope to afford for/
14:58:20 <laurens> ack gibsonf
14:58:20 <Zakim> gibsonf, you wanted to say on Ted's point about UCs vs Reqs, that in that context, search would potentially be a requirement of UCs rather than a UC itself.
14:58:54 <acoburn> gibsonf: in the use case for pictures, search could be a requirement to achieve that use case
14:59:08 <TallTed> required / optional / not-applicable
14:59:43 <acoburn> RRSAgent, make minutes
14:59:44 <RRSAgent> I have made the request to generate https://www.w3.org/2025/06/02-lws-minutes.html acoburn
14:59:56 <RazaN> RazaN has left #lws
17:52:08 <acoburn> acoburn has left #lws