Meeting minutes
<Wip> Meeting Decentralized Identifier Working Group
agenda review
manu: Would like to get a DID Methods standardization working group chartered at W3C. Any ideas on the timing of establishing such a group, and who would like to know who the staff would be. Not being done here, so would like to cover the process that most of us will be involved in.
… one of the chairs is here. Would like to discuss to move it forward.
DID Methods standardization Working Group
pchampin: I have too much on plate to take it, but am default so will help. Can help starting on moving it forward.
manu: Happy to move draft charter forward. Need a place to work on that. Will work with Marcus, but need W3C to provide a place to do this.
… Can the repo be made so that we can create a PR into the Draft Charter. Marcus as one of the DIF DID Method Standardization chairs can help coordinate with that group.
wip: Adds another working group for the same people. Seems like it might be a lot on people's plates.
<manu> It is a concern :)
DID Core
w3c/did-core#877
manu: Not a lot has changed -- the big PR that rationalizes DID Core to depend on the CID spec.
… A tricky one -- hard to get it easily aligned.
Wip: In some places there seems to be normative changes. Notably around "id"s. Changing to URL.
… "identifiers used in verification methods can be changed to URLs"
manu: There is the use case that a DID Method points to a URL. Only change was made to the top most id (root). For all other IDs, noted that DID syntax is allowed -- although CID allows URLs.
… For service endpoints -- most of them are URLs -- but that has always been allowed.
… This PR allows for verificationMethods to be URLs on the web. If we don't have that, we lose the ability to do that.
Wip: This is a change. Is it a concern for others?
smccown: Not a problem. Does come back to a concern with LinkedData, as you can't verify it. You can't sign it and verify it and so it could change. We have accepted that in the past but its on ongoing concern.
JoeAndrieu: There has not been a use for URLs verificationMethods. There is no definition of how the VM is secured when it is a URL, unlike for a DID.
<Zakim> JoeAndrieu, you wanted to say it is not EVERYTHING must be a DID
manu: Could make it that it has to be a DID. If we say it has to be a DID, and they use did:web, we have the same issue. Entirely dependent on the DID Method. There is no protection in the base version of DID Web.
<dmitriz> +1 joe
JoeAndrieu: The difference is that did:web is a published method and it is available for discussion, weaknesses etc. If you just put a URL, you have not of that. Maybe SHOULD be a DID, and talk about the issues.
<dmitriz> (re SHOULD, and mentioning the issues in the spec)
<Zakim> manu, you wanted to suggest I just keep it at MUST be a DID. and to suggest SHOULD :P
markus_sabadello: Missed the comment.
manu: Reviewing the spec...its in the table about IDs and notably that a VM is a DID or a map.
<Wip> https://
manu: trying to decide on SHOULD or MUST. Since did:web could be used, then URL is the same. Maybe put it back to MUST, and then a separate discussion on backing off that.
PDL-ASU: Specs often talk about the securing and the issues. If the URL was a hashlink doesn't that give the security.
manu: Will open an issue to deal with this point separately. Re: PDL-ASU point -- there is not a way to make the hashlink of a fragment (as this is likely to be). So hard to handle via an HL. Could be ways to do that, but hard to do.
<PDL-ASU> Agreed that's the point Joe was raising. Sounds like we should write that down. :-)
DID Extensions
<Wip> https://
Wip: Please take some time to review the issues. There are pending close issues. Any comments now on those?
… There are some fun issues, so please take a look.
manu: Heads up that Wip found that the DID Extensions build is not working properly, but it has now been fixed, and the auto-publishing to TR-space is working.
DID Resolution
w3c/did-resolution#51
Wip: We'll go through the issues.
Wip: Do we want to define a way for a resolver to say what it supports?
Wip: Goal -- go through these issues to identify ones that need to go in the spec -- and looking for volunteers.
markus_sabadello: Lean not, but could help with the practicality argument -- a standard way to ask a resolver supports.
manu: Can just ask to resolve a DID of a type, and it either does or doesn't.
manu: That said -- we would not encourage anyone to use a resolver blindly -- it would be done at coding time and the human trust (and features) would be evaluated at that time. Not need dynamically.
… Gets into the /whois capability that allows a DID to express information about itself. Don't put in the spec, but incubated in practice/other spec, and then see if we want to add it into the core spec.
<Zakim> JoeAndrieu, you wanted to avoid programmatic discovery because trust should not be automated
dmitriz: Another vote for not in the core spec. Echo Manu's comments.
JoeAndrieu: +1 to evaluating why to trust a resolver -- not just a what it supports.
w3c/did-resolution#39
Wip: Resolution? Enough to close?
<PDL-ASU> note the concerns in issue 51 and close it - my view
markus_sabadello: Can be solved with a new parameter or resolution option. Do we want them in the spec or in the extension? In this case, feels like more for an extension.
Wip: Anyone want to carry it in the main spec?
manu: Make it an extension.
w3c/did-resolution#40
markus_sabadello: This is an extension. Makes them easier to consume but could be an extension.
<Zakim> JoeAndrieu, you wanted to ask about expansion
<Zakim> manu, you wanted to support expansion in core spec.
JoeAndrieu: Not sure of the idea of extension -- DID Method specific. Can't verify the DIDDoc if there are extensions.
manu: Feature is only for a DID URLs -- fragments. "#key-1" -- should use automatically mean that the DID is prepended.
manu: Should be in the core, so there is no need to repeat the DID everywhere and creates opportunity for errors.
markus_sabadello: Not DID Method specific. You get the DIDDoc as is, and then could do transformations.
<Zakim> JoeAndrieu, you wanted to say it still doesn't apply to did:btc1
JoeAndrieu: You lose independent verification if the resolver gives something back other than the DIDDoc.
manu: Presumed it to be a flag so not needed.
w3c/did-resolution#46
markus_sabadello: Could be supported by an optional flag. Would not be a DIDDoc, and the resolver would not return a DIDDoc. Flag could result in a JWK set in the dereferencing. Use cases in OpenID.
manu: +1 to providing an option. Resolvers may support it or not. Extension - not in the core spec. Having to define transformational algorithms would be needed.
ivan: Not sure why saying not a DID. A DID is a CID, and the CID allows you to do that. Should be valid DIDDoc.
<Zakim> JoeAndrieu, you wanted to say its easy to have a DID URL to return JWKs, but they cannot be canonical
w3c/did-resolution#52
JoeAndrieu: Think it is out of scope. DIDDoc is about getting the canonical DIDDoc. Can get other things already. What you can't infer is that the JWKS are canonical. Going to confuse the security model.
Wip: Could be an extension.
markus_sabadello: Could be useful as metadata properties. Concept of "network" (namespaces within a method) is not in the DID Core -- is used by some Methods. Could be useful to return other information. I think this is an extension.
manu: +1 to extension.
<JoeAndrieu> +1 to extension. seems useful for some methods
w3c/did-resolution#69
manu: Not clear what a network is. No examples.
w3c/did-resolution#87
markus_sabadello: This has been addressed -- exists. We have resolution and dereferencing result. Pending closed.
manu: Good idea to settle on Problem Details. Handled in other specs and works well. Nice if the DID Resolution spec so there was consistency across the specs (DI, DID, others)/.
ivan: Formerly -- if have a DID error, inherits the CID error, so that covers it.
Wip: Argument to put it in the spec. Any takers to put it in?
manu: I'll volunteer.
w3c/did-resolution#10
markus_sabadello: This is a bigger topic around caching. Could be a mix of TTL and other metadata parameters. Similar to DNS -- could follow that model, with a set of parameters.
… In the core spec.
<Zakim> JoeAndrieu, you wanted to say did-core, yes. controller-specified
manu: +1 for core spec. Multiple levels here. Speak to HTTP caching. Avoid discussions like TTL within verificationMethods. Can of worms there.
JoeAndrieu: Should be in DID Core, and that the DID Controller can set. Needs to be based on what the Controller sets -- not at the DID Method level.
swcurran +1 to DID Controller.
<JoeAndrieu> Could be an extension for did-core (not in did-core itself)
manu: DID Method spec would say how to expose/caching. DID Core would say how to express this.
<Zakim> JoeAndrieu, you wanted to say just a property
<manu> concerned about it being a property -- worried about security concerns there -- controllers might do something that is not supported by the DID Method (creating security vulns)
Wip: One issue to go in. Most others are extensions.