RE: Some questions regarding DID verification relationships

Here are my questions phrased a bit differently. In any ‘verificationMethod’ property, there is a property called ‘controller’ (whose value must be a DID). I can imagine two possible meanings for this property:

  1.  The DID identifies an entity that is capable of changing the contents of the verificationMethod object of which it is part (in analogy of the capability of the controller of a DID Document).
  2.  The DID identifies a party that controls the private key material that is associated with the public key material that is specified in the verficationMethod object of which it is a part (I can see how this might be suggested by the previous messages in this thread).

My questions:

  *   Is either of these meanings correct (and if so, which is it)?
  *   In which (preferably authoritative) text could I have read this?

Rieks

From: Joosten, H.J.M. (Rieks)
Sent: vrijdag 3 december 2021 15:54
To: 'dzagidulin@gmail.com' <dzagidulin@gmail.com>; W3C Credentials CG (Public List) <public-credentials@w3.org>
Subject: RE: Some questions regarding DID verification relationships

Hi Dmitri,
Thanks for taking the time to respond. My understading gets better, but it’s still not 100%. So can you verify/falsify the green texts, c.q. answer the ??? that I inserted in your explanation that I quote here?

So, to over-simplify, when a verifier encounters a VC with a proof section, the process is:
1) Use the key id contained in the "verificationMethod" of the VC to obtain the public key, so the signature can be checked. This key id sits in a verificationMethod property that not only includes the public key material, but also the DID of the controller of that verificationMethod property, which may (not) be the same as the controller of the DIDdoc itself.
2) Ensure that key is authorized for that particular use by the controller of the verificationMethod property.
Specifically: look at the "proofPurpose" property in the proof section of the VC, to see what this particular proof is for (authentication, VCs, etc).
Then load the controller document which I guess I already have as I found the key material in step 1, so why do that again??? (derefence the DID in the "controller" property signature???, get back a DID Document), and check that the corresponding verification relationship in fact includes that key id.
So, if a proof has "proofPurpose": "authentication", and key id in verificationMethod: "did:example:123#456", the verifier must dereference the "controller" DID i.e. “did:example:123”, and make sure that key "did:example:123#456" is contained in that DID Document's "authentication" relationship. If it's not present there (but is present, say, in another relationship), the verifier must still throw an error -- that key is a valid signing key, but it's not valid for this particular purpose.

And I still wonder what the ‘controller’ property is used for in the verificationMethod (raised an issue<https://github.com/w3c/did-core/issues/805> for that)

Thanks.
Rieks

From: Dmitri Zagidulin <dzagidulin@gmail.com<mailto:dzagidulin@gmail.com>>
Sent: donderdag 2 december 2021 19:54
To: W3C Credentials CG (Public List) <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: Some questions regarding DID verification relationships

Hi Joosten,
Great questions.

The motivation for verification relationships in the DID spec stems from the general security recommendation of "use separate keys for separate purposes".

You can see this at work in other specifications, such as JWKS (JSON Wek Key Set), specifically in the 'use' (Public Key Use) parameters, from https://datatracker.ietf.org/doc/html/rfc7517#section-4.2

It's commonly used for things like OpenID Connect Issuer public keys, and the idea there is -- when a verifier encounters an ID token signed by an Issuer public key, it's not enough to verify that the signature is correct, and that the public key belongs to the issuer (that is, is included in the issuer's JWKS key set).
The verifier must ALSO make sure that the particular public key matches the 'use' parameter -- in other words, that the issuer has authorized the public key to be used for this purpose (either for encryption, or, separately, for digital signatures). So that if a verifier encounters a valid public key that is intended to be used only for encryption, but is being used for signing a token, it must reject it.

So, DID verification relationships extend that notion, into more finer-grained categories. The mapping is something like:

(JWKS) "enc" (encryption) key use --> (DID Core) "keyAgreement"
(JWKS) "sig" (signature) key use --> (DID Core) ["authentication", "assertionMethod", "capabilityInvocation", "capabilityDelegation"]

As you can see, the DID Core spec sub-divided the digital signature key use into several core use cases.
The "authentication" verification relationship (key use directive) is used solely for authentication (such as DID Auth), but not for credential signing.
"assertionMethod" is used for signing Verifiable Credentials and other assertions.
"capabilityInvocation" and "capabilityDelegation" are used solely for authorization use cases, to provide Proof of Possession (invocation), and to delegate permissions.

In the common OIDC use case, a verifier of a credential (such as an ID Token) uses the "iss" property, plus OIDC Provider Discovery and JWKS specs, to obtain a machine-readable document where the entity that did the signing authorizes their public keys for particular uses.
Similarly, in the VC / DID case, a verifier uses the "controller" property of a proof to obtain a document where the signing entity authorizes their public key for particular uses.
That controller document is in fact the DID Document itself.

So, to over-simplify, when a verifier encounters a VC with a proof section, the process is:
1) Use the key id contained in the "verificationMethod" to obtain the public key, so the signature can be checked.
2) Ensure that key is authorized for that particular use by the controller.
Specifically: look at the "proofPurpose" property, to see what this particular proof is for (authentication, VCs, etc).
Then load the controller document (derefence the DID in the "controller" property, get back a DID Document), and check that the corresponding verification relationship in fact includes that key id.
So, if a proof has "proofPurpose": "authentication", and key id in verificationMethod: "did:example:123#456", the verifier must dereference the "controller" DID, and make sure that key "did:example:123#456" is contained in that DID Document's "authentication" relationship. If it's not present there (but is present, say, in another relationship), the verifier must still throw an error -- that key is a valid signing key, but it's not valid for this particular purpose.

Does that help?




On Thu, Dec 2, 2021 at 10:28 AM Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>> wrote:

I've been reading up a bit on the current DID spec<https://www.w3.org/TR/did-core/>, and I’ve trouble understanding the ideas behind the verification relationships. The spec says that a verification relationship links the DID subject and a verification method (which consists amongst other of a controller property (to be specified as a DID)). Section 5.3<https://www.w3.org/TR/did-core/#verification-relationships> adds to this that verification relationships enable the associated verification methods to be used for different purposes, and its subsections specify properties, such as `authentication`, `assertionMethod` etc., that seem to be associated with a specific purpose, the actual workings of which is only hinted at.



Here are some questions I have:

  *   What’s the purpose of having a ‘controller’ in a verification method?
  *   What’s the role of the controller (how would verification work, given that the controller is represented by a DID that also has key material)?
  *   How does `assertionMethod` work to express claims, e.g. for issuing VCs (is that simply VC signing as an issuer)?
  *   Is there any text that is readable for non-implementers that documents these kinds of verification relationships, and explains how to extend the set of their types?



Rieks

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.