Meeting minutes
laurens: agenda: intros, announcements / action items / glossary PR / terminology relevant to identity eg with respect to data portability (localstorage vs offline store, scoping)
… : first agenda item: announcement
Introductions and Announcements
laurens: there is a breakout scheduled for 26/3
… : there is time till 12/3 to propose a breakout session
… : there are only 7 proposals until now, nothing LWS related
… : do we want to propose a breakout session about LWS?
<laurens> https://
laurens: https://
<csarven> See https://
csarven: Specs have the Considerations sections including Security and Privacy, Accessibility, Internationalization, and so on, and TAG looks at them as part of Explainers, and is considering societal impact questionnaire
… : this questionnaire is supposed to be a more practical way of looking at the consequences of our designed standards
… : this questionnaire is a draft, we anticipate that this will be incorporated in the explainer, as part of the design of the technical report
… : I also shared the minutes of last week's TAG meeting
… : even at the use case level, it matters, so we might want to revisit these questionnaires later on
… : we already need to look at the implications of these designs
… : please have a look, in the solid protocol there is an empty section for it, still to be done
… : TAG will ask later if the group has looked at it
… : it's still fuzzy at the moment, but it's important
laurens: coming back to the breakout sessions: I was wondering whether we could propose something
pchampin: breakout sessions are not specific to WG, more to bring topics to the broader community
… : there's no expectation that this group submits something, but if someone here has something they want to discuss with the community, this is an opportunity
Actions Items
<csarven> s$solid protocol had a section for it: https://
laurens: open action items: adding owner and controller to glossary, has that happened?
hadrian: that has happened, I do most visible work in the weekend
<laurens> w3c/
<gb> Action 15 introduce both the term owner and controller in the glossary, and clarify their meaning. (on hzbarcea) due 2025-02-24
hadrian: : there is an issue 122 I wanted to talk about
… : since the PR is closed, I wonder what the process is to close issues
… : I think 122 can be closed
<laurens> w3c/
<gb> Issue 122 Glossary draft (by hzbarcea) [needs-discussion]
laurens: I think your PR mostly addressed the scope of 122
… : does the group agree?
csarven: what remains is the part about having a trace from the requirements/terms came from use cases A, B, C
… : I haven't seen these back-references
hadrian: I wanted to talk about that
… : there is the DID use cases document, that is very well organized (issue 119)
<laurens> w3c/
<gb> MERGED Pull Request 119 Template for requirements (by hzbarcea)
hadrian: : it references three other documents, that has a matrix that connects requirements with use cases
… : I'm working on that matrix now
… : the only way to close them is to provide the traceability matrix
<acoburn> DID requirements matrix
csarven: I agree, as long we know why certain terms or requirements were not taken up
hadrian: indeed, once you do the traceability matrix, the use case proposer can see whether their use case is fully covered
… : that's why I don't want to close issues as long as the proposer hasn't agreed that its use case was fully covered
hadrian: I still have the question about the process for closing the issue
… : OK if the editor just closes?
… : you can always reopen issues
… : eg to correct mistakes
laurens: it would be good to have some agency on closing the issue
hadrian: we made the comment that issues can be closed once they are handled and no one complains
… : would be good if the closed issues can be added to the minutes
laurens: yes, would be good if you can create such an overview, i'll make an action item
ACTION: hadrian to present a weekly overview of closed issues in the https://
<gb> Created action #16
laurens: so yes, at editor's discretion, agreement
Glossary
hadrian: the glossary is pretty much done, most discussion needed related to identity and visible structure of a storage
… : ie taking up the discussion from last week
Terminology, use cases and requirements relevant to identity
laurens: there are identity-related issues in our ucs repo
… : also the interrelation between identity provider, identity documents, authentication, etc
… : I wanted to focus on the requirements concerning identity for agents in LWS
… : requirements for identifiers, identity documents, agents, and services, in the LWS ecosystem
… : it's not about WebID vs DID, it's about having objective criteria for when we need an identifier
hadrian: I think my opinion on identity is stable for the last 18 months, but a bit different from Solid's idea
… : the terminology is general enough, but we need to be more specific to get to consensus
… : eg 126 and 125
<laurens> w3c/
<gb> Issue 126 [REQ-F] Guaranteed globally unique Identifier Storage(s) (by hzbarcea) [triage]
<laurens> w3c/
<gb> Issue 125 [REQ-F] Guaranteed globally unique Identifier for Entities (by hzbarcea) [triage]
hadrian: : eg 'an identifier' is just a string, I don't think anyone can object to that
<laurens> w3c/
<gb> Issue 136 [REQ-F] Resources shall have one ore more addresses tied to Identities (by hzbarcea) [triage]
hadrian: 136
… : when you talk about 'Hadrian', you talk about an identifier
… : but that doesn't help you communicate with me
… : my identifier doesn't change often, but my addresses can change a lot
… : using identifiers for the purpose of authentication: it should use identifiers, not necessarily the address
… : LDP didn't make the difference on purpose
… : then you don't need additional infrastructure, but it's a bit of a bastardization
laurens: to clarify: you talk about locators such are URL/URI, when you talk about address?
hadrian: yes, my point is that it's not necessarily the identifier of yourself
… : there is a strong correlation between you and your phone number, but it's not the same, and at scale you see problems
csarven: How much will we get out of a requirement that we should use globally unique identifiers?
… : isn't that a given?
<csarven> >Any resource of significance should be given a URI.
csarven: : so anything that should be referenceable/dereferenceably should get an identifier
… : I'm not sure we should spend too much time, won't that be a given from the spec?
… : eg 'i want to look into my address book': your application needs to know who you are, so you will have a globally unique identifier
hadrian: I agree, not all these requirements will be put in the document, but they can ignite conversations
csarven: then I propose a single requirement as with the design issues Axiom "Any resource of significance should be given a URI"
<Zakim> ericP, you wanted to say that portability requirements lead us to identity requirements: no portability or DNS portability (10Bs of DNS entries) -> DNS-backed identity reqs; user portability -> late-binding (DNS|)ledger-based user ids, no resource reqs; doc portability () -> late-binding (DNS|)ledger-based document (and ACL) ids
ericP: portability requirements lead us to identity requirements
<csarven> We should use IPV6 only
ericP: : eg the DNS route: no portability or DNS portability (10Bs of DNS entries) : we don't add additional requirements
… : user portability, we're stuck with ledger-based user ids, so that if they go from one provider to another, so all their context will go with them
… : if you want document portability, if you don't want to reset all your ACLs etc., then we need the option of ledger-based identity for documents
… : we need to check what we need from the portability requirements
<Zakim> pchampin, you wanted to ask about unique vs. unambiguous
pchampin: i'm not sure we want 'globally unique', rather 'globally unambiguous'
hadrian: ericP, do you mean blockchain such as Ethereum?
… : there is keri which would be a good option, used in legal context
… : concerning 'unambiguous': yes, there could be multiple identifiers for an identity
… : I agree on the meaning, we should agree on the phrasing
hadrian: concerning public ledger, are you meaning merkle trees?
ericP: i tried to avoid the work "blockchain" and use the more fundamental term "shared-ledger", i.e. something serving as a replacement for the IANA-distributed DNS roots
… : ie we have an out-of-band communication of identities, just like DNS gives out of band communication of domain names
csarven: I'm looking at issue 125
<hadrian> https://
csarven: : I'm not sure the description reflects the requirement
… : if the intention is that someone is in control of their identifier, that's orthogonal to the mechanism to prove that, i.e. identifying something
… : why is cryptographic method in particular important to prove the identity? why is that rolled into this description? Can't there be different ways?
… : I think the intention is 'significant things have an identity'
… : we need to do identity that are compatibel with the Web
… : I think we should stay within that scope
<Zakim> ericP, you wanted to add (for posterity) the other parameter i had forgotten was the distinction between well-behaved data providers vs. those that disappear suddenly (à la purl.org)
ericP: final portability issue: the distinction between well-behaved data providers vs. those that disappear suddenly (à la purl.org)
<csarven> s/that "Any resource of significance should be given a globally unique identifier/as with the Design Issues Axiom, "Any resource of significance should be given a URI
ericP: : so if that is in scope, we need more late-binding methods
laurens: I think the identity issues closely relates to a (pod/webid) provider that goes bust: how do we combat that?
… : most methods rely on a resolver infrastructure
dmitriz: i think the resolver part is irrelevant to us, just as the underlying dns resolvers are
… : we can just say 'stable' or 'resolvable' identifiers
… : and that's enough
hadrian: I agree with Dmitri in spirit
… : but there will be an issue in portability
… : we have to somehow address: if you move between providers with different identity systems, you need to handle that
<Zakim> bendm, you wanted to ask whether that's important to nail down, e.g. can't we just have multiple identifier options that have different trade-offs?
<laurens> bendm: I wanted to say the same thing as Dmitri, a stable or resolvable identifier might be sufficient for our scope
hadrian: for next week, expect more on the matrix
… : expect more requirements, and I will start closing more issues
laurens: all right, we can close the session for today