Meeting minutes
laurens: first agenda items and announcements
… no new people today
… no announcements form my side
Introductions and announcements
<RazaN> Presnet +
jeswr: SolidWorld next week
<jeswr> Solid World link https://
* #13 - done
* #15 - done
* #52 - done
* #89 - done
* #96 - done
* #107 - done
* #131 - done
<gb> Issue 52 not found
<gb> CLOSED Action 13 define a requirements template for the lws-ucs repository (on hzbarcea) due 2025-02-03
<gb> CLOSED Issue 13 [UC] bring-your-own-data native apps (by michielbdejong) [usecase]
<gb> CLOSED Issue 52 [UC] Home monitoring for elderly (by fongenae) [usecase]
* #132 - done
* #135 - done
* #141 - done
<gb> CLOSED Action 15 introduce both the term owner and controller in the glossary, and clarify their meaning. (on hzbarcea) due 2025-02-24
* #142 - done
<gb> CLOSED Issue 15 [UC] Community-based sharing app <DRAFT> (by mrkvon) [triage] [usecase]
<gb> CLOSED Issue 89 [UC] Share data with a (potentially large) community/group of people (by mrkvon) [triage] [usecase]
Action Items
<gb> Issue 96 not found
<gb> CLOSED Issue 96 [UC] Offline Support / Local-First (by Laurin-W) [usecase] [review]
<gb> Issue 131 not found
<gb> Issue 107 not found
<gb> Issue 89 not found
<gb> CLOSED Issue 107 [UC] General purpose data storage (by hzbarcea) [usecase] [review]
<gb> CLOSED Issue 131 [REQ-F] Storages should be transferable (by hzbarcea) [review]
<gb> Issue 132 not found
<gb> Issue 135 not found
<gb> CLOSED Issue 132 [REQ-F] Delegation of control (by hzbarcea) [needs-discussion]
hadrian: many issues closed (see list above), several PRs are ready
<gb> CLOSED Issue 135 [REQ-F] Guaranteed globally unique identifiers for Resources (by hzbarcea) [review]
<gb> Issue 141 not found
<gb> CLOSED Issue 141 [REQ-F] Consent based sharing (by hzbarcea) [needs-discussion]
<gb> CLOSED Issue 142 [REQ-F] Auditable trail (by hzbarcea) [needs-discussion]
<gb> Issue 142 not found
hadrian: many covering authN, authZ and algorithms
… algorithms running close to the data are not exactly part of the protocol
… or could be plugins
… for example, format conversion, which must run inside the server
… as discussed, these are out of scope for the protocol, however, we will likely need to say something about this class of use cases
… otherwise will be confusing for implementers
… would like to hear from the group
<Zakim> gibsonf, you wanted to propose third option - capability of server for "algorithm"
we will continue the conversation in the use cases update
LWS Protocol Editors
laurens: meaningful progress in ucs, it's time to start working on the protocol, we decided on editors
… jeswr and eBremer are the editors. It doesn't mean they
… will be editors throughout the full lifecycle
acoburn: great intro, thanks laurens. Ideally the editors are people who can drive us to consensus
… that is to emphasize that we hope that everyone here will be actively contributing to the document
laurens: thanks jeswr and eBremer for taking on this task
… any questions or remarks?
uvdsl: could you give more background on eBremer and jeswr experience? I expect the discussions will get quite heated
laurens: chairs will be supporting editors as well.
… they will not be the only ones working on the deliverables
jeswr: in terms of editing experience I've been involved in w3c for 3-4 years now
… reaching consensus will be a challenge in this group, because of the complexity of the topic
<uvdsl> thanks, jeswr! :)
TallTed: the editors' job is not to drive consensus, but to implement the group's consensus in the document
… the content is based on the input of the group, it's not just polishing. The consensus is driven by the chairs
jeswr: about self nomination, I did send a email to the chairs, volunteering, but willing to step back if there are enough volunteers
… self-nomination was not on the public list
<kaefer3000> thanks jeswr
laurens: chairs decided to start with jeswr and eBremer
cpn: the roles of the chairs are different. Chairs drive consensus and editors make sure it's reflected in the document
<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 text and reviewing PRs
cpn: we need to capture that csarven self-nominated on the public list and this should be captured in the minutes
ericP: editors need to do responsible babysitting
tobias: we have very experienced people in the group, self-nominated. How can we put these people in a good role
… we need a clear guiding light in terms of process and consensus finding
… I don't know if we need somebody experienced in that role
<Zakim> acoburn, you wanted to respond to cpn's comment
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
… there are other people on the call with experience who will help out
… 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
… there is plenty of experience in the group. we have to make sure the group produces something in the end.
laurens: we are all members of this group, it's a shared responsibility to work towards deliverables
… the thing that we're proposing now is a way to steer towards that end
<Zakim> ericP, you wanted to talk about conflict resoultion
ericP: the process does not help you get to consensus
… typically we want people who have a good understanding of the situation, counts on integrity and good communication skills
… the group delegate trust to these people. sometimes we use tools like wikis
<kaefer3000> by saying "process" I did not just mean W3C processes but also getting to consensus
ericP: sometimes there are disputes between the members of the group and we have to use integrity and compromise
… don't look at the process as the magic solution
TallTed: I am more than a little concerned about this conversation
… we have 2 people who self-nominated in private and are busy
… the person who self-nominated is not on the call and he's very frustrated
… I don't feel good about my participation right now
… I contribute to every group I'm in, mostly about language. right now I am not comfortable
<uvdsl> hadrian, why was the part about the self-nominee not being heard not in the minutes?
<kaefer3000> thanks for your open words TallTed
TallTed: ... not comfortable that my contributions will be used in the spirit they were offered
laurens: choosing people is not a popularity contest, it would be wrong to feel about it that way
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
Use Cases & Requirements Updates
gibsonf: related to algorithms, the question is how you define an algorithm. Would that also include authN and authZ?
… mandatory algorithms, such as authN/authZ. what about other algorithms that are not MUSTs in the spec
… could re refer to these as capabilities?
… e.g. discoverability of capability
<Zakim> gibsonf, you wanted to talk about algorithms
hadrian: this is very much related to what I was referring to. AuthN/AuthZ are core capabilities
… beside the core ones, we had conversations about what is in scope is the protocol, not necessarily how the technology is built
… we cannot say (e.g.) that a storage server must be a modular one
… but you are right in terms of interop and portability
… for portability, what claims can be made about the capabilities of different servers?
<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....
<TallTed> (Authn does not require Authz)
hadrian: we will still need to find consensus on how we describe capabilities
laurens: there are a number of use cases that go beyond the basic functioning of an LWS server
… they could be use cases for a v2 of the LWS protocol
… that's not to say that they should not be included, but they could be labelled as out of scope
<laurens> akc gibsonf
laurens: as much as we can, I believe we should capture these use cases
<uvdsl> +1 to what TallTed says...
gibsonf: to clarify, I'm not referring to implementation details, rather strict protocol operation
… this would have major impact on interop. Search or query could have major role in interop
<Zakim> gibsonf, you wanted to clarify on capabilities - no intentions to dictate implementation details - but protocol interop
gibsonf: in our use cases, the key feature for us is the ability to have our data interoperate
… if there are well-defined capabilities (e.g. optional capabilities), this would help
<Zakim> hadrian, you wanted to clarify that the proposal is to call them capabilities and include them as use cases, potentially out of scope
hadrian: I agree that query/search is important capabilitye. It may not be core
… at some point we will need to deal with capabilities that we don't think of today
… we will need a way to describe the capabilities of the storage server
… discovery could be within the scope of the protocol
uvdsl: we should be cautious of our terminology, such as non-repudiation
hadrian: there exists a use case for non-repudiation
<gibsonf1> +1
hadrian: there are use cases for many of these items
… seems that the best approach is to capture the use cases and then let the group decide what is in scope
laurens: yes, there are use cases that we haven't yet considered
… or we may want to down-scope certain capabilities
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
… there will be some number of requirements for each use case
… some use cases can be combined
… across the board, we have a requirement for stable identifiers
… e.g. if I port data across providers and the identifiers change, everything breaks
… we have spoken about a photo album use case, where the photos come from, say five different storages
… need an identifier for the owner, delegation permission to other users, both read and write
… also editing metadata about the resources
… elucidating those requirements is key to this document
… historically, I have found it useful to have the requirements be listed with each use case and then tabulated elsewhere
… an implementation must be able to satisfy the requirements of a use case in order to move one
… some will be simple and some might be advanced; search may be an advanced use case
… for example search by date range
laurens: I believe this is largely the approach taken in the use cases document
… and how I would hope this deliverable takes shape
jeswr: re scoping of capabilities, 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
… for example, is there a SPARQL endpoint?
… we may provide a way to discover those services without specifying those services themselves
… for hadrian: do we do this now in our UCR doc?
… for ted: how do other groups handle this?
hadrian: Ted made a good point that after each use case, there will be a section with a list of requirements
… I will get that done
… to Jesse, in terms of capabilities, I want to be able define capabilities of the protocol, rather than capabilities of the server
… 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
TallTed: I haven't looked at many other groups, but the most common protocol that we're dealing with is HTTP
… there, servers don't broadcast their features, but one can query them
… one can dereference a URI to find out what is available
<pchampin> https://
TallTed: for example these are the verbs that can be used at a given URI
… this is a very functional and scalable way to do this
… narrowing down on the keywords that are relevant for LWS will be important
… for example, the server might say you can only store documents of a certain size or quantity in a given location
… we will need to be somewhat cautious in what we design
<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.
gibsonf: in the use case for pictures, search could be a requirement to achieve that use case
<TallTed> required / optional / not-applicable