Re: Proposed work item: did:key DID Method

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.

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>