Re: DID Key Management Harmonization Proposal #1

I would have liked to have posted this earlier to give more time for
discussion in advance of today's DID Spec Closure Meeting that begins in 5
minutes (see the logistics message from Susan Bradford), but here is a link
to a Google doc for DID Harmonization Proposal #2
<https://docs.google.com/document/d/1z8o2VPjvXIw6-KrxGTdSPfOshDlBGmj0MhH3QJXS0eg/edit?usp=sharing>
.

For those who want to avoid Google docs, here's a copy of what's in this
doc at the moment:

DID Spec Harmonization Proposal #2

For discussion in the W3C Credentials Community Group

First Draft—2018-01-11
Background

This proposal builds on the DID Key Management Harmonization Proposal #1
sent by Manu Sporny to the W3C Credentials Community Group mailing list on
2018-01-05 (Manu, could you insert a link here—I don’t know how to find the
ULR for a W3C mailing list email).

This proposal adds some suggestions and constraints. It is presented in the
spirit of helping isolate the remaining open issues so we can drive them to
closure and produce the next stable version of the spec as quickly as
possible.
Requirements

This list is from proposal #1 and is included here for easy reference and
also to enable comments or discussion of these requirements.

R1. All data structures can be treated as plain 'ol JSON.

R2. All data structures can be extended via JSON-LD.

R3. All data structures are compatible with both a tree-based model AND a
graph-based model (no philosophical nor technical conflicts).

R4. There is a simple algorithm for locating public keys owned by an entity
represented by the DID.

R5. Authentication and encryption use cases are supported.

R6. Design allowances are made for authentication via biometrics, smart
contract, and oracles.

R7. Ambient authority is protected against to a certain extent.

R8. Non-correlation use cases are supported.

R9. There is a very clear extensibility story both for JSON and JSON-LD.

R10. It is clear where non-owned public keys go.

R11. Multiple encoding types for public keys are supported with a clear
extensibility story for other types of cryptographic primitives.
A) Tree-Orientation and Graph-Orientation

Per R3 above, Manu’s proposal highlights that the two “worldviews” we have
been discussion largely come down to whether one is coming from a
tree-oriented or a graph-oriented perspective to processing a DID document.
So this first proposal is for the spec to acknowledge up front that DID
documents need to serve both purposes and it is an explicit design pattern
for the spec to support both modes of processing and extensibility.

Note that this does not preclude using graph-model processing or full
RDF-based semantic graph descriptions as Manu’s proposal describes. It
simply
DISCUSSION
B) Core “Tree” Properties

Secondly, from the tree-orientation, the proposal is for the spec to define
three core properties:

{

 "id": "did:example:123456789abcdefg",

 "publicKey": [ ... array of public key description objects ... ],

 "service": [ ... array of service description objects ... ]

}

The proposal is that tree-oriented processing is designed so developer can,
if they wish, only use these three core properties.
DISCUSSION
C) Type Properties

To support (B), the type property of both public key description objects
and service description objects needs to be able to carry sufficient
metadata for a developer to be able to select: a) the public keys they need
and/or b) the services they need.

NOTE: DO NOT READ TOO MUCH INTO THE VALUES OF THE PROPERTIES IN THE EXAMPLE
BELOW—this is just illustrative of proposed DID property structure.

{

 "id": "did:example:123456789abcdefg",

 "publicKey": [{

   "id": "#key1",

   "type": "RsaSigningKey2017",

   "owner": "did:example:123456789abcdefg",

   "publicKeyPem": "-----BEGIN KEY...END KEY-----\r\n",

   "publicKeyJwk": {...}

 }],

 "service": [{

   "id": "#svc1",

   "type": "RsaKeyBasedAuthentication2017",

   "publicKey": "#key1"

 },

 {

   "id": "#svc2",

   "type": "did-auth-push-mode-v1",

   "publicKey": "#key1"

   "endpoint": "http://auth.example.com/did:example:123456789abcdefg",

 }],

 ...

}
DISCUSSION
D) Public Key Reference Property

The proposal is that the native DID JSON-LD context define publicKey as
containing either an absolute URL or a fragment that references a public
key description object so that a service description object (or any other
RDF extension) can make unambiguous references to public key description
objects in the same DID document or another DID document.
DISCUSSION
E) Public Key Owner Property

The proposal is that *the owner property of a publicKey object is: a)
optional, and b) if it is missing, it can be assumed to be the DID subject.*
DISCUSSION