search

w3c-ccg / did-spec

Please see README.md for latest version being developed by W3C DID WG.
https://w3c.github.io/did-core/
Other
124 stars 45 forks source link

authorization section with publicKey #51

Closed mikelodder7 closed 6 years ago

mikelodder7 commented 6 years ago

I'm wondering if publicKey in the authorization section should be renamed to publicKeyURI to make it more clear about what it is. Is there a use case where the actual key would be put there instead of the publicKey section? All of our discussions so far have used it as a DID url for the key either in the same DID document or somewhere else. To keep things clean I would recommend that keys go in the publicKey section and authorization just uses DID urls to refer to them. I'm not happy about publicKeyURI but I believe the name publicKey is not a good descriptor.

msporny commented 6 years ago

I'm wondering if publicKey in the authorization section should be renamed to publicKeyURI to make it more clear about what it is.

In the graph-sense, publicKey is a link to an object that itself has a URI as an identifier. So, both of these things express the same information in Linked Data:

"publicKey": "did:example:1234#key-1"

is semantically the same as:

"publicKey": {
   "id": "did:example:1234#key-1",
   // ... a bunch of other key information like publicKeyPem or publicKeyBase58 ...
}

For that reason, publicKeyURI isn't a good name for this property.

Is there a use case where the actual key would be put there instead of the publicKey section?

Yes, this is the default mode for Veres One because we do not share keys between different application suites. The proposal I made on the mailing list, which is what we used to arrive at consensus, does this. It enables either a reference to be used, or a complete key to be directly embedded, where the semantics of the two are the same and the only difference in implementations is a couple of lines easily written code.

mikelodder7 commented 6 years ago

okay can you put this example somewhere in the spec or I can put it somewhere because that helped to clear up my confusion and some other developers that I reviewed this with. The developers were very confused about that until now.

msporny commented 6 years ago

okay can you put this example somewhere in the spec or I can put it somewhere because that helped to clear up my confusion

Will do. If you don't do a PR, I'll do a PR when I'm doing my next edit cycle. Once the PR is merged, we'll close this issue.

mikelodder7 commented 6 years ago

Sounds good. I'm not sure the best place to put this but I'll be watching for it.

msporny commented 6 years ago

Resolve this issue by submitting a PR that outlines the key searching algorithm when looking for key material associated with a cryptographic suite. Include two examples: 1) embedded key, and 2) referenced key.

talltree commented 6 years ago

I am in favor of this resolution for this issue.

On Thu, Mar 8, 2018 at 2:28 AM, Manu Sporny notifications@github.com wrote:

Resolve this issue by submitting a PR that outlines the key searching algorithm when looking for key material associated with a cryptographic suite. Include two examples: 1) embedded key, and 2) referenced key.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/did-spec/issues/51#issuecomment-371403520, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLkTejrfPgG5KRYLcE1z8hpoIR7rdKTks5tcN2NgaJpZM4SItNz .

msporny commented 6 years ago

PR #79 was submitted to address this issue. Waiting on reviews.