Re: Outcome of 2023 Miami Verifiable Credentials WG Meeting

Hey all,

First of all, thank you Manu for the summary.

Nevertheless, Paul Bastian (Bundesdruckerei, Federal Printing House of
Germany, co-author of RWOT Holder Binding paper and invited to the F2F
session online) and I (led the Holder Binding session and presented the
slides) wanted to give our interpretation of what was agreed during the
session, what holder binding is, what it not is and what are the next
steps.

Please see our comments below...

*From:* Manu Sporny <msporny@digitalbazaar.com>
> *Sent:* Saturday, February 18, 2023 8:57 AM
> *To:* W3C Credentials CG <public-credentials@w3.org>
> *Subject:* Outcome of 2023 Miami Verifiable Credentials WG Meeting
>
> Holder Binding
> --------------------
>
> * There was consensus that "Holder Binding" was the wrong terminology
> and the group does not want to use it going forward. There seemed to
> be consensus forming around the term "assurance" plus another word
> like "identity assurance" or "assurance method"... further
> bikeshedding will be done on this terminology.
>

[Paul/Oliver] While there was consensus that the group does not want to
adopt the term “Holder Binding”, the group was mostly against using the
term “Identity Assurance”. While the term assurance was being discussed the
group felt most comfortable with the term “confirmation method” but this
term is up for bikeshedding once we have a concrete PR that introduces that
feature. The RWOT paper used the term “Identifier Binding” which would be
another option. Also the term “subjectEvidence” was brought up.


>
> * For use cases where the issuer would like to convey the mechanism
> that it used to perform identity proofing, the `evidence` field could
> be used. Expressing statements like: "I checked a passport that had
> these fields and a photo against the individual standing in front of
> me, in person, before I issued this credential" seemed like a bad fit
> for`credentialSubject`, but a good fit for `evidence`.
>


[Paul/Oliver] The “evidence” in our opinion describes how the issuer got
the data or checked the identity of the holder/subject which corresponds
more to the NIST IAL (Identification Assurance Level). However, the
mechanisms how the issuer got/checked the data, might not be available for
the verifier or the issuer offers a simpler mechanism (so verifier doesn’t
have to check all the evidence themselves, e.g., a utility bill). In the
confirmation method the issuer describes one or more mechanisms how a
verifier can confirm/authenticate a subject/holder. This corresponds to
NIST AAL (Authentication Assurance Level). Therefore, the confirmation
method can be independent from issuer evidence. The following are some
examples for evidence and confirmation methods. Note, that both don't have
to be always the same. It might be even fine to have a confirmation method
property without a corresponding evidence and vice versa.

Evidence:

   -

   Utility bill
   -

   Passport
   -

   Internal Government registry
   -

   DID Auth / Public Key


Confirmation method:

   -

   DID Auth / Public Key
   -

   Portrait picture
   -

   Passport reference



By including a confirmation method claim in the `credentialSubject`, the
issuer of the VC declares that the presenter controls a particular
confirmation method and that the verifier can confirm that the presenter
has control of that confirmation method. The issuer binds the claims about
the subject to the confirmation method. The confirmation method can have
different types and each type can refer to different claims and properties
in VCs such as the `evidence`, `credentialSubject.id` (in case of DID
Auth), or something else.

Confirmation Methods are more than just DIDs and Keys. They should offer
mechanisms for different scenarios (on-site vs remote, attended vs
unattended) for the same credential. Moreover they better describe what
people today see as “obvious” and implicit by making the current approach
with DID/credentialSubject.id more explicit and offer additional means to
authenticate the subject/holder.

Example (not normative):

...

"confirmationMethods": [ {

    //refers to credentialSubject.id and can be defined
    //as verify the VP and that the VP is signed with linked DID

    "type": [ "SubjectDidAuthenticationConfirmation2023" ]

}, {

    "type": [ "PassportConfirmation2023" ] ,

    "nationality": "NL",

    "passportNumber": 012345678,

    "contentHash": "3338be69 ... 2398f392"

}, {

    "type": [ "BiometricTemplateConfirmation2023" ] ,

    "portrait": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA8sAAAJl..."

}, {

    "type": [ "BiometricTemplateConfirmation2023" ] ,

    "linkedPortrait": "credentialSubject.userPicture" //refers to existing
claim

}]

…

ConfirmationMethods can also be used with a potential issuee/holder
property if required.



>
> * For use cases where the issuer would like to shift liability or
> constrain what the verifier does, such as "If you don't check the
> individual's passport before you accept this VC, then you accept all
> liability" were identified as problematic to support as we'd need a
> lot of input from legal counsel and there were doubts that the sort of
> liability shifting some were expecting was possible.
>

[Paul/Oliver] The verifier does not need to trust information issued by the
issuer, if they choose to ignore expirationDate, that’s fine and the same
holds true for confirmation methods. So the confirmation method gives
guidance to the verifier, because the issuer knows best how to interpret
the VC data.


> * There will be a concrete pull request offered based on the
> discussions at the F2F.
>

[Paul/Oliver] For the PR, we said, we will add the base properties for the
confirmation methods to VCDM (type, potentially realm) and then we will
define 1-2 concrete types, e.g., DID Auth, Biometric Template. For the use
cases document, we also agreed it makes sense to add language that
describes the importance of strong authentication, e.g., MFA.

Thanks,
Oliver & Paul