Re: DID Spec Closure Process: Cryptographic Key Material Proposals for the DID Specification

On Wed, Dec 20, 2017 at 9:50 AM, Steven Rowat <steven_rowat@sunshine.net>
wrote:

> On 2017-12-20 12:26 AM, =Drummond Reed wrote:
>
>> On Tue, Dec 19, 2017 at 9:54 AM, Steven Rowat <steven_rowat@sunshine.net
>> <mailto:steven_rowat@sunshine.net>> wrote:
>>
>
>     Drummond & all,
>>
>>     TL;DR:  Include Use-cases in comparison?
>>
>>
>> Steven, great point. I added it to the template, and in fact added one
>> example use case for the first proposal listed ("Simple Flat Array of Key
>> Description Objects").
>>
>> I'm hoping others who have proposals can add them tomorrow in advance of
>> our final DID Spec Closure call of the year on Thursday morning (10AM PT;
>> reminder details will be sent to the list).
>>
>
> Thank you.
> But I must apologize for not being clear.
>
> The kind of use-cases I had in mind were END-user cases, in which DID
> would be the primary facilitator of the transaction system.
>
> Examples:
> 1. A doctor managing patient health records or prescriptions.
> 2. A publisher of books managing author payment and copyrights.
> 3. A whistleblower providing sensitive data who needs to be anonymous.
> 4. A consumer purchasing a widget across the internet who wishes only to
> provide limited data about themselves.
>
> I wish to try to understand whether the DID cryptography schemes under
> consideration would limit those use-cases differently.
>

Ahh, thank you, that helps me understand the context of your question
better. I'm happy to say every one of those is a perfect fit for the usage
that I personally see, and that the Sovrin community has discussed, for
DIDs, DKMS (Decentralized Key Management System), and verifiable claims (in
particular verifiable claims exchange that uses privacy-respecting crypto
protocols).


>
> More specifically for my own interest (others may have other focuses),
> Will any of the following be different:
>
> The subject's *data privacy*?
> The subject's access to *pseudo-anonymity*?
> The subject's ability to *accept payment* for digital services?
>

You've hit the nail on the head—those different features start to become
highly dependent not on a DID, but on the protocol and crypto used in the
interactions between the parties using the DIDs. In my experience,
different protocols using different crypto can provide very different
answers to those questions.

>From the standpoint of DID and DID document design, however, the key
requirement simply becomes the ability to provide discoverability and
verifiability of the cryptographic key material and service endpoints
necessary to implement those different protocols. That's the challenge on
the table right now with the DID spec.

Again, speaking only for the Sovrin Foundation, we are designing and
implementing protocols and crypto (specifically Camenisch-Lysyanskaya
signatures) that will provide strong data privacy, including selective
disclosure, strong pseudonymity by default, and which will be integrated
with digital token exchange that is also strongly privacy-respecting.


>
> IMO that is the kind of comparison that will be useful to many of those
> who are going to eventually use the DID system.
>

I agree it will be very useful to have a comparison of the different DID
methods, verifiable claims signature formats, and verifiable claims
exchange protocols with respect to how they support the privacy and payment
features you describe. Thankfully at the DID layer all we need to do is
enable the identification, discovery, and verification that
those verifiable claims formats and protocols need, and then they can
compete in the market based on their feature sets.


> And if there will be no substantial difference in any of them, then I'd be
> happy to know that too. :-)


If the market is any indication so far, there will be very substantial
differences. Some of it will be at the DID and DID method layer; IMHO more
of it will be at the verifiable claims signature and protocol layer.

But each of the options should be a big step forward.

Best,

=Drummond


>
>>
>>
>>     Longer:
>>
>>     I agree that this Google doc seems like a good way to make a
>>     comparison between DID structure choices that may have a long-term
>>     effect. I look forward to seeing the others filled in.
>>
>>     However, in that document shouldn't there be some reference to
>>     use-cases, since, AFAIK, they are potentially impacted by the choice?
>>
>>     Specifically, how would any proposal make it easier or harder for
>>     even a single major use-case (like the refugee migration
>>     documents) to be achieved? Or even better, perhaps three or four
>>     representative use-cases?
>>
>>     Or at very least, put a direct mention in the "Rationale" section
>>     that variable ability to achieve use-cases should be considered
>>     and noted?
>>
>>     IMO it's the one thing everything on the list shares; when this
>>     DID system is up and running, what use-cases will it be able to
>>     perform...or not perform?
>>
>>     Steven
>>
>>
>>
>>
>>