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

There's an open PR with a long thread about exactly this topic:
"Allow DID methods without Update and Delete"
https://github.com/w3c-ccg/did-spec/pull/55

uPort implementation:
https://github.com/uport-project/secp256k1-did-resolver

My opinion is that keys-as-identifiers that cannot be rotated could be 
useful in some situations, but maybe then they shouldn't be called "DIDs".

Markus

On 06/07/2018 02:59 AM, Manu Sporny wrote:
> On 06/06/2018 11:30 AM, Chris Boscolo wrote:
>> We should define a DID method name called *"local"*or *"self"*where 
>> the /specific-idstring/ is a secp256k1 public key.
>
> This method would be:
>
> 1) susceptible to stolen key attacks and wouldn't allow key rotation,
>    and
> 2) favor a very specific type of public key, which is a bad
>    security design practice.
>
> We've explored this a bit in the past. You can address these
> shortcomings by just making this mechanism a part of the DID method. You
> can have public-keys-as-DIDs, but you also MUST enable the DID Document
> to be updated to deal w/ stolen key attacks.
>
>> This way, individuals can useDIDsthat are TRULY self-sovereign, 
>> albeit limited, to just the public key lookup without any way to 
>> update it.
>
> Again, this is very dangerous and I suggest that no one expose their
> constituency to this sort of attack.
>
>> 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.
>
> Veres One and Sovrin have this feature as well... start off-chain and
> enable a migration to on-chain (in the event that you want to prevent
> the stolen key attack).
>
> I suggest we leave this as a DID Method feature.
>
> -- manu

Received on Thursday, 7 June 2018 06:46:33 UTC