Re: DID Hardening: Keys

On Mon, Dec 11, 2017 at 6:10 PM, Kim Hamilton Duffy <kim@learningmachine.com
> wrote:

> Drummond -- to reconcile your response above with the current key
> description examples (in the DID Hardening V3 doc), I think you are saying
> something like the following...
>
> Currently, the samples in the hardening doc look like:
>
> {
>
> "id": "#key1",
>
> "type": "rsa-2017-pem",
>
> "value": "-----BEGIN KEY...END KEY-----\r\n"
>
> }
>
> But instead of the above, types would *also* encode parameters like
> key_ops, use (using rfc7517 terminology).
>

Yes, exactly right.


>
> Furthermore, to avoid the problems raised about algorithmic agility, the
> key type is a URI describing 1 specific combination (as opposed to
> component-wise specification) of these parameters. E.g. in the example
> above, in addition to specifying RSA and pem, type would also specify a
> use).
>

Yes. In other words, the value of the key type property is a single URI
(or JSON-LD name for that URI) that encapsulates one combination of all
parameters for selecting the key.


> I like the precision of this approach. I personally feel this is the most
> unambiguous for implementors, but others have more experience in this area
> than I.
>
> Of course I anticipate these objections/difficulties:
> 1. Mismatch with the current scope of LD key type
>

I get that, but then I think we need to make a firm decision here: is the
DID spec truly format independent, or not? If it is, and it's designed to
be extremely simple and be able to serve all graph models, ontologies,
serializations, signatures, etc., then it can't be constrained to only type
or key description format.


> 2. Future-proofing concerns Manu has mentioned around encoding being part
> of the type
>

Future proofing? Making encoding part of the type is explicitly a way to
future-proof it—new encodings become new type URIs.


>
> In any case, I'm finally clearer on the different proposals and hope we
> can make more progress next discussion.
>

Me too.

=D

>
> Thanks,
> Kim
>
> On Mon, Dec 11, 2017 at 8:40 AM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> From an individual user’s perspective, such as a physician working with a
>> patient’s health record, it’s important that their DID, whatever the
>> method, be standardized relative to both authentication and signature.
>>
>> In HIE of One, for example, a standardized DID enables the physician to
>> authenticate into any compliant patient record system. But once signed-in,
>> the physician has to also be able to sign and issue a verifiable
>> credential, such as a prescription, to the patient’s system of records.
>>
>> Not all methods will be considered legally adequate for all verifiable
>> credentials. A prescription for a controlled substance might be subject to
>> federal regulation at a level where a regular prescription might not. It’s
>> important that the credentaling of the self-sovereign licensed professional
>> via DID and her verifiable credentials be consistently linked to the
>> verifiable credentials that she issues as a self-sovereign entity.
>>
>> Adrian
>>
>> On Mon, Dec 11, 2017 at 10:53 AM David E. Ammouial <da@weeno.net> wrote:
>>
>>> >   cryptographicPurpose: "Signing"
>>>
>>> What about using the JSON Web Key (JWK, RFC7517) format for the
>>> cryptographic keys? It has a `key_ops` parameter that could bring the
>>> semantic we're looking for and is already standard.
>>>
>>> https://tools.ietf.org/html/rfc7517#section-4.3
>>>
>>> I realise I'm actually making two different points here:
>>> - requiring that the key be specified in RFC7517 format rather than
>>> permitting N different formats -- freedom of choice is great but it also
>>> brings confusion for readers and writers
>>> - specifically, using the `key_ops` parameter for the key's purpose
>>>
>>> --
>>> David
>>>
>>> --
>>
>> Adrian Gropper MD
>>
>> PROTECT YOUR FUTURE - RESTORE Health Privacy!
>> HELP us fight for the right to control personal health data.
>> DONATE: https://patientprivacyrights.org/donate-3/
>>
> --
> Kim Hamilton Duffy
> CTO & Principal Architect Learning Machine
> Co-chair W3C Credentials Community Group
> 400 Main Street Building E19-732, Cambridge, MA 02139
>
> kim@learningmachine.com | kimhd@mit.edu
> 425-652-0150 <(425)%20652-0150> | LearningMachine.com
>