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

Dave,
The primary desired behavior behind my proposal is that you can turn a DID
into a DID Doc using only the DID string and without any additional lookups.
It will make interop testing of VCs much simpler.  Using a
content-addressable hash defeats this.

Your point about not wanting to limit it to secp256k1 is valid. I was
attempting to keep my proposal simple in scope, but a pub key type could
also be encoded in the DID.

For example:

*did:self:Secp256k1VerificationKey2018:12345678*


   -chrisb



On Wed, Jun 6, 2018 at 10:56 AM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> 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
>