DID Resolution work

[kdenhartog]

As we all know DID Resolution is a component we have to grapple with and there's a lot of differing opinions on this subject. I'm earmarking this issue for discussing this work so that we can communicate about the topic in between calls related to the topic. @tplooker I know you had some work on this and @swcurran had some ideas as well. Would you mind adding your proposal here to kick off the discussion? Pinging @esplinr @jovfer @dhh1128 @ashcherbakov and @troyronda as well because I believe they would be interested in the discussion.

[dhh1128]

I'm mentioning @peacekeeper and @talltree because I think both of them should track this conversation as well.

[tplooker]

I believe we should be pursuing architecture similar to that pre-existing with the uniresolver @peacekeeper is the below an accurate design representation?

Essentially, we should have a pluggable driver interface that allows registration of drivers to handle different did methods. This allows for both local and remote did resolution depending on the did method.

[talltree]

Tobias, what you are describing in your diagram is exactly what I believe Markus was describing to me when we talked last Friday.

The one difference between this and what Stephen has been describing is that you are anticipating a DID resolver function that has plug-in drivers, whereas Stephen is describing that all DID methods are just protocol modules(either dedicated to a DID method or integrated in with a VC exchange protocol). In that case, a remote DID resolver protocol would be just another protocol module.

On Sun, Jun 30, 2019 at 1:34 PM Tobias Looker notifications@github.com wrote:

I believe we should be pursuing architecture similar to that pre-existing with the uniresolver @peacekeeper https://github.com/peacekeeper is the below an accurate design representation?

[image: Screen Shot 2019-07-01 at 8 31 11 AM] https://user-images.githubusercontent.com/15972525/60401801-a67e9480-9bda-11e9-880f-409787cfcff9.png

Essentially, we should have a pluggable driver interface that allows registration of drivers to handle different did methods. This allows for both local and remote did resolution depending on the did method.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/101?email_source=notifications&email_token=AAZOITPUHJGHSHIWIDA3KALP5EKEZA5CNFSM4H3V2WG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY4TJNQ#issuecomment-507065526, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZOITPB3RZYL2YOKB4G4YLP5EKEZANCNFSM4H3V2WGQ .

[tplooker]

@talltree thanks, yes @swcurran I believe your approach would bring did resolution up into the protocol layer? I do see how this would benefit community velocity in the short term but I think it would become a problem in the longer term.

To me DID comms should have DID resolution as a base function rather than did resolution being an artefact of a particular DID comm message protocol. Put differently, I see DID comms as an arbitrary messaging standard between DIDs, if thats the case then DID resolution is a primitive and the application layer should not introduce the notion of DID resolution.

[tplooker]

Subsequent to the above diagram, this is how I would envisage peer dids being managed, simply as another driver that instead is designed to query what ever the pluggable storage mechanism is rather than a ledger or remote resolver.

[swcurran]

My $0.02CDN is that making the did:peer method a parallel to the public DID methods is not the right way to go - it should not be treated as just another method. It's fundamental to messaging, and discourages the use of public DIDs for that purpose - which is the right thing to do.

I'm OK with a DID resolver for public DIDs, but think it is more of an optimization. It's importance really depends on how many DID methods there winds up being. I think there are way more DID methods listed than are needed and what really matters for each DID method is the verifiable credential model that comes with the DID method, since that is biggest reason you need public DIDs.

Looking forward to folks building code to show how this works in practice.

[tplooker]

I think encouraging the usage of peer did's with DID comms is absolutely the right thing to do, however I don't think preference on a particular did method should be made at the primitive level. Granted the did resolver may appear to be an optimisation and for all intensive purposes for now it will probably present that way. However going forward it is an important source of innovation and leaving space for it will future proof did communications. IMO a credential model should not be tethered to a DID method, the verifiable credential spec should be used to set out a standard that all credential formats adhere to, which prevents all sorts of headaches such as holding and presenting credentials cross format.

[swcurran]

Sounds like we are agreeing on most things, but applying the emphasis in slightly different ways. In other words, minor differences.

While I too would like the credential models to converge (we all would), I don't think they will until developers are using multiple implementations at the same time - e.g. not siloed development. For that to happen, we need to get others learning about then using and contributing to did:peer and hence, using common agents.

[talltree]

