Re: Proposed work item: did:key DID Method

On Sun, 24 Nov 2019 at 20:03, Orie Steele <orie@transmute.industries> wrote:

> Yes, those proof purpose methods are problematic because of lack of
> documentation... There is some related discussion here:
>
> https://github.com/w3c/did-core/issues/2
>
> TL;DR; IMO, we need to make sure we are providing human readable
> documentation for every context change we make to did-core JSON-LD context
> moving forward... It's hard to rally people around the use of
> capabilityInvocation, when there is very little to read on the subject.
>
> One of the core challenges we are facing regarding interop is a lack of
> conformance regarding proof purposes, and that's why the issue I linked is
> so critical.
>
> Until we have multiple did methods supporting the same proof purposes, and
> leveraging them in for interoperability, everything interop (even
> authentication) is mostly theoretical.
>
> I recently added support for these proof purposes to github-did (our
> centralized testing method), here is an example leveraging assertionMethod
> <https://github-did.com/verify/eyJAY29udGV4dCI6WyJodHRwczovL3czaWQub3JnL2RpZC92MSIseyJzY2hlbWEiOiJodHRwOi8vc2NoZW1hLm9yZy8iLCJhY3Rpb24iOiJzY2hlbWE6YWN0aW9uIn1dLCJhY3Rpb24iOiJBdXRoZW50aWNhdGVNZSIsInByb29mIjp7InR5cGUiOiJFZDI1NTE5U2lnbmF0dXJlMjAxOCIsImNyZWF0ZWQiOiIyMDE5LTExLTE3VDIyOjQwOjI0WiIsInZlcmlmaWNhdGlvbk1ldGhvZCI6ImRpZDpnaXRodWI6T1IxMyNYSlozc0hDLWlkcWNrSFFDWVFTUUJsTlljQk54aDhGZVBpRF9LZW56WjJvIiwicHJvb2ZQdXJwb3NlIjoiYXNzZXJ0aW9uTWV0aG9kIiwiandzIjoiZXlKaGJHY2lPaUpGWkVSVFFTSXNJbUkyTkNJNlptRnNjMlVzSW1OeWFYUWlPbHNpWWpZMElsMTkuLkphU3VITExEVElqeXpjNlZtLWY5OTZITGxMa2s2ZlNHeFduOFM0TXBLYjFXQzRCSS15b1pTeFNDZmhJQ1pic2RWbmtlY2pNWjJzTnlsZEszNDhQY0FBIn19>...
> note his link will likely break the next time I rotate keys for
> did:github:OR13.
>
> So in summary, did:key, did:v1 and did:github all support these proof
> purposes today, but we really need to document them in order to encourage
> others to add support.
>

Going through various docs I found :

    keyAgreement
        The keyAgreement key is a Curve25519 public key (suitable for
Diffie-Hellman key exchange) that is deterministically derived from the
source Ed25519 key, using ed2curve-js.

I still dont quite understand what these terms mean :

    assertionMethod
    capabilityDelegation
    capabilityInvocation

Ive collected the following links

    DID Method Key : https://digitalbazaar.github.io/did-method-key/
    Linked Data Proofs : <
https://w3c-dvcg.github.io/ld-proofs/#proof-purpose
    LD Cryptosuite registry : <
https://w3c-ccg.github.io/ld-cryptosuite-registry/
    VC data model : <https://www.w3.org/TR/vc-data-model/
    DID core : https://w3c.github.io/did-core/

Is it contained in any of these, or a different document.  Or is it not yet
written up?


