Meeting minutes
Wip: welcome
… DID Resolution architecture is our topic today
DIDWG Chair Update
pchampin: Gabe has had to step down.
… Dan Burnett has been helping, but also needs to step down. We are looking for another chair. Otto has agreed to help.
… This should be official in a couple days
ottomorac: Thank you. I'm here to help out.
<manu> o/ Woo! Welcome Otto, great to have you here -- wonderful to have you as the new Co-Chair of the DID WG!
<markus_sabadello> Thanks Otto!!
Wip: Thanks, Otto.
Global Digital Collaboration around Wallets
Wip: brief announcement: the OWF is in touch with W3C to host conference around wallets
… Nothing formally announced, but perhaps the first or second of July in Geneva.
… Currently in planning.
<ChristopherA> link to that event? I'm a L0
Wip: I think we should be in that conversation. I was surprised that wallets was more about credentials than keys.
manu: I'm interested in what the event is going to be about.
… There's been a push in the EU against DIDs by some of the folks in the EUDI initiatives.
… It would be good for some of us to show up, but at the same time, It's not clear how closely the OWF is associated with EUDI or not.
ivan: I was part of some of the discussion with EU folks. More on VCs than DID.
… the discussions were very useful. We could give them good arguments for why VCs should be used.
… They seem to be much more positive with VCs now
… The event in Geneva grew out of a panel that was held in Davos where Seth Dobbs, CEO of W3C was present and talked about W3C technologies VCs and DIDs, etc.
… The goals appear to be a bit vague, but its more like bringing together all possible partners together to see where the work should go
… It's more a general architecture than about DIDs or VCs.
… This is not a W3C event. We were invited.
… Seems that W3C is the main promoter in terms of privacy.
… At least in Davos, privacy was discussed
… For the time being its worth being present
ChristopherA: I have the same reservations that Manu has.
… Plus there is an entire class of participants, e.g., in the hardware level
… who are totally not represented. I have some concerns there.
… Joe, maybe you can find the document
… A RWOT SICPA paper comparing wallet flows for blockchains with financial, compared to similar flows for identity wallets.
… I don't know that I can go.
Overview of the DID Resolution Architecture Section
wip: What changes should we consider?
markus_sabadello: we are defining resolution function in Section 4
… we are about to remove the resolveRepresentation function
… We've already talked quite a bit about options and metadata and algorithm
… This is described as an abstract function. No particular protocol
… We define inputs and outputs, but how it is implemented and deployed
… DID resolvers could come in different forms. Remotely overy HTTP, or just a local library that doesn't communicate with any external systems.
… Section 7 is about DID Resolution Architecture to discuss this
… The way the section is now, it's divided into two sections, method architectures and resolver architectures.
… The section on method architectures tries to cover how a resolver reads information from the VDR
… When you invoke a resolver, it reads data according to the DID method spec. This section covers how that is done.
… For example, no assumption should be made that a blockchain is being used or that interaction with remote networks are required.
… We discuss verifiable read and unverifiable read. Depending on the DID method, this could be done in a way that has some sort of cryptographic verifiability or not.
… For example, a resolver resolving a bitcoin method might do that by using an explorer api (and not really know if the answer is correct)
<ChristopherA> (I found the link to the RWOT paper on wallet architectures "What’s in Your Wallet?" https://
markus_sabadello: Or it could run its own bitcoin node with full cryptographic verifiability
… What is verifiable and what are the trust characteristics.
… Then the Resolver Architecture section talks about the other side of the resolver.
… How a client using a resolver interacts with the resolver.
… Similar considerations about local and remote bindiing.
… Not about how the resolver gets the DID document, but about how the client invokes the resolver.
… This binding could just be a local library that's a resolver.
… Or you could use a remote service.
… We discuss a bunch of considerations when using those architecutres
… Then additional considerations about proxies, with resolvers calling other resolvers.
… And subsection about different parts of the process handled by different resolvers
… There are several issues addressing different topics for this area
… What kinds of things do we want in the spec?
<ottomorac> Thanks Markus great overview!
wip: This section already exists. Has a bunch of issue tags that need help.
… ChristopherA can you share your ideas in these issues?
ChristopherA: There is a lot more richness going on than what is even in this simplified proxy model
… You have some complicated relationships.
… You might trust code in the browser. Or there might be a "trust zone" or SSH-capable FIDO keys, an airgapped connection to a hardware device where they don't trust the bluetooth chip.
… There's also richness at the other end: the resolver that you speak to may be able to do a measure of trust, not just in that particular resolver, but also what that resolver can do.
… like with BTCR where there are multiple phases ... you might have initial resolver that does initial work
… but then when you want the other parts, you might need to talk to another resolver with more capability
… For example, most bitocin nodes are pruned, but you can run a full now (and need to for full history)
… Also you might want to check via multiple explorers, even randomized to make sure you aren't relying on any particular one.
… This allows "broad internet consensus" to help
wip: Thanks, Christopher
… What actual things should we add to the diagram?
<ottomorac> Or should we jump into issue 79?
wip: I read this section before the call. It's definitely a work in progress, but those flags... some are really good
… Some things that came out: the best case is a local resolver running verifiable reads on specific methods, clear that each method's "reads" are going to have different levels of confidence.
… Markus?
markus_sabadello: Thanks, Christopher. A lot of what you said is possible on a high level with the language we have already.
<ChristopherA> Here is 6-year old diagram: https://
markus_sabadello: For example, "browsers have certain trusted ways of executing code", I think that is what these subsections are trying to explain.
… Local/remote binding, verified/unverified read
… Points about multiple resolvers are all ways of making the read operation more verifiable
… We could add these as examples. They'd fit right in.
manu: Looking at #79. There are valid concerns. And noting Markus's concerns. But I don't know if the current text doesn't strike the right balance.
… the sections Markus put in are good, because they establish what people should be thinking about
… Also +1 to Christopher's point, we don't want to lock down too far in version 1.0
… Maybe there are statements in there locking things down prematurely. I'd support fixing that.
… Also, this might be something more for security considerations rather than where it is now.
… but sometimes it's better to have something in the considerations that you don't want to get lost
… I'd rather us write more than less as long as it doesn't lock anything in normatively
… Some people complain about verbose specifications, but this is a core part of the ecosystem and we should give it the amount of text that explains it clearly
ChristopherA: I don't think we want to have something as complex as this image (in chat)
… My point is that "it's a lot richer" and we need to convey that to people A variety of things going on here that they may not be aware of.
… A lot of newer homomorphic and zk proofs are partially done in hardware.
… In the diagram, there's a big dotted line that isn't actually a network connection, it's a secure multi-party computation going on, not a web connection in the classic sense.
… What's the right minimal amount explain this complexity and richness.
<ottomorac> 
ChristopherA: This is all applicable to revocation, which could happen because of a quorum
wip: we should try not to put things in boxes
… I agree with Manu, some of this does go in Security considerations, or at least in there as well.
… maybe even if those sections just flag ot read the other section
markus_sabadello: regarding the richness, the current diagrams are completely generic
… I tried to make them so they apply theoretically to all did methods
… Should work for did:key where everything is local, as well as did:btcr or did:btc1 where there is more complexity.
… I like the idea of some examples
… We could do some more specific versions of the different architectures
<Zakim> JoeAndrieu, you wanted to mention threat modeling
markus_sabadello: We can illustrate these differences a bit more as they apply to certain DID methods
JoeAndrieu: What we're nuzzling towards is doing some threat modelling.
JoeAndrieu: If we do those architecture diagrams with some of the sensibilities in the security group, which are still sort of nascent, Adam Shostack starts with data flow diagrams, analyze threats for that architecture, show difference in the threats that emerge because of different architectures.
JoeAndrieu: Not quite ready to kick that off right now, but that might be where we should be going.
ottomorac: I was wondering: we have this diagram with Chris that shows some architectures.
… do we have some examples of different architectures that we could study or describe in the spec?
markus_sabadello: I wanted to ask some of the open issues we have about authentication, ... , selective disclosure.
<ChristopherA> (related to this specific issue is also https://
markus_sabadello: so far we've been talking about trust, but there are also additional features under consideration
… should we specify that resolvers can have authentications?
… Or there should be ways to selectively disclose parts of a DID document
w3c/did-resolution#79
wip: I agree with Markus, which of these features do we want to add to the resolution spec
ChristopherA: To add a little richness. There was a mention of how a client trusts a resolver, but there are also situations where a resolver must be able to trust the client.
… For example, a resolver might be able to do basic resolution, but elide specific data about specific keys
… In a public API you just get the key you need, just what you need
… but then you might need to authenticate to resolver service or some kind of OCAP authorization from issuer or holder to reveal the elided information
… The trust CAN go both ways
wip: I think all of these topics are important, but as I read it, I agree some of these are too big
… e.g., DID Resolution enables extensions, so are these really not possible or just not yet extended?
<Wip> w3c/
<ChristopherA> Maybe a "future work" session?
wip: One thing we might want to add to the spec would be #38 about authorization and authentication
<ottomorac> trust in the resolver is interesting for sure
<ottomorac> its almost the same as trusting the issuer
<ottomorac> a fuzzy question to tackle
wip: this has been an interesting discussion. Are there issues we should be creating? Like adding examples of different architectures.
… Maybe one for threat modeling.
markus_sabadello: I think what Christopher said, I think we should mention/explain is what a client is and how to deal with elided v public components of a DID document.
… we should talk about it as a possibility, but are we ready to build it into the algorithm.
… That feels like a lot of work, so maybe we start in Security considerations that these are possibilities
… But it is a pretty fundamental question, saying effectively that the result of the resolution process depends on who the client is and what the client is providing.
… We had always been saying we have the DID you get the DID document, no variations.
ChristopherA: I wanted to pop up a level. Tactically, we have a limited scope to do a 1.0 spec. We're focused on the resolver.
… We could just do the minimal viable thing. But part of why I'm motivated to talk about these broader issues is a response to what is going on with EUDI wallet and mDL and things of that nature.
… we have offered to the world a technology that has superior capabilities to centralized solutions
… Somehow conveying that we should use elision with committed, but unrevealed endpoints, and the ability to work with different kinds of hardware, etc.
… When someone says DIDs doesn't offer anything to overcome XYZ, we can say, yeah, but you don't do ABC
<ottomorac> Should the did resolution categories maybe follow the did methods beings standardized?
<ottomorac> after all those would be gaining notoriety in the community...
wip: Maybe there's a type that can still resolve to a DID document compatible to the API
<Zakim> JoeAndrieu, you wanted to speak against variations on DID document
JoeAndrieu: Standardizing that you might get back different DID Docs on who you are opens the door to widespread late publishing problems.
JoeAndrieu: They might not be able to verify that they're working w/ a particular DID... we've seen use cases where results of the entire DID Document withheld, but to have variations on it introduces a challenging security context.
Manu: yes a light +1 to what Joe said...
manu: Yeah, a light +1 to what Joe said. I think we should explore the space. I have the same concerns.
manu: As editor, reminding folks, we can't add new features.
ChristopherA: I agree with the concerns if it's just the elided document.
… but there is a way to demonstrate they are "the same"
<Wip> +1 I also think it might be possible. Needs experimentation though
ChristopherA: It's just the commitments are made, but when you get the more detailed document, you see all the commitments revealed
… So they are one document and they can have one trust point.
<manu> +1 to finding a middle ground
otto: the other thing I'm wondering. Given we are standarding DID methods, that is itself an endorsement
<Zakim> JoeAndrieu, you wanted to challenge the features comment
<Wip> w3c/