Tobias, while I agree with your other points, I disagree that the peer DID method is "like the others". Although it is of course a DID method, it behaves entirely differently in that: a) it has no (direct) connection to any public ledger, b) it has privacy characteristics unlike any other DID method, and c) it is the Aries default for all connections. So I would not to treat it like any other DID method—I would build it directly into the "engine block".

On Sun, Jun 30, 2019 at 5:07 PM Stephen Curran notifications@github.com wrote:

Sounds like we are agreeing on most things, but applying the emphasis in slightly different ways.

While I too would like the credential models to converge (we all would), I don't think they will until developers are using multiple implementations at the same time - e.g. not siloed development. For that to happen, we need to get others learning about then using and contributing to did:peer and hence, using common agents.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/101?email_source=notifications&email_token=AAZOITN723HI22MXGET2W4LP5FDD7A5CNFSM4H3V2WG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY4WP4Q#issuecomment-507078642, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZOITLAKG7NX2NDYJ2M7H3P5FDD7ANCNFSM4H3V2WGQ .

[tplooker]

@talltree, interesting with that architecture wouldn't it mean DID communication message could not be sent or received by any other did method? I do think we should be encouraging did:peer in most circumstances but as the only choice in aries for messaging I feel could be quite prescriptive?

Perhaps it is a consideration for Aries, if it wants to be more of a framework for realising did based identity agents and we are valuing speed over end-state architecture then I could be convinced. But if we want aries to be the home of the reference implementation of a new messaging standard "did communication" then I think favouring one did method over the other isn't the right path.

[talltree]

@tplooker I didn't mean to imply that "building the DID peer method into the engine block" meant that you couldn't use DIDComm with any other DID method. I completely agree that you need to be able to use DIDComm with anything that has a DID. All I meant was that, if 99% of what you are going to be forming connections and communicating with is peer DIDs, then it makes sense to me to build that particular DID method directly into the "engine block". All other DID methods can be plug-ins/protocol modules/resolver drivers.

[swcurran]

Perhaps what we might agree on is that at the core level, Aries should support resolution for a variety of DIDs, but only support CRUD operations for did:peer. Any deeper support for specific ledger implementations would be at the protocol level (or at least, implemented separately from did:peer), since if you are needing to do beyond-reading CRUD operations for public DIDs, then you are doing something other than just messaging.

That would allow, for example, an Agency to use a public DID for an endpoint for all of the agents of it's clients The Agency itself would use a protocol for managing that public DID. Another enabled use case would be a public entity using a public DID in the establish connection protocol to eliminate the need for the invitation.

[talltree]

@swcurran I think that's a good idea: make DID resolution ("reads") a standard function, but only build-in support for the full CRUD operations ("writes") for peer DIDs. That corresponds directly to how other identifier infrastructure works, e.g., there are orders of magnitude more DNS reads that writes, and the same will be true of DIDs. So reading should be optimized, but writing is a special function. And since the typical Aries agents will write (i.e., create/assign) order of magnitude more peer DIDs than public DIDs, it makes sense to build in native support for creating/updating/deleting peer DIDs.

[peacekeeper]

I agree with @tplooker that probably Aries should support resolution of multiple DID methods, not just its own "peer" method. Your diagrams above are pretty accurately describing the architecture of the Universal Resolver.

As we know, the Universal Resolver is mostly useful as a hosted service, not so much as part of a native app. I think this is where an Aries resolver can be useful.

I'm interested in collaborating on this and testing for interoperability. For example, I hope a "local" Aries resolver will be able to talk to a "remote" Universal Resolver. This can happen over various "bindings", such as HTTP(S) or even DIDComm itself (in other words, the Universal Resolver can itself be an agent).

For reference, here are what I think are the relevant sections of the current (early) draft of the DID Resolution spec:

• DID Resolver Architectures
• Resolving a DID
• Dereferencing a DID URL

How do we collaborate on this? Do you want to make this a topic on one of the upcoming call? I'd be happy to prepare some thoughts...

[talltree]

@peacekeeper I totally agree that an Aries agent should be able to talk to a remote DID resolver—and that this function should be implemented as a standard Aries protocol module.

RE collaboration, +1 to covering this topic on an upcoming Aries call, and having Markus present on this. I think this work will tie in well to the work he is doing on the DID Resolution spec right now.

[tplooker]