>
> OS
>
> ᐧ
>
> On Sun, Nov 24, 2019 at 11:36 AM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On Sun, 24 Nov 2019 at 16:57, Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>>
>>> On 11/24/19 5:54 AM, Melvin Carvalho wrote:
>>> > Not to be pedantic, but is there an actual working example of this
>>> > method?
>>>
>>> Yes:
>>>
>>> https://github.com/digitalbazaar/did-method-key-js
>>>
>>> with a minimal test:
>>>
>>>
>>> https://github.com/digitalbazaar/did-method-key-js/blob/master/tests/driver.spec.js
>>>
>>> Orie (Transmute) has also put together an implementation here:
>>>
>>> https://github.com/transmute-industries/did-key
>>>
>>> with a demo here:
>>>
>>> https://did-key.web.app/
>>>
>>> > The above JSON gives syntax errors (even after removing the "..."
>>> > parts)
>>>
>>> Yes, I was just providing a rough sketch of how we could achieve what
>>> Orie was asking for... it wasn't meant to be a fully baked working
>>> example since it speculates on where the DID WG might land on whether or
>>> not to allow two parallel key expressions for the same key (base58 and
>>> JWK, for example).
>>>
>>> > But controller doesnt seem to be explained anywhere in that
>>> > document.
>>>
>>> Yes, the document is out of date... things are moving quickly in the DID
>>> WG and we're trying to see where things settle before putting something
>>> permanently into the Linked Data Security vocabulary/context. We've
>>> found in the past that when we add stuff that's experimental, and note
>>> that it's experimental, that developers end up relying on it and then we
>>> can't remove the experimental stuff... ever. So, the published
>>> vocabularies and JSON-LD Contexts are usually the *last* thing to get
>>> updated... typically during CR. In the meantime, we publish static
>>> copies of the documents via stuff like:
>>>
>>>
>>> https://github.com/w3c-dvcg/security-vocab/blob/master/contexts/security-v2.jsonld#L39
>>>
>>> which is published here:
>>>
>>> https://www.npmjs.com/package/security-context
>>>
>>> That package can be npm installed and then used with the JSON-LD
>>> document loader mechanism to automatically load the latest security
>>> context, example here:
>>>
>>>
>>> https://github.com/digitalbazaar/bedrock-security-context/blob/master/lib/index.js#L7
>>>
>>> Hope that helps... don't expect all of this stuff to be production ready
>>> yet... we're putting these items into the group early in the process so
>>> that we can work out the kinks together. We've used it internally, we're
>>> pretty sure it works for our use cases, we still need to see if others
>>> in this group can find issues with the proposal and see if they have
>>> other use cases they want the spec to cover. Expect the spec and design
>>> to change over the next couple of months. :)
>>>
>>
>> Thanks.  I now have my own did:key at
>>
>>
>> https://did-key.web.app/api/dids/did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6
>>
>> So the issue I had in general.  Last time we chatted you suggested that
>> did:key was a simple place to get started with did.
>>
>> For that reason, I spent a couple of hours diving in.  As someone with
>> reasonable familiarity with linked data, crypto and did, I thought I'd be
>> able to figure out the spec.
>>
>> But it was more complex that I thought.  I appreciate it's a work in
>> progress, but without those links that you just helped out with, it would
>> have not been easy for a developer to know that from reading the spec.
>>
>> Given that linked data is self describing, the idea to look at the
>> ontology to find out more was the first port of call.  So while I can now
>> locate the context, there's not an easy way to understand what im seeing.
>>
>> assertionMethod
>> capabilityDelegation
>> capabilityInvocation
>> keyAgreement
>>
>> For example these 4 terms are not all together intuitive.  And it's not
>> obvious where to find out more information.  There was little in the spec
>> to explain what's going on.
>>
>> It would be great to have a better understanding of thse 4 terms and to a
>> lesser extent "authentication", tho I suspect that means what I think it
>> means.  The terms inside keyAgreement were also something of a black box
>>
>> Mainly writing this out as feedback for the developer experience.
>>
>>
>>>
>>> -- manu
>>>
>>> --
>>> Manu Sporny (skype: msporny, twitter: manusporny)
>>> Founder/CEO - Digital Bazaar, Inc.
>>> blog: Veres One Decentralized Identifier Blockchain Launches
>>> https://tinyurl.com/veres-one-launches
>>>
>>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>