Re: DID Hardening: Keys

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

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

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
2. Future-proofing concerns Manu has mentioned around encoding being part
of the type

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

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 | LearningMachine.com