Ok great I understand now, to clarify, by "DID resolution support", I meant merely the ability to do the read component of CRUD. To me the other operations are implemented in another module, @peacekeeper I believe you have been calling this a did registrar? And as you pointed out with your analogy to DNS @talltree many implementing agents (especially in the realm of personal identity) will have support to resolve multiple different did methods (so they can validate credential issuers), but only have support for registering and managing peer dids as that is the only method of dids others will ever know them by.

I hope that makes sense, to be explicit, perhaps the below diagram might help.

That diagram depicts the a hypothetical did resolution/registrar setup for a personal identity agent. Ledger 1 and 2 is where the credential issuers would have their public did's.

My outstanding questions are around did registration, @talltree I believe you touched on this the other day, essentially it is hard to have a uniform component for registering did's because every ledger implements things very differently, some ledgers require fees to be paid, while others have a long confirmation time. @peacekeeper perhaps you have some more insight on this with the uniregistrar?

[dhh1128]

Regarding Markus's question about where to discuss: In the upcoming Aries call this Wednesday, I am going to be presenting on the peer DID method. This might be a natural follow-on topic -- e.g., as I finish presenting, perhaps we pile into DID resolution in general as a topic?

On Mon, Jul 1, 2019 at 2:39 PM Tobias Looker notifications@github.com wrote:

Ok great I understand now, to clarify, by "DID resolution support", I meant merely the ability to do the read component of CRUD. To me the other operations are implemented in another module, @peacekeeper https://github.com/peacekeeper I believe you have been calling this a did registrar? And as you pointed out with your analogy to DNS @talltree https://github.com/talltree many implementing agents (especially in the realm of personal identity) will have support to resolve multiple different did methods (so they can validate credential issuers), but only have support for registering and managing peer dids as that is the only method of dids others will ever know them by.

I hope that makes sense, to be explicit, perhaps the below diagram might help.

[image: Screen Shot 2019-07-02 at 8 30 57 AM] https://user-images.githubusercontent.com/15972525/60464960-11e06900-9ca4-11e9-92b6-4113a34c4aef.png

That diagram depicts the a hypothetical did resolution/registrar setup for a personal identity agent. Ledger 1 and 2 is where the credential issuers would have their public did's.

My outstanding questions are around did registration, @talltree https://github.com/talltree I believe you touched on this the other day, essentially it is hard to have a uniform component for registering did's because every ledger implements things very differently, some ledgers require fees to be paid, while others have a long confirmation time. @peacekeeper https://github.com/peacekeeper perhaps you have some more insight on this with the uniregistrar?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/101?email_source=notifications&email_token=AAQ3JCBQRPCMTMEBFS24OBDP5JTQRA5CNFSM4H3V2WG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY7JFBY#issuecomment-507417223, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQ3JCHNEDZK5YPWLXJ37T3P5JTQRANCNFSM4H3V2WGQ .

[peacekeeper]

@dhh1128 this Wednesday sounds good, as I said I'd be happy to present on DID resolution and how it could be implemented with Aries?

[kdenhartog]

I've been researching thinking a bit about the flow of a create operation and came across this conundrum. Let's say that we wanted to create a did:ethr method which can support multisigs. If we were to do this with the protocol method proposed by @swcurran I think we would have to either extract the public key from the wallet (so the protocol logic can perform signing), or modify the returned signature format for this specific did method and the variety of other methods as well. If we go down the route of modifying the returned signature format in the rust layer, than it already requires significant changes. In my mind at this point it would make sense to contain it all within the rust core library so that the signing doesn't have to be implemented in each framework. However, I may be thinking about this in a strange way that can be resolved with a simpler flow. I'm open to ideas in resolving this, but from what I can tell it would make more sense to contain this logic in the core layer to prevent mishaps during the signing.

Another consideration that @tplooker reminded me of when he was asking why DIDs aren't used in the JWEs was that the pack and unpack method has a fairly strong dependency on resolution. This is because right now the JWEs contain only a key and in order for a a receiver of a message to verify the authenticity of the sender, they need to verify that the key is contained within the DID Document. In this case, pack and unpack would rely on resolution nearly every time (whether that be through checking local storage or a ledger) or the receiver doesn't have strong authentication. In this case, I think it makes for a bit of a messy situation to have the rust layer handling pack calling up to the protocol layer to resolve which passes the did doc back down, so that the rust layer can verify the key is in the did doc, and then return the message.

In both of these cases, the programming flow is the first thing that came to mind and we may be able to find easier approaches to this. In any case, I think they're important cases that we should take into consideration because these are two frequent use cases where resolution should be used I believe.

