Re: Some questions regarding DID verification relationships

This email has now been stored as documentation in our SSI library! :D

On Thu, Dec 2, 2021 at 8:08 PM Phillip D. Long <phil@rhzconsulting.com>
wrote:

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

-- 

*Snorre Lothar von Gohren Edwin*
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io
<http://www.diwala.io/>
*Stay on top of Diwala news on social media! **Facebook
<https://www.facebook.com/diwalaorg>** / **LinkedIn
<https://www.linkedin.com/company/diwala>** / **Instagram
<https://www.instagram.com/diwala_/>** / **Twitter
<https://twitter.com/Diwala>*