Open ekr opened 2 years ago
Hey @ekr, apologies for the delay in response. The DID WG stopped regularly processing issues for DID Core when DID Core went to Proposed Recommendation. I'm just now seeing your question. I'll note during the next call that a few issues have been raised after we went to PR and see what our policy is on responding to these issues during a FO process.
The purpose of controller
is to ensure that the key material is bi-directionally associated with an entity. That is, the key description has to say "This is my controller (provides a URL)", and then when you retrieve that URL, it (the controller document) has to express "These are the keys that I have approved for the purposes of X" (e.g., authentication, issuing, capability delegation, capability invocation, etc.). An implementation doing authentication would expect to see the key listed in the list of keys approved for authentication in the controller document.
The simplest case is a DID Document, where you expect the entity identified by a DID to express its authentication keys in the same document.
There are more complex cases where a system might only store the public key information (but not the entire DID Document)... or where the key might be expressed in many different places across the Web (where each expression points back to the same "controller document" -- aka DID Document).
Regardless, in both of these cases, you have to resolve the key description of it's controller in the "key document" against what's expressed in the "controller document" and ensure that the controller document lists the key in its list of authentication keys.
Presumably, if Alice can prove that it can sign with the private counterpart of key zH3C..PV then Bob should accept that this is Alice (or, I suppose did:example:123456789abcdefghi).
Undefined at present because the charter (and DID WG members) did not want us to work on or discuss protocol.
I can give you an answer that has some implementation experience and is where I expect the group to go.
In the case you describe above, Bob looks at the authentication message, that might look like this (Verifiable Credential Presentation for a DID-based authentication):
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
],
"type": "VerifiablePresentation",
"holder": "did:example:123456789abcdefghi",
"proof": {
"type": "Ed25519Signature2020",
"created": "2021-11-21T17:38:50Z",
"domain": "login.example",
"challenge": "zCa4mJuYXSyZH3FFiC",
"verificationMethod": "did:example:abcdef#keys-a",
"proofPurpose": "authentication",
"proofValue": "z2yPdKTT5W57WMGUvu5WKLcgAGQJywpkSz8EnGDaRugLU4rM9ATjggCa4mJuYXSyZH3FFiCez1aufhSjog4wzM1Fo"
}
}
and sees a proofPurpose
of authentication
, and a verificationMethod
of did:example:abcdef#keys-a
. Bob's software then dereferences did:example:abcdef#keys-a
and checks to see if that controller document lists did:example:abcdef#keys-a
as a key that can be used for authentication
. If all of that holds, then the proof is valid -- the bi-directional binding of the key has been established (assuming the digital signature bytes are also valid).
However, the question then turns to the holder: Is a holder allowed to use a key that is controlled by another entity to authenticate? There are valid use cases that matter here, such as legal guardianship, power of attorney, etc. In those cases, the signer is doing something on behalf of another entity, and so it's very important to not get the two entities confused (variation of confused deputy attack).
So, for those use cases, you'd need an extra step (when the holder is not the same one that signed). You look up the holder document, check which keys they list in their authentication
field, and if did:example:abcdef#keys-a
is listed, then you know the holder has allowed this other entity to authenticate on their behalf (without confusing one entity with the other).
What happens after that authentication is done, however, is use case specific. Some use cases might not allow "delegated authentication" while others might.
Does that answer your question of: "What is Bob to make of that?" -- You seem to be describing a delegated authentication use case.
S 5.2. says
It's not clear to me how to interpret this text here. Suppose that Alice wishes to authenticate to Bob with a DID that resolves to the following document:
Presumably, if Alice can prove that it can sign with the private counterpart of key
zH3C..PV
then Bob should accept that this is Alice (or, I supposedid:example:123456789abcdefghi
).However, what if instead Bob looks up the controller value (
did:example:abcdef
) and that resolves to a new document with its own authentication block and key YYYY and the counterparty signs with YYYY. What is Bob to make of that?