What are the semantics of "controller" in "authentication"

[ekr]

S 5.2. says

The semantics of the controller property are the same when the subject
of the relationship is the DID document as when the subject of the
relationship is a verification method, such as a cryptographic public
key. Since a key can't control itself, and the key controller cannot
be inferred from the DID document, it is necessary to explicitly
express the identity of the controller of the key. The difference is
that the value of controller for a verification method is not
necessarily a DID controller. DID controllers are expressed using the
controller property at the highest level of the DID document (the
topmost map in the data model); see § 5.1.2 DID Controller.

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:

  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:abcdef",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

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).

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?

[msporny]

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.