- From: =Drummond Reed <drummond.reed@evernym.com>
- Date: Tue, 26 Dec 2017 23:16:55 -0800
- To: Credentials Community Group <public-credentials@w3.org>
- Cc: Sam Smith <sam.smith@sovrin.org>
- Message-ID: <CAAjunnaaU4keOT948W_ggVCb2z_spfraq=ORrLaL8MnKwaSXKw@mail.gmail.com>
I leave for a trip to Mexico with my family tomorrow morning (back the evening of Jan 2). Before I left I wanted to start a thread based on the last DID Spec Closure call on Thursday Dec 21. On that call we went over the two proposals that were submitted to answer the question of how DID documents should handle cryptographic key material. You can read both proposals in this Google doc <https://docs.google.com/document/d/13fp7V3v1nBuhxTI55Al8KLG2kyxFthBz-Ush-ZL58KA/edit#> . During the call, Sam Smith and several others suggested that perhaps the two proposals could be merged into an overall approach that everyone can live with. From "glass half full" POV, such a merged proposal would be "the best of both worlds": 1. It would allow developers or applications who prefer "naive JSON" to use the DID document for basic key management with a simple array of keys described by type. 2. It would also enable developers who want to use full JSON-LD and RDF semantics to describe cryptographic key material more richly using RDF relations and then reference the value of the key in the key management array. Of course, from the "glass half empty" POV, such a blend of RDF and non-RDF approaches to data description may not satisfy RDF purists. In any case, since at the end of the call there was strong interest in a harmonized proposal, I'm starting this thread to encourage discussion of it between now and the next DID Spec Closure call (yes, we are continuing these calls into January—*until the spec is closed*). For anyone who wants to participate on the calls but does not yet have it on your calendar, the calls are Thursdays at 10AM PT/1PM ET/6PM UK. Logistics is sent out to the mailing list the day of each call. As you have time over your break, please do respond to this thread and if possible let us know: 1. Are you in favor of pursuing a harmonized proposal along the lines discussed above? 2. If so, what specific features/design would you suggest for the harmonized proposal? Also feel free to start constructing a harmonized proposal in the Google doc (I put a placeholder at the end of it for doing this). I'll be happy to contribute after I return on Jan 2. Happy New Year, =Drummond
Received on Wednesday, 27 December 2017 07:17:28 UTC