[Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06

Anthony Nadalin tonynad at microsoft.com
Thu Aug 1 18:55:34 UTC 2019


Basic question: How do you know the language of the claims, as there are special characters in many languages that may need to be processed in interpreting the claims, I would say there needs to be a ISO 639 field for language

-----Original Message-----
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Anthony Nadalin via Openid-specs-ab
Sent: Thursday, August 1, 2019 11:29 AM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>; Marcos Sanz <sanz at denic.de>; Torsten Lodderstedt <torsten at lodderstedt.net>
Cc: Anthony Nadalin <tonynad at microsoft.com>
Subject: Re: [Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06

More musings on Id_Documents:

driving_permit, must conform to ISO 18013-2 : Personal identification (this is an international drivers license (IDL) standard) passport, should be names "travel document" as there are many forms and passport is one of them, a passport must conform to ISO/IEC 7501-1:2008 Identification cards -- Machine readable travel documents -- Part 1: Machine readable passport

-----Original Message-----
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Anthony Nadalin via Openid-specs-ab
Sent: Thursday, August 1, 2019 10:20 AM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>; Marcos Sanz <sanz at denic.de>; Torsten Lodderstedt <torsten at lodderstedt.net>
Cc: Anthony Nadalin <tonynad at microsoft.com>
Subject: Re: [Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06

Introduction (goals not stated), I assume the goals are to facilitate electronic data exchange, and assist in authenticity and integrity validation

-----Original Message-----
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Anthony Nadalin via Openid-specs-ab
Sent: Thursday, August 1, 2019 10:08 AM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>; Marcos Sanz <sanz at denic.de>
Cc: Anthony Nadalin <tonynad at microsoft.com>
Subject: Re: [Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06

Some musings: 

1.	Claims, these should be just "entity" claims and not specific to “end_users”
2.	Birth place should be more prescriptive, three fields delimited by the sub-field delimiter - City; State/Province or District; Country.  Addresses that cannot be expressed in the defined character set shall be transliterated.
3.	I don’t believe the current OpenID Address claim is sufficient need to be more prescriptive , should be Six fields delimited by the sub-field delimiter - Street address line 1 (e.g. street name and number); Street address line 2 (e.g. apartment number); City; State/Province or District; Postal Code; Country.  Addresses that cannot be expressed in the defined character set shall be transliterated.
4.	Name (Birth, given, etc.) needs to be more prescriptive,  No titles and/or suffixes shall be included.
5.	Id_Document  needs to be more prescriptive, as the verifier should be able to be expressed as an ISO issuer/verifier as described in iso/iec 7812-1, also this brings up the question of verifier vs issuer, I assume that the case would be that the issuer in the case of an ID card is the issuer not the verifier, so I would tend not to use verifier unless you truly intend that this is the entity that verified the document (which could be a drivers license and no one verifies these since they don’t have access to the DL information).

-----Original Message-----
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Torsten Lodderstedt via Openid-specs-ab
Sent: Thursday, August 1, 2019 6:39 AM
To: Marcos Sanz <sanz at denic.de>
Cc: Torsten Lodderstedt <torsten at lodderstedt.net>; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06

Hi Marcos, 

thanks again for your review. 

> On 31. Jul 2019, at 12:22, Marcos Sanz <sanz at denic.de> wrote:
> 
> Hi Torsten,
> 
>> a new revision of
> https://open
> id.net%2Fspecs%2Fopenid-connect-4-identity-assurance-1_0.html&data=02%7C01%7Ctonynad%40microsoft.com%7C7d23f4c9a8494eb0c17b08d7169a7193%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002724897288563&sdata=%2F3j9MyX4kks2avmVRZgML6oA%2BaWRFbPu9lvOJmXwha0%3D&reserved=0 is available.
> 
> it's really getting closer :-)

good to hear :-) 

> 
> Typos:
> - There's still one instance of "verified_person_data" in section 5.1

thanks. It seems to be pretty persistent ;-).  

> - Section 4.1.1.3: s/eletronic signatue/electronic signature/

fixed.

> 
> Besides that, here at ID4me we were wondering how should we 
> syntactically express aggregated/distributed verified_claims answers 
> when they stem from/point at two or more different claims providers on 
> the light of the examples of sections 6.6 and 6.7. Should it be 
> something like
> 
> { 
>   "iss":"https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.com&data=02%7C01%7Ctonynad%40microsoft.com%7Cf702207a79164f5d81f308d716ae1d68%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002809389803549&sdata=cC7QphGdn8oyaq2ootI1p6Y%2FFnoCfkWXWmv1abFD7DM%3D&reserved=0", 
>   "sub":"248289761001",
>   "_claim_names":{ 
>       "verified_claims":{ 
>         "claims":{ 
>            "given_name":"src1",
>            "family_name":"src1",
>            "address":"src2"
>         }
>      }
>   },
>   "_claim_sources":{ 
>      "src1":{ 
>      "JWT":"..."
>      },
>     "src2":{ 
>      "JWT":"..."
>      }
>   }
> }
> 
> respectively
> 
> { 
>   "iss":"https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.com&data=02%7C01%7Ctonynad%40microsoft.com%7Cf702207a79164f5d81f308d716ae1d68%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002809389803549&sdata=cC7QphGdn8oyaq2ootI1p6Y%2FFnoCfkWXWmv1abFD7DM%3D&reserved=0", 
>   "sub":"248289761001",
>   "_claim_names":{ 
>       "verified_claims":{ 
>         "claims":{ 
>            "given_name":"src1",
>            "family_name":"src1",
>            "address":"src2"
>         }
>      }
>   },
>   "_claim_sources":{ 
>      "src1":{ 
>       "endpoint":"https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Foneserver.oneop.com%2Fclaim_source&data=02%7C01%7Ctonynad%40microsoft.com%7Cf702207a79164f5d81f308d716ae1d68%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002809389803549&sdata=ZPlLbNU5pD2lsfOJ73pVrmSmEnW%2FQZ%2F61bzdyi5tIJ8%3D&reserved=0",
>      },
>     "src2":{ 
>      "endpoint":"https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fanotherserver.yetanotherop.com%2F&data=02%7C01%7Ctonynad%40microsoft.com%7Cf702207a79164f5d81f308d716ae1d68%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002809389803549&sdata=Qx9Bmxr5jxdq4R1VqKnD%2FJ2OaMGDtE9fLLsZLtJR1Dc%3D&reserved=0",
>         "access_token":"ksj3n283dkeafb76cdef"
>      }
>   }
> }
> 
> I'd need some standards guidance on that.

Very interesting question. I had envisioned the external claim provider to provide the while “verified_claims” Claim at once. As this is a top level claim, one can rely on the standard OIDC mechanisms. 

Now you are proposing to obtain the claims within the “verified_claims” Claim from external providers. Syntactically we can make that work on one way or the other. 

I would like to understand more about the context and use case. How does the IDP asserting the “verified_claims" Claim to the RP ensure that the externally provided data comply with the data provided in the verification element?  
 
best regards,
Torsten. 

> 
> Thanks and regards,
> Marcos

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C01%7Ctonynad%40microsoft.com%7Cf702207a79164f5d81f308d716ae1d68%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002809389803549&sdata=iDJZ4UbNdaZydsK1Kgx5t4vaY2LIAGo0s5wA8NFg7Oc%3D&reserved=0
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C01%7Ctonynad%40microsoft.com%7Cf702207a79164f5d81f308d716ae1d68%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002809389803549&sdata=iDJZ4UbNdaZydsK1Kgx5t4vaY2LIAGo0s5wA8NFg7Oc%3D&reserved=0
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C01%7Ctonynad%40microsoft.com%7Cf702207a79164f5d81f308d716ae1d68%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002809389813538&sdata=5oXwirxythewj2ucqSQx%2BnrMHWPaB%2BSHl1Gyte%2BOOIE%3D&reserved=0


More information about the Openid-specs-ab mailing list