[DID Reference] REQUIREMENT: Ability to query the list of DID Methods found on a particular DID Resolver or Ledger
Closed this issue · 13 comments
Related to but different from #25
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.
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
@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;
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.
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 ]`
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).
@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 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?
@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.
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.
- Where should we define the HTTP/URL bindings for these operations? ...which document?
- What's the best way for specify the syntax for these bindings? ...ABNF?
Closed in favor of #32 Use case 6