Re: Outcome of 2023 Miami Verifiable Credentials WG Meeting

Thanks George, that makes sense. I also agree that evidence should not
contain all the info from a passport in case a passport was checked to make
certain claims. +1 for aggregating that information as much as possible.

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

> Yes, I think you're right. We don't have any current plans to represent
> authentication level in the presentation layer, because our model relies
> for authentication on a single OpenID Connect provider. This is a
> complication we definitely don't need right now!
>
> In fact, even for identity confidence, our presentation layer summarizes
> the evidence into a Vector of Trust for identity confidence, because for
> data protection reasons, the detail of exactly how an identity was proven
> (in the original verifiable credentials) is simply too much information to
> share.
>
> (The technical way we're doing that is to encode a "vot" claim into our VC
> JWTs; if we were not using JWTs, then I'd imagine having that as a property
> under "evidence" - this mapping isn't supported by any specification I know
> of except our own, but feels a practical response to the constraints we're
> operating with.)
>
> George
>
>
> On Mon, 20 Feb 2023 at 15:56, Oliver Terbu <oliver.terbu@spruceid.com>
> wrote:
>
>> 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
>>>
>>>
>>>
>
> --
> George Lund
> Technical Architect
> GOV.UK One Login
> Government Digital Service
>
>
>