Simplify spec by moving to capabilities, proofs, and authn and authz #22
Conversation
msporny
requested review from
ChristopherA,
dlongley,
jandrieu,
talltree and
kimdhamilton
|
@msporny Do you have a URL so we can look at your branch directly? |
|
@ChristopherA Yes, here it is: https://msporny.github.io/did-spec/ I also added it to the PR description just now. |
index.html
Outdated
| set of service endpoints, which are resource pointers necessary to | ||
| initiate trusted interactions with the identity owner. Each DID uses a | ||
| specific DID method, defined in a separate DID method specification, to | ||
| resolve to DID Objects — simple JSON documents that |
There was a problem hiding this comment.
I'm a +1 to changing DID Objects to DID Descriptions.
index.html
Outdated
| initiate trusted interactions with the identity owner. Each DID uses a | ||
| specific DID method, defined in a separate DID method specification, to | ||
| resolve to DID Objects — simple JSON documents that | ||
| contain all the metadata needed to interact with the DID. |
There was a problem hiding this comment.
"Interact with the DID" ... how does one "interact" with the DID? Perhaps this should be "with the entity that the DID identifies."
We often talk about "authenticating as a DID" or "interacting with the DID" as shorthand for "the entity the DID identifies". I know this is verbose, but we shouldn't let the shorthand we use to discuss DIDs leak into this spec because it's inaccurate and confusing to those outside the community that discusses this on a regular basis.
index.html
Outdated
| resolve to DID Objects — simple JSON documents that | ||
| contain all the metadata needed to interact with the DID. | ||
| Specifically, a DID Object contains at least three things. The first is | ||
| a set of mechanisms that may be used to authenticate as |
There was a problem hiding this comment.
I think we should be careful here to indicate that the DID Description specifies the set of acceptable mechanisms or the verification material (not the mechanisms themselves or the authentication secrets). Also, again, one does not authenticate as a particular DID, they authenticate as the entity the DID identifies. So suggested language:
"The first is the set of acceptable forms of proof that may used to authenticate as the entity identified by a DID."
I'd be happy to see something more concise than that, but that's my best stab at the moment.
index.html
Outdated
| Specifically, a DID Object contains at least three things. The first is | ||
| a set of mechanisms that may be used to authenticate as | ||
| as a particular DID (e.g. public keys, pseudonymous biometric templates, etc.). | ||
| The second is a set of authorization information that outlines which entities |
There was a problem hiding this comment.
"outlines" => "specifies".
There was a problem hiding this comment.
Also, I think it is a bit imprecise to say that one "authenticates as a particular DID". One does not assert "I am this DID"--as the current language suggests. Rather, we use a DDO to authenticate as an entity authorized to claim the DID. Or something like that. We are not our DIDs. DIDs are merely tools we use to authenticate as appropriate agents in certain circumstances.
There was a problem hiding this comment.
@jandrieu -- I agree. I mentioned the same thing in a couple of comments above. It's seeped into our language when talking about this stuff as shorthand, but it shouldn't be in the spec (and it's arguable that we should even be talking that way about it at all).
index.html
Outdated
| as a particular DID (e.g. public keys, pseudonymous biometric templates, etc.). | ||
| The second is a set of authorization information that outlines which entities | ||
| may modify the DID Object. The third is a set of service endpoints, which may | ||
| be used to initiate trusted interactions with the identity owner. Each DID |
There was a problem hiding this comment.
"with the identity owner" => "with the entity identified by the DID".
index.html
Outdated
| @@ -174,12 +174,9 @@ | |||
| Each identity owner can be identified on a ledger with a <a href= | |||
There was a problem hiding this comment.
"Each identity owner can be identified on a ledger" => "Each entity may authenticate with a"
The entities are identified by DIDs. They may authenticate via keys (or other mechanisms).
There was a problem hiding this comment.
We should square this language with the more general use of "proofs" perhaps by saying "the simplest authentication mechanism is through the use of a public/private key pair".
index.html
Outdated
| </td> | ||
| <td colspan="1" rowspan="1"> | ||
| <p> | ||
| DID architecture should enable identity owners to control the |
There was a problem hiding this comment.
"identity owners" => "entities"?
index.html
Outdated
| </td> | ||
| <td colspan="1" rowspan="1"> | ||
| <p> | ||
| DID architecture should provide sufficient security for relying |
There was a problem hiding this comment.
The architecture should "provide" this security or "enable" it?
index.html
Outdated
| <p> | ||
| DID architecture should enable an identity owner to provide | ||
| cryptographic proof of ownership and proof of access control | ||
| rights. |
There was a problem hiding this comment.
Uses old language of "proof of ownership" and "proof of access control". Possibly change to:
"DID architecture should enable an entity to authenticate and obtain authorization to modify DID Descriptions."
Though, are there other capabilities beyond modifying the DID Descriptions -- how do we incorporate that language here?
index.html
Outdated
| example assumes that the identity owner—the entity that controls the | ||
| private keys for this identity—is authoritative for the DDO. See section | ||
| 2.2 for an example of a DDO created by a guardian. For the authoritative | ||
| private keys for this identity—is authoritative for the DID Description. See section |
index.html
Outdated
|
|
||
| <p> | ||
| Following is an example of a DDO that describes the DID above. This | ||
| Following is an example of a DID Description that describes the DID above. This | ||
| example assumes that the identity owner—the entity that controls the |
There was a problem hiding this comment.
Old language here that should probably be removed ("identity owner" and "controls") and just talk about entities, authentication, and authorization.
There was a problem hiding this comment.
I'll start with the top level:
The emergence of distributed ledger technology (DLT), sometimes referred to as blockchain technology, provides the opportunity to implement fully decentralized identity management. In this ecosystem, all participants with identities (called identity owners) share a common root of trust in the form of a globally distributed ledger (or a decentralized P2P network that provides similar capabilities).
This sentence captures a broad disconnect I believe we can easily fix.
DIDs do not provide decentralized identity management. They provide decentralized identifier management.
There's a huge difference.
We're generally on the same page about the opportunity for decentralized identity, but DIDs are just the first step and I think we would do better to be strict in our claims.
DIDs do not address attribute management (classic ISO definition of identity), nor do they address attribute derivation, analysis, use, and protection (from the functional definition of identity).
I started adding a bunch of +1 to @dlongley's comments for replacing "identity owner" with "entity" and realized a simpler, but more sweeping change to focus on DIDs as providing a means to prove control of "identifiers" rather than "identities" would greatly improve the entire spec.
I agree, but expect this change to be controversial. We should probably discuss in another PR. We may want to raise an issue for this... could you please do that, Joe? |
index.html
Outdated
| DID record. A DDO may also contain other <a href= | ||
| DID Description. A JSON data structure containing metadata | ||
| describing a DID, including mechanisms, such as public keys and | ||
| pseudonymous biometrics, that an entity can use to authenticate itself as the |
There was a problem hiding this comment.
Biometrics on the ledger seems fairly risky. You can't rotate a biometric if leaked. Crypto algorithms have yet to have as long a life as humans so protecting them with crypto does not have a great track record over a long period of time (a person's life).
There was a problem hiding this comment.
+1 on this approach and change. Only a few minor comments added here.
I think this PR addresses the goals we had here -- moving to capabilities, proofs, etc. IMO related concerns raised in the CG could be addressed in subsequent PRs; ie:
- new name of DDO
- readability pass
| once and never changed (forever). Ideally a DID would be a completely | ||
| abstract decentralized identifier (like a UUID) that could be bound to | ||
| multiple underlying distributed ledgers or networks over time, thus | ||
| maintaining its persistence independent of any particular ledger or | ||
| network. However registering the same identifier on multiple ledgers or | ||
| networks introduces extremely hard identity ownership and <a href= | ||
| networks introduces extremely hard entityship and <a href= |
There was a problem hiding this comment.
is this a find/replace term? replace with "entity ownership"?
index.html
Outdated
| private keys for this identity—is authoritative for the DDO. See section | ||
| 2.2 for an example of a DDO created by a guardian. For the authoritative | ||
| Following is an example of a DID Description that describes the DID above. This | ||
| example assumes that the entity—the entity that controls the |
There was a problem hiding this comment.
minor: "entity—the entity" -> "entity"
index.html
Outdated
| @@ -2414,12 +2337,12 @@ | |||
| <p> | |||
|
|
|||
|
|
|||
| Including an equivalence property, such as equivID, in DDOs whose value is an array of DIDs would allow identity owners to assert two or more DIDs that represent the same identity owner. This capability has numerous uses, including supporting migration between ledgers and providing forward compatibility of existing DIDs to future DLTs. In theory, equivalent DIDs should have the same identity rights, allowing | |||
| Including an equivalence property, such as equivID, in DID Descriptions whose value is an array of DIDs would allow entitys to assert two or more DIDs that represent the same entity. This capability has numerous uses, including supporting migration between ledgers and providing forward compatibility of existing DIDs to future DLTs. In theory, equivalent DIDs should have the same identity rights, allowing | |||
There was a problem hiding this comment.
minor: "entitys" -> "entities"
index.html
Outdated
|
|
||
|
|
||
| The authors of this specification have applied all seven Privacy by Design principles throughout its development. For example, privacy in this specification is preventative not remedial, and privacy is an embedded default. Furthermore, decentralized identity architecture by itself embodies principle #7, "Respect for user privacy—keep it user-centric." | ||
|
|
||
|
|
||
| This section lists additional privacy considerations that implementers, guardians, and identity owners should bear in mind. | ||
| This section lists additional privacy considerations that implementers, guardians, and entitys should bear in mind. |
There was a problem hiding this comment.
minor: "entitys" -> "entities"
index.html
Outdated
| identity). A corresponding public key is published in the DDO using a | ||
| key description. A DDO may also contain a set of service endpoints for | ||
| interacting with the identity owner. Following the dictums of <a href= | ||
| decentralized identity management. In this ecosystem, all entities |
There was a problem hiding this comment.
probably a nit, but to me this implies a single ledger: "all entities share a common root of trust in the form of a globally distributed ledger". Maybe replace with "...globally distributed ledgers or decentralized P2P networks..." -- omitting parens around the P2P network part.
|
When we approve these changes in the CG, can we change the spec version to 1.01 or 1.1? |
No, we can't... a 1.0 release is a W3C REC (if all goes well, that happens in two years time). We could do semantic versioning and back out the version number to 0.x.x, though. We should discuss on the call today. I'll back out the version to 0.7. |
| "LinkedDataSignature2015": "sec:LinkedDataSignature2015", | ||
| "LinkedDataSignature2016": "sec:LinkedDataSignature2016", | ||
| "RsaCryptographicKey": "sec:RsaCryptographicKey", | ||
| "RsaSignature2015": "sec:RsaSignature2015", |
There was a problem hiding this comment.
RSASignature2017 is referenced in index.html section 6.5.1 and doesn't appear in this context.
There was a problem hiding this comment.
Yes, we're still finishing up implementations on that spec. We may want to back it out to RsaSignature2015, which does exist.
There was a problem hiding this comment.
I just ended up adding RsaSignature2017 since we know we're implementing it.
|
Comments from CCG call: |
* Authentication and Authorization (vs. Ownership and Control) * Proofs (vs. just Keys and Signatures) * Decomposing Service Discovery * Capabilities-based Security Model
Remove whitespace around "," and "." causing odd output formatting.
Attempt to simplify the spec by moving to:
You can view the rendered changes here:
https://msporny.github.io/did-spec/