Meeting minutes
<ottomorac> ottomorac/
Agenda Review, Introductions (5 min)
ottomorac: reviews agenda for today
pchampin: Would like to talk about CR snapshot for DID 1.1
CR snapshot for DID 1.1
pchampin: plan was to publish today, but this is not going to happen. There is a small blocker
ottomorac: Okay lets start with that
pchampin: something is missing from the CR snapshot. We are expected to describe in the CR document what the exit criteria are
<pchampin> https://
pchampin: Here is an example, for how DID 1.0 did this
… We need something similar in the CR snapshot. In the State of the document
… We should be careful about how we define/measure interop here across implementations
… We may also refer to DID resolution here
manu: Sure, we can add the text
… I thought we didnt have to becasue the new charter specifies this
… The language around what interop is, is tricky
… It is legit to presume folks will be picky
… Not sre what language we can add to explain what we mean about interop
… In the formal objection round 1.0, was that what we meant by interop is that the feature expressed by a DID document is interperatable the same way no matter what DID method you use
… id always means id, verificationMethod always means verificationMethod
… To test this, feels difficult
… Happy to take a shot at what this text looks like, understanding that whatever we put in will be open for people to pick holes in
… Our test suite takes input documents for 1.0, updating them to 1.1 and demonstrating that nothing breaks
… Showing that we didnt make breaking changes
… Not sure if this will be okay for people who want to make FO
… Not saying the concerns raised are not legitimate. We can write some texts, it may take weeks which will push back CR
ottomorac: When you stay status of the document text, why would this take weeks?
manu: Challenge is defining what interop means
ivan: wondering if it is possible to build up specific scenarios that has to go through seveal methods with similar results as a proof of interoperability
… A way to check validity of DIDs across different methods
pchampin: I believe what has changed, is now we have something to show for the objections that were recieved
… DID Resolution is on standards track
… I would say refering to DID Resolution is a good approach here.
… Probably want to avoid precise definition of interop
… Explain more explicitl that this spec is not covering everything, so niether is the test suite
<Zakim> JoeAndrieu, you wanted to say the charter defines exit criteria. we should look at that.
<JoeAndrieu> from the charter: where interoperability can be verified by passing open test suites, and two or more implementations interoperating with each other. In order to advance to Proposed Recommendation, each normative specification must have an open test suite of every feature defined in the specification.
<JoeAndrieu> In order for DID Resolution to advance to Proposed Recommendation, it is expected that each of the independent implementations mentioned above support at least two DID methods which 1) have an open specifications (freely available specification, freely implementable), and 2) are implemented interoperably by more than one of the independent
<JoeAndrieu> implementations mentioned above. This means that there will exist at least two openly-specified DID methods that are each implemented by at least two independent implementations.
JoeAndrieu: The charter does define a form of interop
… This was crafted in response to addressing the FO from a different era
… We should not spend to much time speculating about who might object
… It is a distraction
… +1 to point to DID Resolution
manu: I can try to raise a PR that we can look at
… Will try to do that today
<pchampin> and I will be more reactive than last week, promise :)
Inconsistent use of resolution \[1\] (10 min)
manu: What is the new target publication date
… I need to redo the CR publication
pchampin: I can regenerate the snapshot. That is also possible
… Lets say two weeks
<ottomorac> w3c/
<ottomorac> Inconsistent use of resolution:
<ottomorac> This is one of the last couple of TAG issues that needs a PR raised against it, which is critical so that we can get to CR.Joe have you had a chance to review or is there any way we can help?
ottomorac: wondering what we can do to prioritize this issue prior to threat model
<Zakim> JoeAndrieu, you wanted to mention this will follow getting the narrative for the threat model
JoeAndrieu: Apologies that it is bottlenecked behind the threat model stuff
… I am learning based on the diagrams, we dont have a coherent way to talk about all the diagrams
… Creating diagrams for different architectures, e.g. did:key, did:btcr2
… Making sure we have consistent language across the different architectures
… This will teach me the right way to talk about it
… I dont need to get all the way to finished for the diagram, I just need a first draft
… Aiming for 2-4 weeks before we have spec text that we can share with TAG to see if it addresses their concerns
Should the spec address the non-handling of DID URL query parameters? \[2\] (10 min)
<ottomorac> w3c/
<ottomorac> Should the spec address the non-handling of DID URL query parameters?
<ottomorac> Issue raised by Stephen, related to the following: If during DID URL Dereferencing some parameters are not processed, should the caller be notified and if so, how?Markus had indicated that perhaps an error code could be returned, and then some additional discussion took place.
Wip: We are currently returning an error in the spec, based on my understanding we don't want to error if the DID resolver does not understand some parameters, but we might want to generate a warning
but warnings are not implemented
<manu> https://
manu: In VCALM spec, there is a verification errors and warnings section
… This allows it to return an object, and errors and warnings as two separate arrays
… I think we should follow the approach in the VCALM spec if we are wanting to add warnings
… Lets make a decision and move forwards. Can always address it in a future version
… We are in a time crunch here
… One option is not to mention it in this version
dmitriz: I do think a warning capability is very important
… The version parameter is a really good example
… I would advocate that reserved parameters, such as versionTime, we should specifically highlight when they should return an error
<Zakim> JoeAndrieu, you wanted to discuss warnings over errors
JoeAndrieu: I think versionId is different. E.g. if versionId is on a did:key URL, the client should still get a did document
… +1 for warnings
Wip: I think this reminds me that this may not be as relevant, because DID methods can be more strict, for example did:webvh has a strict mode....
Wip: This would restrict resolvers and could also use the versionID for that
Maybe a warning will solve this too
<Zakim> JoeAndrieu, you wanted to put the burden on the DID method explicitly
JoeAndrieu: I agree, lets put the burden on the DID methods. We should make it clear to people that DID methods may add additional constraints
Wip: What should we do then? Sounds like we do want warnings, but do we have time to get it in for this version of the spec?
<dmitriz> I think warnings for next version would be good.
Wip: at least this text from Joe that some did methods may be more restrictive makes sense
dmitriz: The key question is this version or next
manu: Lets say its next version. We do intend to add warnings, it may having in CR phase. We can add a feature warning to the spec
… If we dont make it we can leave a note that we intend to add warnings in the future
… We would have to state it before CR, that we intend to add a feature during CR
DID Resolution Ready for PR - Updates on assigned issues \[3\] (15 min)
w3c/did-resolution#275
ottomorac: A few issues I want to subtopic
275: - Per my note on Issue 275 w3c/
ottomorac: Stephen shared the above note with me
… He thinks we should close this issue as a wont do. Or if we do want to do it, he should be unassigned
… Thoughts?
<Zakim> JoeAndrieu, you wanted to mention VCDM synchrony
ottomorac: markus also raised a similar comment on the confusion with the WhatWG URL spec
JoeAndrieu: My biggest challenge is not 3986 vs WhatWG. Rather it is alignment with the Controlled IDentifier spec and the VCDM
… We have this alignment issue. Recognising the confusion of WhatWG
… It is hard to find the syntax
… Curious if people where on the call when the VCDM chose to use WHatWG
manu: I was involved in VCDM. This is not impossible. It just takes a lot of work
… 3986 is not how a vast portion of web servers resolve URLs. It is outdated
… WhatWG spec properly defines URL processing
… Would expect people in the TAG to raise objections
… People are going to use libraries to handle this. Libraries are going to implement WhatWG
… I would volunteer but dont have the cycles
pchampin: Just wanted to comment on JoeAndrieu. Not everyone is migrating. RDF and Sparkle group are sticking to 3986, but this group is less concerned with resolving and dereferencing
… To manu's point we are in the process of horizontal review for sparkle rdf work. The TAG did not comment on the use of 3986
ivan: Want to remphasise something manu said
… It is not only the browsers, but all off the shelf libraries to do URL and URL parsing are using WhatWG
… If we are very strict on implementers, they would have to reimplement a URL library to follow 3986. This is crazy. WhatWG is the reality
<Zakim> JoeAndrieu, you wanted to mention CID is WHATWG
JoeAndrieu: Pulled up the CID spec, which uses WHATWG definition
… DIDs depend on CIDs. CIDs use WhatWG. So we need to figure out nhow to be consistent
… We can state it as an issue and hope someone gets to it
… This is work we should do, we want to do it, just need to find someone to do it if we ca
ottomorac: I see 10 occurances of 3986 in the spec. We just need to find equivalent in WhatWG. Tempted to take this
… Doesn't seem horrible
JoeAndrieu: Challenge is mapping the language between the specs
ottomorac: Okay I will take it
JoeAndrieu: I think we should have a resolution for this switch
PROPOSAL: Update to the WHATWG URL specification from RFC3986 in the DID Resolution specification.
<manu> +1
<JoeAndrieu> +1
<Wip> +1
<JennieM> +1
<ivan> +1
<pchampin> +1
<dmitriz> +1
<TallTed> +1
RESOLUTION: Update to the WHATWG URL specification from RFC3986 in the DID Resolution specification
JoeAndrieu: This will come back around to the DID work later
manu: I think the DID spec already uses WHATWG
… Actually no, nevermind
TallTed: Can we push on the WhatWG to do an ABNF
manu: Not going to happen, we have tried
w3c/did-resolution#173
need some language about implementing https within private IP range #173
TallTed: Not made progress yet
<JoeAndrieu> +1 to labelling as editorial
<pchampin> from what I see, DID 1.1 is referencing WHATWG URLs for service ids and endpoints; the rest is RFC3986 🤔
DID Resolution Threat Modelling Update \[4\] (5 min)
DID Path PR - Final Call
ottomorac: Okay lets move to DID Path PR
dmitriz: Want to get a sense of what Joes objections are
JoeAndrieu: So one thing, Stephen and I are going to get on a phone and walk through our differences
… I was confused by a redefinition of relativeRef
dmitriz: I think Stephens comments where that we are using relativeRef as it is defined
… No change has been made or redefined
… The change is to point out how it interacts with the PathService mechanism
… This is also what we need WHATWG because it allows you to do combination
dmitriz: good that you two are going to chat
JoeAndrieu: Agreed, we can work through our issues
… hoping this is just miscommunication
manu: concerned there is a point where Stephen passes on this
… Want an agreement on new language here, or to put an issue marker
… This has been outstanding for a very long time
… JoeAndrieu can we say if there is not a resolution on these things, we will convert them to issues and merge them
JoeAndrieu: I am opposed to merging this PR. Stephen and I have honest confusion to clear up
… Hoping we can work through it
ottomorac: Thanks all
m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment already there: w3c/
<m2gbot> comment created: w3c/