Re: Some questions regarding DID verification relationships

Dmitri: very good explanation, decomposing the steps and their context for DID verification. Doing this takes time, and it very much appreciated.

Phil

Phillip Long, Ph.D.
RHz Consulting, LLC.
Inquire-Listen-Design-Prototype-Analyze-Repeat
e:phil@rhzconsulting.com
LinkedIn:http://www.linkedin.com/in/longpd/ 
—
T3 Innovation Network, LER Network Facilitator
e: phil@rhzconsulting.com, 
SNS: Twitter/Telegram @RadHertz
LinkedIn: https://www.linkedin.com/in/longpd



> On Dec 2, 2021, at 1:54 PM, Dmitri Zagidulin <dzagidulin@gmail.com> wrote:
> 
> 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 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7517*section-4.2__;Iw!!IKRxdwAv5BmarQ!M-K2pbJVyprv3Brl5VVG7_MmCPUq2t-uk0l33_2JUf3x3wcjaIRlkWwfqgpCdd4$>
> 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://urldefense.com/v3/__https://www.w3.org/TR/did-core/__;!!IKRxdwAv5BmarQ!M-K2pbJVyprv3Brl5VVG7_MmCPUq2t-uk0l33_2JUf3x3wcjaIRlkWwf7iyJvn4$>, 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://urldefense.com/v3/__https://www.w3.org/TR/did-core/*verification-relationships__;Iw!!IKRxdwAv5BmarQ!M-K2pbJVyprv3Brl5VVG7_MmCPUq2t-uk0l33_2JUf3x3wcjaIRlkWwfMKuEnjs$> 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.
>