Re: A local built-in DID method name for public key lookup

On 06/06/2018 11:30 AM, Chris Boscolo wrote:
> The "What is a DID? Was: Call for Focal DID Use Cases" taking place on 
> this list evoked an idea.
> 
> We should define a DID method name called *"local"*or *"self"*where the 
> /specific-idstring/ is a secp256k1 public key.
> 
> Then require all DID libraries to have a built-in handler for this 
> method's read operation.  That would turn a DID like this:
> 
>     *did:self:12345678*
> 
> 
> To a DID Document like this:
> 
>     *{*
>     *  "@context": ["https://w3id.org/did/v1",
>     "https://w3id.org/security/v1"],*
>     *  "id": "did:self:12345678",*
>     *  "publicKey": [{*
>     *    "id": "did:self:12345678#keys-1",*
>     *    "type": "Secp256k1VerificationKey2018",*
>     *    "owner": "did:self:12345678",*
>     *    "publicKeyHex": "0102030405060708"*
>     *  }]*
>     *}*
> 
> 
> This way, individuals can useDIDsthat are TRULY self-sovereign, albeit 
> limited, to just the public key lookup without any way to update it.
> It would also simply testing of SSI implementations in much the same way 
> "127.0.0.1" "localhost", simplifies IP network testing.
> 
> I know that several DID implementors (uPort/lifeID) are already 
> supporting a way to have DIDs start their life off-chain which was a 
> seed thought for this idea.

The Veres One DID method also supports having DIDs start their life
off-chain. I don't know that we need a separate DID method forcing them
to remain off-chain. Even if we did, I don't think we'd want to limit it
to secp256k1, so some other multihash sort of encoding would be more
appropriate. But at that point, it wouldn't be different from a Veres
One DID except in that it can never be sent to the Veres One ledger.

It seems like a content-addressable hash (of the entire DID document)
would be a better choice for a DID of that sort if it even makes sense
to do it. There are a lot of pitfalls to that approach.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Wednesday, 6 June 2018 17:57:10 UTC