- From: Adrian Gropper <agropper@healthurl.com>
- Date: Mon, 11 Dec 2017 16:37:53 +0000
- To: "David E. Ammouial" <da@weeno.net>
- Cc: public-credentials@w3.org
- Message-ID: <CANYRo8hNFvruU0TkS=Ye8A+FQY0nVTm3sn36wx5U5NkMbLf-fw@mail.gmail.com>
>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/
Received on Monday, 11 December 2017 16:38:29 UTC