Re: Outcome of 2023 Miami Verifiable Credentials WG Meeting

For even more nuance (and I don't yet have much reference material to send
you on this, but I hope to at some point), folks might be interested in the
GOV.UK One Login perspective.

For GOV.UK One Login, we interpret "evidence" as being evidence of the
checks that contributes to identity confidence per our Good Practice Guide
45 (corresponding to IAL). But this *includes* recording the verification
process, which might have been biometric, that tied the identity to the
person in the chair when it was originally confirmed.

Authentication - corresponding to AAL, but in our world defined by Good
Practice Guide 44 - is never (at present) baked into a verifiable
credential. It might one day be expressed at the presentation level, but
right now we're solely using Vectors of Trust
<https://www.rfc-editor.org/rfc/rfc8485.html>, as that maps well with our
authentication systems, which use OpenID Connect.

George





On Mon, 20 Feb 2023 at 13:34, Oliver Terbu <oliver.terbu@spruceid.com>
wrote:

> I forgot to mention that AAL is about the presenter and to protect against
> identity theft, fraud, forgery, cloning, replay attacks and so on etc.
> whereas IAL is about the identification process and the trustworthiness of
> the claims.
>
> On Mon, Feb 20, 2023 at 2:30 PM Oliver Terbu <oliver.terbu@spruceid.com>
> wrote:
>
>> 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
>>
>

-- 
George Lund
Technical Architect
GOV.UK One Login
Government Digital Service