[DID Reference] REQUIREMENT: Ability to query the list of DID Methods found on a particular DID Resolver or Ledger

[mwherman2000]

Related to but different from #25

[dmitrizagidulin]

I don't think this requirement makes sense. Can you say more about it?
There's no real mechanism to reference a ledger, outside of a particular method.

[mwherman2000]

In the real world, enterprise applications are going to have work with multiple DID-compatible Ledger networks. When presented with an arbitrary DID, how can an app know which Ledger Node Service endpoint of which Ledger Node (INDY ARM element 35) to resolve the DID against? ...without using static configuration files. In addition, some organizations will have, possibly multiple, internal Ledger networks (36); some will also have, possibly multiple, external Ledger networks.

Apps need to be able to query the Ledger Node Service endpoint of the known Ledger Nodes (Ledger networks) to determine which DID Methods can be found there.

Reference: https://github.com/mwherman2000/indy-arm/blob/master/README.md#3-did-resolution-viewpoint

[peacekeeper]

@mwherman2000 , do you mean:

The ability to list all DID methods that utilize a certain ledger technology? E.g. return a list of all DID methods that use the Ethereum blockchain, --> uport, jolo, erc725? This is hard for a number of reasons. Not all DID methods even use ledgers. There is no central registry of all DID methods that could be used for such lookups. Theoretically there could even be DID methods that use multiple ledgers, or one that combines a ledger+IPFS, or many other kinds of combinations of technologies. Also, I don't really see how this would be useful.

Or do you mean:

How can you work with multiple ledgers, networks, etc. that use the same DID method but different instances of the ledger, network, etc. For example "mainnet" and "testnet". This can be easily addressed in the DID syntax, and we have already seen examples, e.g.:

• did:sov:WRfXPg8dantKVubE3HX8pw -> DID using the "sov" method on the Sovrin mainnet.
• did:sov:stn:WRfXPg8dantKVubE3HX8pw -> DID using the "sov" method on the Sovrin testnet.
• did:erc725:ropsten:2F2B37C890824242Cb9B0FE5614fA2221B79901E -> DID using the "erc725" method on the Ethereum "Ropsten" test network.

It would be up to the DID method spec to define this syntax and how it is interpreted by a resolver;

[mwherman2000]

The ability to list all DID methods that utilize a certain ledger technology?

No, I simply mean the ability to list all the DID methods available at a particular Ledger Node (35) Service endpoint.

[mwherman2000]

SUGGESTION: When you query/try to resolve the following:

did: OR did: OR did:?methods

The DID Resolver Response returns a collection of (fully qualified) methods. e.g. '[ did:sov, did:foo, did:bar ]`

[mwherman2000]

Maybe it doesn't make sense to be able to direct these types of queries (the above example and #27) to a particular Ledger Node ...but it does make sense to be able to query these against a particular DID Resolver Node (element 41 in the INDY ARM).

[peacekeeper]

@mwherman2000 Your last comment now makes more sense to me than the ones before. Yes I can imagine that a DID Resolver could support a function that returns a list of DID methods that the DID Resolver knows how to resolve.

But this has nothing to do with the syntax of a DID or DID Reference or DID URL, as discussed e.g. here and here.

[mwherman2000]

@mwherman2000 Your last comment now makes more sense to me than the ones before. Yes I can imagine that a DID Resolver could support a function that returns a list of DID methods that the DID Resolver knows how to resolve.

@peacekeeper For this to happen, does some sort of syntax specification need to allow for it? If so, which one? Where/how do we specify support for did:?ping and/or did:?methods queries (or anything similar)? ...where in/which ABNF syntax specification do we allow for these types of constructs?

[talltree]

