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