[peacekeeper]

Hello, after last week's Aries WG call, my sense is that it would make sense to work on two things:

1. Define an interface for DID Resolution in Aries, similar to the DIF Universal Resolver, in accordance with @tplooker's diagrams where both "local" and "remote" DID Resolvers are supported.
2. Define a "remote" DIDComm binding for DID Resolvers, as a better alternative to the HTTP(S) binding supported today e.g. by the DIF Universal Resolver.

I started working a bit on item 2. here: https://github.com/peacekeeper/aries-rfcs/tree/master/features/0000-did-resolution-protocol. It's only about 50% complete and not ready to even be proposed as RFC, but I wanted to mention I'm working on this, and I wanted to check what others thought were next steps, before going further? We could also have another dedicated follow-up call for this?

[dhh1128]

Markus:

I went and read the doc you started. It is excellent.

Could I collaborate with you to replace the section of the peer DID spec where READ is specified https://openssi.github.io/peer-did-method-spec/#read-resolve, with the more generic resolution protocol you've outlined? What I've written is redundant with what you've written, and your approach is better.

On Tue, Jul 9, 2019 at 4:13 AM Markus Sabadello notifications@github.com wrote:

Hello, after last week's Aries WG call https://wiki.hyperledger.org/pages/viewpage.action?pageId=16320115, my sense is that it would make sense to work on two things:

1. Define an interface for DID Resolution in Aries, similar to the DIF Universal Resolver, in accordance with @tplooker https://github.com/tplooker's diagrams where both "local" and "remote" DID Resolvers are supported.
2. Define a "remote" DIDComm binding for DID Resolvers, as a better alternative to the HTTP(S) binding supported today e.g. by the DIF Universal Resolver.

I started working a bit on item 2. here: https://github.com/peacekeeper/aries-rfcs/tree/master/features/0000-did-resolution-protocol. It's only about 50% complete and not ready to even be proposed as RFC, but I wanted to mention I'm working on this, and I wanted to check what others thought were next steps, before going further? We could also have another dedicated follow-up call for this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/101?email_source=notifications&email_token=AAQ3JCH4B3HATLHXUGO7IO3P6RQDBA5CNFSM4H3V2WG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZPZX6I#issuecomment-509582329, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQ3JCGVYXVGXG4QHIFCDITP6RQDBANCNFSM4H3V2WGQ .

[peacekeeper]

@dhh1128 : I just raised my PR for adding the DID Resolution DIDComm protocol RFC: https://github.com/hyperledger/aries-rfcs/pull/124

I'd like to point your attention to the following sentence in that RFC and see if you agree with it:

A special case of remote DID Resolvers occurs in the case of the Peer DID Method, where each party of a relationship essentially acts as a remote DID Resolver for other parties, i.e. each party fulfills both the requester and resolver roles defined in this RFC.

If this makes sense to you, I'd be happy to work on your suggestion above, i.e. replace the READ section in the Peer DID Method.

[dhh1128]

This is great! Thanks. I have merged the PR.

I do agree with that sentence. Let's work to update the Peer DID method to replace the READ section.

On Fri, Jul 12, 2019 at 5:18 PM Markus Sabadello notifications@github.com wrote:

@dhh1128 https://github.com/dhh1128 : I just raised my PR for adding the DID Resolution DIDComm protocol RFC: #124 https://github.com/hyperledger/aries-rfcs/pull/124

I'd like to point your attention to the following sentence in that RFC and see if you agree with it:

A special case of remote DID Resolvers occurs in the case of the Peer DID Method https://openssi.github.io/peer-did-method-spec/, where each party of a relationship essentially acts as a remote DID Resolver for other parties, i.e. each party fulfills both the requester and resolver roles defined in this RFC.

If this makes sense to you, I'd be happy to work on your suggestion above, i.e. replace the READ section in the Peer DID Method.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/101?email_source=notifications&email_token=AAQ3JCAMYZ25GX37OLFZSJLP7EGMZA5CNFSM4H3V2WG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ3CXNI#issuecomment-511060917, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQ3JCEPMEFFKYT7T3WB7W3P7EGMZANCNFSM4H3V2WGQ .

[peacekeeper]

@dhh1128 Here's a PR to replace the Read section: https://github.com/openssi/peer-did-method-spec/pull/97

(We may have to discuss/iterate on this a bit..)

[TelegramSam]

Closed as discussed in Aries WG Call 2019-11-13