Meeting minutes
<KevinDean> https://
otto: agenda recap
otto: (agenda recap)
Agenda Review, Introductions (5 min)
<ottomorac> w3c/
otto: PR twists and turns - joe, explain your recent turn to dissatisfaction
joe: i previously questioned the backwards-compatibility with the older URL implementation, e.g. did:cheqd DID-linked resources and did:cosmos
… i don't want to merge this until we have more hardened backwards compat, and i worry we are privileging one approach over others
… as opposed to leaving this in the realm of opt-in extensions
… good convo yesterday with will: we talked through a corner case where an existing DID with one kind of path/endpoint "adds" a new one in the new model and it breaks that DID or older ways it could be consumed
swcurran: i take issue with the idea of this prejudicing or favoring one way over others
… : on the contrary, the whole point is to regularize this and make interop possible rather than just extensions that can't have cross-method meaning or usage
… : i am still catching up on more recent comments, but i definitely want to satisfy the goal of backwards compatibility and minimal breakage of existing deployments and extensions
manu: i see both sides here. the wg consensus was not to favor specific approaches and to maximize back-compat. i can't follow the disagreements over the specifics of the algorithm, but i do remember the wg saying people would object until they felt backwards compat was complete enough
… breaking cheqd would be a failure mode and i would expect objections if there is clear breakage
… i think some form of path service in this general shape we could invite people to align around, and market-based alignment would happen naturally over time
… and extensions or other approaches will still be supported on a more method-by-method basis in any future we can avoid breaking them
… i thought the consensus was to move this into did-wide mechanism, NOT leave it in extension-land
swcurran: action item for me, i'll take a closer look at cheqd did-linked resources to understand better what the concerns are there
… i assumed peacekeeper was being thorough when he said he thought backwards compat was fine here, i guess i will dig deeper to figure out what we're still disagreeing over
<ottomorac> Alex Tweeddale:
<ottomorac> I do think it breaks DID-Linked Resources, but a simple update will align DLRs with this new spec.
<ottomorac> My understanding is that if cheqd DIDs included a service of type = pathService and endpoint including: /resources/
<ottomorac> Then it should be compatible?
<Zakim> JoeAndrieu, you wanted to say it does conflict
joe: wow, +1 to alex, if cheqd sees the fix as manageable on their side, it's great news
… i'm worried about the case where legacy and new model are both present and they conflict, some kind of built-in conflict resolution or heirarchy makes it more programmatic to avoid breakage in the design of the new model #150
DID Path PR \[1\] (10 min)
<ottomorac> w3c/
joe: was trying to think through this
otto: manu have you checked this out yet? looks approved already
manu: i haven't run the linter/checker but if that passes looks right semantically
… yeah looks good
DID Core PR: Add DID Resolution error conditions to vocabulary \[2\] (5 min)
zaky boy, get it together
DID Resolution PR Processing \[3\] (7 min)
w3c/did-resolution#299
<ottomorac> Include extensions in the expand urls algorithm
otto: will, wanna introduce?
will: Addresses TAG review comments, but also mentioned in one of joe's issues; previously, known/core did properties were the only things checked, but this updates it to cover additional props and more reliably expand all URLs
manu: looks good
w3c/did-resolution#301
swcurran: relativeRef seemed dangerous to me
manu: at a high level, looks good, nit, lowercase shoulds and mays might bite us later
… as opposed to MAY or can
swcurran: whoops missed that
manu: TBH, i think this patch was very thorough and was just about as convincing as i can imagine
… a lot of the complexity is unavoidable and upstream because inherent to URL normalization and syntax
<Zakim> JoeAndrieu, you wanted to mention issue 925 at did-core w3c/
joe: ok but there's a real vacuum here, "query" isn't defined enough
… in did-core there is an admonition against duplicate query params, but that seems impossible here given this language, so that ambiguity might bite us later
swcurran: i was focusing on exactly that, but i'm not sure where to stick the fix
… i was being pretty careful to consistently stick to what is possible in a did, i would welcome a separate PR (or maybe a fix on did-core) to squash this ambiguity
… could this PR land and new issue and PR address it?
<Zakim> manu, you wanted to note relativeRef as SHOULD NOT use is something I could get behind
bumblefudge: +1 to swcurran requesting follow-on PR for issues created by this PR instead of holding up this PR
manu: if not for backcompat, i would have loved to just deprecate relRef for the same reasons, but pathService, if it is defined here in this spec, could include a non-normative hint to use this instead and explain why
<swcurran> Does anyone use relativeRef? It's so tricky.
pchampin: i wonder if advising against relRef is too harsh (or prejudiced against existing impls); couldn't a relRef include a hash or hashlink or SRI or?
<Zakim> JoeAndrieu, you wanted to clarify
manu: well, maybe but the semantics are slippery, what relationship is assumed or projected between the hash and the referent, what assumptions of the dereferencing or immutability
… i would love to hear from someone who uses it and loves it and feels safe using it
joe: pchampin, you might be referring to a different usage of the relRef in URLs, this is a DID-specific semantic, which might be another reason to deprecate or at least rename our overloading of the term
bumblefudge +1, hate overloading
DID Core PR: Add DID Resolution error conditions to vocabulary \[2\] (5 min)
DID Resolution Issue Processing \[4\] (15 min)
otto: i was wondering what this issue flag "simplify for interop and consistency" means?
… are you imagining one PR to address all four of these?
w3c/did-resolution#302
<ottomorac> Reconsider expandRelativeURLs as part of dereferencing instead of resolution #302
joe: to explain, all four of these came out from swcurran's pr, but were kind of offtopic so i wanted to address them later, mostly around deferencing/resolution mixups in various points of the spec and swcurran's new lang
joe: in summary, i think there is a slippage here whereby the resolver is changing the did doc
… the actual did doc is what gets dereferenced, if the resolver wants to change anything it should change what gets resolved
will: also there is a separate issue tied up in this to detangle how extensions work across resolution and dereferencing
… worried about parallelizing these, might this get squashed or conflictive if you're doing PRs on same sections?
joe: i am not to worried
… about parallelizing
manu: sorry this is a lot to read and assess, as well as judge if parallelizable
… i could have sworn this came up before and we said we would add a section or algorithms but never got around to it
… not clear to me what next steps are
joe: actually we already have sections for the resol/deref, i just want further clarity of the separation of concerns and the implicit contract between method implementation/VDR and resolver
manu: +1, that clarification would be good somewhere
w3c/did-resolution#303
<ottomorac> Reconsider accept as parameter for dereferencing rather than resolution #303
joe: similar dynamic here
… i think parameter got put in the wrong place, accept header gives the resolver wider birth to reformulate and return a translation
will: i think this is from the two mediatype days
… and when resolvers were expected to do content-negotiation
… but more generally, +1, i agree to move this, it's cleaner the proposed way
otto: i am not sure it's productive to go through these 1 by 1 now, these issues are new and need time to percolate
… and get reviewed async
w3c/did-resolution#304
<ottomorac> Be clearer about the service array as part of dereferencing instead of resolution #304
otto: seeing some reactions from peacekeeper, but markus' question is good
joe: can address: i think threat modeling exposed a corner case with dereferencing a DID URL historically
… namely, you need to dereference a DID URL, but if there are query params, you also need to resolve the DID URL (i.e. apply params to the dereferenced DID URL)
… as that applies to services array, i think we can also just move this over
otto: yeah swcurran's PR really made all this salient for me
swcurran: i think you have general agreement so proceed to PR and it would be faster to just discuss draft PRs rather than abstractions
joe: will do action item for me
… although i wanted confirmation that the mental model worked for me
bumblefudge: Does this overlad de-referencing and resolving?
bumblefudge: sorry nothing productive to ask, just worried other terms might overload general URL deref/resol
otto: last call for minor issues and checkins?
will: basically, if anyone sees a complication or counterargument before joe writes PRs, drop them in the issue
swcurran: if floor is open, can i close the pathUrl PR and start a new PR?
manu: yeah totally, just backlink as "superceding"
swcurran: minor issue, the CSS issue i got into last week with echidnea, numbered algorithms and bullets are getting garbled as deep deep numbers, i will try to open a separate PR for that
w3c/did-resolution#293
swcurran: but if anyone has helpful echidnea insights i would appreciate the pointers
Tracking of resolutions and dereferences by downstream entities from the resolver #293
will: 293: i promised a general privacy review issue across all the specs at once, please drop any inputs or ideas in there that might help me with that review
… i have also pinged the reviewer to propose a 3-feature PR
… point 2 points out that priv cons specs can refer to each other to avoid duplication and drift
… but it's a bit unwieldly to follow three links to know how to use one of the specs
… if reviewer is happy with wontfix on #2 i will just PR 1 and 3
otto: sounds a bit like a circular reference, tho...
manu: and on pt 3, there might be a quick fix just specifying a "trusted cache" rather than a "cache", or just dropping that section altogether if the reviewer still dissatisfied
joe: fundamentally, i think they are asking for something offbase
… obfuscating which callers are getting which dids seems to misunderstand the privacy goals imho
… we can obscure which DOCUMENTS they got back but callers and DIDs aren't worth obscuring
will: i think the reviewer was asking specifically about HTTP/IP obfuscation/tracking, which we can maybe explain better in PR or in spec text
… with trusted cache reference for ex