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

Markus,
Thank you for posting these links!

Regarding this thread: https://github.com/w3c-ccg/did-spec/pull/55, was
there a conclusion reached after the F2F discussions happened at IIW?  I
don't see any other comments in that thread.

I think having something like uPort's secp256k1-did-resolver be mandated by
all DID resolvers would greatly benefit interop testing.  (In much the same
way TCP/IP stacks have a loopback address to test network software on a
single host.)

   -chrisb

On Wed, Jun 6, 2018 at 11:45 PM, Markus Sabadello <markus@danubetech.com>
wrote:

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