[Openid-specs-ab] [External Sender] Re: OIDC for Verifiable Presenations
Vittorio Bertocci
vittorio.bertocci at auth0.com
Mon May 16 19:38:44 UTC 2022
Inconsequential, but it’s already the second time I see it spelled this way
so I can’t help pointing out that it’s “Pareto” principle :)
On Mon, May 16, 2022 at 11:09 David Chadwick via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:
> *This message originated outside your organization.*
>
> ------------------------------
>
>
> On 16/05/2022 18:31, George Fletcher wrote:
>
> 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 :)
>
> Which is why DIF PEv2 has adopted the Piretto Principle of satisfying 80%
> of requirements with 20% of the implementation effort (i.e. it covers
> conjunctive requests and selective disclosure). Whether disjunctive
> requests will become predominant or not is too early to say. Whether
> implementors will decide the extra effort is worth it or not will depend
> upon many factors, and again is too early to tell.
>
> Kind regards
>
> David
>
> p.s. You many find that some implementors already have their own
> proprietary ways of specifying more complex disjunctive forms in easy to
> implement and use ways.
>
> 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
>> <https://www.google.com/maps/search/8020%0D%0A++++++++++++++++++++++++++++Towers+Crescent+Drive,+Vienna,+VA?entry=gmail&source=g>
>> 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.
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220516/77caa568/attachment.html>
More information about the Openid-specs-ab
mailing list