Meeting minutes
DID Rubric & Traits Special Topic Call - 30th of April
<TallTed> https://
ottomorac: We will be continuing the discussion around DID Rubric and traits. Figuring out the next steps for integrating this work
Allow verification method identifiers to be HTTPS URLs?
<ottomorac> w3c/
ottomorac: Current DID documents do not allow other the DID URLs to be IDs for verification methods
… This issue tracks if we should change this
manu: This came up because the controlled identifier spec talks about https URLs
… it uses them for its IDs
… Since then we have moved the CID spec through the standard process. It will become a formal standard
… Some feedback was, why do we have the CID spec again..
… It is true the DID spec can do all the CID spec can
… did:web can do all that the CID spec can
… So applying that to this issue, I think the answer is no because if someone wants to refer to a https based verification method they can just use did:web or its variations
<Zakim> JoeAndrieu, you wanted to say we should let the CID spec define that
JoeAndrieu: +1 to manu, we should not water now our security guarantees. CID spec was a compromise
manu: To be clear, this means no spec changes. The text stays as is
Guidance on Normalization Rules Enforcement
<ottomorac> w3c/
ottomorac: This issue relates to string URIs in the serviceEndpoint property
… manu requested we use the WHATWG working group spec for normalization
… KevinDean proposed a direction
manu: On the proposal from KevinDean, a couple of things to talk about
… First, what would it take to move the CID spec into this group. Trying to keep these specs aligned in different working groups and timelines is very difficult
… Second. The problem with URIs is we should move to the URL spec because the browser vendors have effectively killed URIs
<ivan> +1 to manu on URL vs URI/IRI
manu: I think using URIs and RFC3986 is not the best direction. It is the URL spec that WHATWG is in control of
<JoeAndrieu9> also endpoints must have an end, i.e., they actually must be locators (URLs) not just identifiers (URIs)
<smccown> +1 for moving to URLs
manu: I don't know about the normalization rules, will check the CID spec
… I think there are some normalization rules in the URL standard. If there are we can just use those
… If not we cannot use RFC3986. There will be all sorts of interop issues
… That is why the URL standard was created to address these
… I understand where you are trying to go Kevin. I think the longterm path is to move the CID spec into this group
* notes scribe lost audio
<ivan> /me there is an URL equivalence in the URL spec: https://
Kevin: there is not hard and fast set of rules for URL normalization....
<ottomorac> Kevin: happy to close this
<ottomorac> Kevin: once we have control of the CID spec we can change it later
manu: To answer the first question KevinDean asked. A DID is a URL per the definition of a URL in the URL standard
… I searched for the words canonicalization and normalization in the URL standard and they don't exist.
It says the spec defines canonical forms of ***
… The only examples I can see they give is for the windows drive path.
… There is a bunch of code point canonical rules e.g. % encoding
… You could argue there are normalization and canonicalization rules in the URL standard
… If it is not defined in the URL spec, then the DID spec is not going to define additional rules
… in the CID spec we currently do the right thing. We said the ID value must be a URL conforming to the URL standard
… We do say URI, I think mistakenly in the also known as
… This is the wrong thing if we want to say everything is a URL
… We might want to add to the spec to say, that all rules for normalization and canonicalization are defined in the URL standard. That addresses this issue
<JoeAndrieu9> https://
ivan: I also didnt find normalization in the URL spec.
… To take on the CID spec to be maintained, would require rechartering this WG
<Zakim> JoeAndrieu, you wanted to mention "serializers"
KevinDean: Given that the URL spec is meant to replace the URI spec, it is removing the normalization guidance provided in this spec
<Zakim> manu, you wanted to say, yes to a recharter - eventually :)
JoeAndrieu: In the URL spec, I think the define parsers and serializers. And serializers are handling the normalization, just not using those terms
… +1 to referring to that spec and removing a reference to URIs
manu: +1 to ivan and JoeAndrieu. There are enough algorithms in here for people to look at recognise that these are canonicalization rules
… KevinDean's point is interesting, but again all browser vendors dont implement that stuff anymore
… Also, if you have a URL and that URL has query parameters. Position matters for those parameters now
… I don't think this changes anything. I still think we can point to the URL standard for the rules to address this issue
… Also, responding to ivan. Totally agree that we would have to recharter to take on the CID spec.
… This is a long term thing. In our next recharter we should do that.
… The best time to do that might be when we charter the DID method work
… We could send them both out in the same vote
dmitriz: minor point, removing myself from queue
ottomorac: Seems like we have some direction on this issue, thanks
DID Resolution Architecture Issues Discussion
<ottomorac> w3c/
Add examples to illustrate different DID Resolution Architectures #131
Add examples to illustrate different DID Resolution Architectures #131
markus_sabadello: This is a good idea. To add some more concrete diagrams for different architectures
… The current architecture section covers some concepts. Mentioning local and remote resolvers. And talks about how the read operation can be verified or not verified. There are some diagrams in the section right now, but all of it needs some more work
<markus_sabadello> w3c/
markus_sabadello: The diagrams that exist right now are quite high level. There is an open PR that updates these diagrams
<ottomorac> (link to diagrams from Markus)
markus_sabadello: This PR 143, adds additional diagrams for more concrete architecture
… For example the different ways that resolution against the bitcoin network could be implemented
<Wip> +1 that looks great markus_sabadello
manu: Just a quick note on the diagrams markus
… We are going to be required to add accessible descriptions for them. We would fail the accessibility review without those
markus_sabadello: Another thing I am doing in this PR, is changing to svg files. These include a short caption about what the image is
… Wondering if that is enough
manu: My experience is they require us to indetail describe what is in the picture
… you have to describe to someone who cannot see literally what is on the screen
… not sure if that has changed, but i doubt it
Complete threat modelling analysis for different DID Resolution architectures #132
<ottomorac> w3c/
Wip: yes, I think this came up on our discussion before.... The diagrams describe different architectures, it would be good to do an analysis of each and this could fit into the security considerations....
ack: JoeAndrieu
<Zakim> JoeAndrieu, you wanted to discuss threat modeling
JoeAndrieu: +1 to making it a separate note. We dont want to be concerned about making it concise
… I think it makes sense to look at each of those architectures and break down the threats
… I am keen to help with that work
… The plans for the security interest group is to great a guide for all groups to do some threat modelling as part of their spec development work
… Getting ahead of this is a good idea
markus_sabadello: Wondering if it is a separate note, why would we still have a security considerations in the main specification
… I would have thought this would go into the security consideration section
… Not really sure what the difference would be between the note and the security section
<Zakim> JoeAndrieu, you wanted to say good question
JoeAndrieu, thats a good question. Still trying to figure it out. I do think there are security considerations that would not be part of threat modelling
… Simone is still figuring out what threat modelling would mean for the W3C groups
… My invitation to the group is lets help figure out what this means by applying it to our spec
<ottomorac> Wip: yes my sense is that a separate document could then inform the security considerations , we can figure it out
Add DID Resolution architecture security and privacy considerations #133
<ottomorac> w3c/
Wip: not much more to add to it... main thing is what considerations do implementers of the resolvers need to have in mind
markus_sabadello: In the current section about architectures there are some short comments about some of these considerations
… For example there is a sentence that says when you use a remote resolver service you could use a VPN. Or some form of authentication. Or query multiple resolvers to check results
… These ideas probably need to be expanded and elaborated on so they can be added into the security considerations section
<JoeAndrieu9> RFC 3552 Guidelines for Writing RFC Text on Security Considerations
JoeAndrieu: I think we should improve our guidance for what should go in security and privacy consideration section
… In our work with Simone we have incorparated RFC 3552. I think we should point DID method implementers to this RFC or additional guidance for writing these sections
Update future work section #134
<ottomorac> w3c/
Wip: yes this also came out of our discussion with ChristopherA...
<smccown> Is RFC 3552 the newest document? The spec I'm finding is dated 2003
<JoeAndrieu9> (not sure Steve. It's the one Simone referred me to)
Wip: one option could be we remove the section completely, or perhaps we update and add some new future items....
Wip: interested in what the group thinks?
JoeAndrieu: I think we should keep this issue around. We are early in our cycle to know whats future
… Lets circle back to this when we are closer to the finish line
markus_sabadello: I agree with JoeAndrieu. Lets come back to this
… We have discussed in the last few meetings some enhancments but put them as issues in the extensions registry
… Other topics we arent sure yet how and if we might incorporate them into this spec
… For example Christophers work on gordian and selective disclosure etc
Should we use JSON or JSON-LD for the resolution spec?
<ottomorac> w3c/
ottomorac: Briefly touched on this in the APAC call. manu voiced wanting to just use JSON
manu: Yep, since them markus_sabadello has mentioned that a benefit of using JSONLD means you could fully digitally sign the response that came back.
… Resolvers could sign all their responses
… I found this compelling as an argument
… Wondering if we could through data integrity still use JSON and use JCS based signatures instead
… We could optionally express this response using JSONLD
… Meaning we could keep it JSON, Use data integrity with JCS to sign the responses. And not flat our require JSONLD processors
… Trying to find a way to define DID resolution responses in JSON
… We almost certainly will have a context. If we do that, we should probably change the context from v1 to v1rc1
… We have found people will ship v1 to production so the group can't easily change the context
… This creates confusion
… Lets use v1rc1 for all examples in the spec to contain some of these issues
ivan: Not sure I understand manu. First, I raised this issue a while ago. I think what manu said about using JCS is fine. We can and should use it. That should not be enough of an argument to turn it into JSONLD every time
… Not sure I understand how the context file comes into the picture. If using JSON there is no context
manu: ivan using the context file is about trying to find a middle ground. So people that dont like jcs or rdfc can both be happy
… It would be nice if we could digitally sign the responses from the resolver. If we use data integrity and jcs we dont have to go to rdf
… This doesnt mean that DID resolvers cant also use a different data integrity mechanism
… We don't want to cut ourselves off from future usecases. We say please include the context. Here it is
… If we do that, then I think we leave all options open
markus_sabadello: We don't currently talk about signing resolution responses in the spec. But it has come up in the discussion
… Commenting on manu, if we use jcs then there is no graph canonicalization. However, I thought if you use data integrity with jcs you would still only do that with jSONLD document.
… didnt realise you could do that with plain JSON
<dmitriz> @markus - that's the cool thing about JCS canon -- you can use it without @context! :)
In verifiable presentations you use JSONLD. VPs contain VCs which are JSONLD. In my mind DID document and resolution results work ion a simlar way
ivan: What manu is saying, if we introduce a context then we are using JSONLD. We have to define formally a vocab. Adding complexity. Implementers will see that a context is necessary. Some will complain that they dont want to use JSONLD etc etc
… For applications like VC, there are good arguments why JSONLD is useful
… For something else, like resolution, the resolution data that you use is not combined with other data
… if you are not combining, then rdf is not necessary
<Zakim> manu, you wanted to comment on including signing.
manu: agree with ivan. With DID resolution I am not sure if this is true
<smccown> JSONLD is really useful. However, from a security perspective, the "linked" parts never seem to be covered by signatures.
manu: I am just trying to keep the door open
<JoeAndrieu9> once we start signing it becomes an open system unless we restrict the signing to a specific algorithm
manu: we might want to include signing in the DID resolution spec. It keeps coming up
… We should say it is possible to sign these things
<ottomorac> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/