[Openid-specs-ab] [External Sender] Re: OIDC for Verifiable Presenations

George Fletcher george.fletcher at capitalone.com
Mon May 16 17:31:13 UTC 2022 

That's very helpful! So for this to work, both the RP and the Wallet(s)
have to implement this complex logic and somehow turn it into something
easy for the user :) I suspect we have a bunch of work to do in this regard
though maybe that isn't specification work and just rather implementation
work to differentiate solutions?

On Mon, May 16, 2022 at 1:27 PM David Chadwick <
d.w.chadwick at verifiablecredentials.info> wrote:

> Hi George
> On 16/05/2022 17:48, George Fletcher wrote:
>
> Thanks Torsten and David. I think you are getting to the crux of my
> question at the end of your response David. The Verifier/RP is willing to
> accept a DoB from a Driver’s license, Passport and a financial institution
> but not the Boy Scouts.
>
> How does the Verifier/RP specify those constraints in the Request?
>
> This gets more complicated because now you have a disjunctive request. So
> the RP will specify 3 alternative filters, one for the DL type, one for the
> Passport type, and one for whatever type banks issue that contain your DoB.
>
> To do this you need to use the group extension of DIF PE, put each filter
> in a different group (A, B and C) and then specify a presentation
> submission saying that only one of these needs to be returned, by using the
> from_nested construct.
>
> Personally I think that the way disjunctive requests are specified in DIF
> PE is not the most elegant way, nor is it in disjunctive normal form, but
> it does allow to, for example, say pick 2 from 5, which is long winded
> using normal forms.
>
> On the plus side, DIF PE does allow the RP to specify any arbitrarily
> complex set of requirements (by an equally complex construct)
>
> Kind regards
>
> David
>
> Or is this a multiple step process where the RP asks for a DoB and then
> gets one it won’t accept and asks again requiring the user to choose a
> different credential with the same claim?
>
> It’s fine if this level of standardization isn’t happening yet.
>
> Thanks,
> George
>
> On Mon, May 16, 2022 at 12:31 PM David Chadwick via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> Hi George
>>
>> I can supplement what Torsten said below by adding that multiple
>> different types of credentials might have the same schema. For example, a
>> credit card schema could be used by Amex, Visa and Mastercard types. So
>> instead of filtering on the credentialSchema property, which could cover
>> several different types of credential, you might prefer to filter on the
>> "type" property, which should be more narrowly scoped to just one type of
>> credential. Note that it is unlikely that driving license and passport
>> types, which both contain the DoB property, will use the same
>> credentialSchema, so filtering on the latter would not work for DoB in this
>> case.
>>
>> Ultimately the RP has to decide what type of credential it is willing to
>> accept. (It might not accept a boys scout credential for providing DoB)
>>
>> Kind regards
>>
>> David
>> On 16/05/2022 16:56, Torsten Lodderstedt via Openid-specs-ab wrote:
>>
>> Hi George,
>>
>> Am 16.05.2022 um 15:54 schrieb George Fletcher via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net>:
>>
>> Hi,
>>
>> What would I use in the current spec as a relying party to inform the
>> wallet that I need an "age over 13“ claim
>>
>>
>> First of all you need to request that contains such a claim. We use
>> Presentation Exchange as language for that, in this case the so-called
>> presentation_definition.
>>
>> It may restrict the desired result by defining a constraint, in this case
>> over the credentialSchema. The following requests an „idcard" credential.
>>
>> "presentation_definition":{
>>            "constraints": {
>>                "fields": [
>>                    {
>>                        "path": [
>>                            "$.credentialSchema.id
>> <https://urldefense.com/v3/__http://credentialSchema.id__;!!FrPt2g6CO4Wadw!OhV8SJR5gsp9_wP7MDmyCYTI7L46MclpSTlQ6gCpa0VBY8WpQ6W33EKO9GLR8CXEsE8Rc--dks5QsRRDyj_n7N12JDSXr1UAQ4apws8$>
>> "
>>                        ],
>>                        "filter": {
>>                            "type": "string",
>>                            "pattern": "https://example.org/idcard
>> <https://urldefense.com/v3/__https://example.org/idcard__;!!FrPt2g6CO4Wadw!OhV8SJR5gsp9_wP7MDmyCYTI7L46MclpSTlQ6gCpa0VBY8WpQ6W33EKO9GLR8CXEsE8Rc--dks5QsRRDyj_n7N12JDSXr1UAp8DP56Y$>
>> "
>>                        }
>>                    }
>>                ]
>>            }
>>         }
>>
>> Note: the concrete paths and patterns depend on the credential format
>> (here JSON-LD/LD Proofs).
>>
>> You may also explicitly request a certain claim by defining a further
>> path, such as
>>
>> {"path":["$.values.is_over_13"]},
>>
>> This would require a „is_over_13“ booelan claim to be present in the
>> credential.
>>
>> Something more generic could perhaps be implemented using PE`s predicate
>> feature. I assume the support of this feature depends on certain credential
>> format & crypto suite capabilities. Here is a (made up) example:
>>
>> {
>>    "path":[
>>       "$.dob"
>>    ],
>>    "filter":{
>>       "type":"number",
>>       "min":1242489139
>>    }
>> }
>>
>>
>> and it can be form one of N issuers that the Verifier/RP trusts?
>>
>>
>> The recommended way is to use a claim in the credential conveying the
>> trust framework/federation the issuer shall belong to. Here is an example:
>>
>> {
>>     "vp_token": {
>>         "presentation_definition": {
>>             "id": "32f54163-7166-48f1",
>>             "input_descriptors": [
>>                 {
>>                     "id": "federationExample",
>>                     "purpose": "To pick a UK university that is a member
>> of the UK academic federation",
>>                     "constraints": {
>>                         "fields": [,
>>                             *{*
>> *                                "path": [*
>> *                                    "$.termsOfUse.federations"*
>> *                                ],*
>> *                                "filter": {*
>> *                                    "type": "string",*
>> *                                    "const": "ukuniversities.ac.uk
>> <https://urldefense.com/v3/__http://ukuniversities.ac.uk__;!!FrPt2g6CO4Wadw!OhV8SJR5gsp9_wP7MDmyCYTI7L46MclpSTlQ6gCpa0VBY8WpQ6W33EKO9GLR8CXEsE8Rc--dks5QsRRDyj_n7N12JDSXr1UAAcUYuKc$>"*
>> *                                }*
>> *                            }*
>>                         ]
>>                     }
>>                 }
>>             ]
>>         }
>>     }
>> }
>>
>> The verifier will need to check that relationship using a registry.
>>
>> There is text about this in the spec at
>> https://openid.bitbucket.io/connect/openid-connect-4-verifiable-presentations-1_0.html#name-support-for-federations-tru
>> <https://urldefense.com/v3/__https://openid.bitbucket.io/connect/openid-connect-4-verifiable-presentations-1_0.html*name-support-for-federations-tru__;Iw!!FrPt2g6CO4Wadw!OhV8SJR5gsp9_wP7MDmyCYTI7L46MclpSTlQ6gCpa0VBY8WpQ6W33EKO9GLR8CXEsE8Rc--dks5QsRRDyj_n7N12JDSXr1UA1GqAZ4U$>
>>
>>
>> I'm losing that context in all the JSON examples :)
>>
>>
>> I hope that helps.
>>
>> best regards,
>> Torsten.
>>
>>
>> Thanks,
>> George
>>
>> --
>> [image: Capital One]
>> George Fletcher (he/him)
>>
>> Executive Distinguished Engineer • Identity Architect
>> [image: address]8020 Towers Crescent Drive, Vienna, VA
>> <https://urldefense.com/v3/__https://www.google.com/maps/search/8020*Towers*Crescent*0D*0A**cDrive,*Vienna,*VA?entry=gmail&source=g__;KyslJSsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr!!FrPt2g6CO4Wadw!I1LiQ9hb4bDIBa3aH7cH0kXKero7Ge3TQLVMETZeJJjLtmMV5bIkLycDEMr8DE0j9j-4NmeRKaZR744QhQIEwT3kiqCWnVyBDMObcuggvW4AdA$>
>> 22128
>> [image: mobile]616-498-8240
>>
>> assistant: [image: email] sharon.anderson at capitalone.com
>> ------------------------------
>>
>>
>> The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The information
>> transmitted herewith is intended only for use by the individual or entity
>> to which it is addressed. If the reader of this message is not the intended
>> recipient, you are hereby notified that any review, retransmission,
>> dissemination, distribution, copying or other use of, or taking of any
>> action in reliance upon this information is strictly prohibited. If you
>> have received this communication in error, please contact the sender and
>> delete the material from your computer.
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!OhV8SJR5gsp9_wP7MDmyCYTI7L46MclpSTlQ6gCpa0VBY8WpQ6W33EKO9GLR8CXEsE8Rc--dks5QsRRDyj_n7N12JDSXr1UAVHlBKAI$>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttps://lists.openid.net/mailman/listinfo/openid-specs-ab <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!OhV8SJR5gsp9_wP7MDmyCYTI7L46MclpSTlQ6gCpa0VBY8WpQ6W33EKO9GLR8CXEsE8Rc--dks5QsRRDyj_n7N12JDSXr1UAVHlBKAI$>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>>
>> https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!OhV8SJR5gsp9_wP7MDmyCYTI7L46MclpSTlQ6gCpa0VBY8WpQ6W33EKO9GLR8CXEsE8Rc--dks5QsRRDyj_n7N12JDSXr1UAVHlBKAI$
>>
> --
> [image: Capital One]
>
> George Fletcher (he/him)
>
> Executive Distinguished Engineer • Identity Architect
> [image: address]8020 Towers Crescent Drive, Vienna, VA 22128
> [image: mobile]616-498-8240
>
> assistant: [image: email] sharon.anderson at capitalone.com
> ------------------------------
>
>
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
>
>
>

______________________________________________________________________



The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220516/4f696438/attachment.html>

More information about the Openid-specs-ab mailing list