On Wed, Feb 20, 2019 at 4:16 PM Michael Herman (Toronto) < ***@***.***> wrote: @mwherman2000 <https://github.com/mwherman2000> Your last comment now makes more sense to me than the ones before. Yes I can imagine that a DID Resolver could support a function that returns a list of DID methods that the DID Resolver knows how to resolve. @peacekeeper <https://github.com/peacekeeper> For this to happen, does some sort of syntax specification need to allow for it? If so, which one? Where/how do we specify support for did:?ping and/or did:?methods queries (or anything similar)? ...where in/which ABNF syntax specification do we allow for these types of constructs?

The typical pattern here—at least the one I have experienced—is one of specialization. This is the sequence: 1. RFC 3986 specifies the generic ABNF syntax for all URIs. Think of this as the top-level class. 2. A URI scheme specification (e.g., HTTP, FTP, mailto, DID) specifies the specific ABNF syntax for a URI scheme. It is a specialization of the top-level class for a specific protocol. It's ABNF must be a valid subset of the RFC 3986 ABNF. 3. A subprotocol specification (e.g., OASIS XRD) further specializes a scheme specification (in the case of XRD, it was to specify the protocol parameters that could be passed in a URL query component). It's ABNF must be a valid subset of the URI scheme ABNF. So the DID spec is an example of #2, a URI scheme specification, and the DID Resolution spec—if it ends out needing to define its own ABNF—is an example of #3, a subprotocol specification. What is important about #2—the DID URI scheme specification—is that it must specify what generally applies across all DID methods and all resolution requirements. Then #3—the DID Resolution subprotocol specification—only has to specify the specializations that apply to resolution.

[peacekeeper]

@mwherman2000 the way I think about it is that DID Resolvers will support one or more abstract operations, e.g.:

resolve(did) --> did-doc

resolve(did) --> did-resolution-result

resolve(did, timestamp) --> did-resolution-result

dereference(did-url) --> did-doc or something else

checkExists(did) --> boolean

ping() --> boolean

listMethods() --> array-of-methods

There can then be multiple "bindings" for those DID Resolution operations, i.e. they can be invoked locally via an API, or via a command line tool, or remotely via an HTTP REST interface.

It's unclear at this point 1. what the list of operations will be exactly, and 2. which ones need to be standardized in a spec vs. left open to implementers.

But what's clear at least to me is that you only need an ABNF for the "did" or "did-url" or "did-reference" inputs above; you don't need an ABNF to define the resolve(), ping(), listMethods() or whatever other operations themselves.

[talltree]

Beautiful, Markus.

…

On Wed, Feb 20, 2019 at 9:56 PM Markus Sabadello ***@***.***> wrote: @mwherman2000 <https://github.com/mwherman2000> the way I think about it is that DID Resolvers will support one or more abstract operations, e.g.: resolve(did) --> did-doc resolve(did) --> did-resolution-result resolve(did, timestamp) --> did-resolution-result dereference(did-url) --> did-doc or something else checkExists(did) --> boolean ping() --> boolean listMethods() --> array-of-methods There can then be multiple "bindings" for those DID Resolution operations, i.e. they can be invoked locally via an API, or via a command line tool, or remotely via an HTTP REST interface. It's unclear at this point 1. what the list of operations will be exactly, and 2. which ones need to be standardized in a spec vs. left open to implementers. But what's clear at least to me is that you only need an ABNF for the "did" or "did-url" or "did-reference" inputs above; you don't need an ABNF to define the resolve(), ping(), listMethods() or whatever other operations themselves. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLkTYYmlmbtNRIsKe1V54Y6bQYs1bX3ks5vPjUigaJpZM4ayr-I> .

[mwherman2000]

But what's clear at least to me is that you only need an ABNF for the "did" or "did-url" or "did-reference" inputs above; you don't need an ABNF to define the resolve(), ping(), listMethods() or whatever other operations themselves.

1. Where should we define the HTTP/URL bindings for these operations? ...which document?
2. What's the best way for specify the syntax for these bindings? ...ABNF?

[mwherman2000]

Closed in favor of #32 Use case 6