[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