Re: Outcome of 2023 Miami Verifiable Credentials WG Meeting

Thanks George for that perspective, I have some questions below...

On Mon, Feb 20, 2023 at 4:47 PM George Lund <
george.lund@digital.cabinet-office.gov.uk> wrote:

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

This makes sense.


>
>

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

If you use a federated identity model, then there is no need to necessarily
have the authentication (confirmation method) baked in. I agree. I believe
in your case you trust the GOV.UK One Login provider to authenticate the
user before the VCs (not a VP) are sent to the relying party. If you change
to a model where you have the authentication at the presentation level,
then the issuer will need to associate the confirmation method in the VC.
For example, the verifier could then verify the signature of the VP (e.g.
data integrity proof) to verify the confirmation method that was declared
in the VC by the issuer.


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