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

Torsten Lodderstedt torsten at lodderstedt.net
Tue Aug 13 15:41:09 UTC 2019


I included a statement referring to OpenID Connect language tags for that purpose. 

https://openid.net/specs/openid-connect-core-1_0.html#ClaimsLanguagesAndScripts 

> On 1. Aug 2019, at 20:55, Anthony Nadalin <tonynad at microsoft.com> wrote:
> 
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3923 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190813/25962641/attachment.p7s>


More information about the Openid-specs-ab mailing list