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

Thu Aug 1 18:28:42 UTC 2019

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%7Ca6b040299cc4459a99bf08d716a48ee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002768366120355&sdata=Z3puf3Xqm9qkJ4Qw5wIQj9mb%2BQWycIuOiZAVXecidx8%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%7Ca6b040299cc4459a99bf08d716a48ee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002768366130351&sdata=%2BpoY8BqQ0DdLwWCd6BsHfOPf2KwqZXTR3agc5oSWC4A%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%7Ca6b040299cc4459a99bf08d716a48ee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002768366130351&sdata=rLHKOBt3xKBPbk6j%2FS0awODCNPObFyrCC8rg2ZsS9To%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%7Ca6b040299cc4459a99bf08d716a48ee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002768366130351&sdata=N5i0WGGs7R63TpAsKeKHMS9wbE%2BEb17AfRlXIqHA910%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%7Ca6b040299cc4459a99bf08d716a48ee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002768366130351&sdata=8lVWPd6iFTuwcuk0UGqGFE2jwozJG%2B5X0wzylwMx7HQ%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%7Ca6b040299cc4459a99bf08d716a48ee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002768366130351&sdata=8lVWPd6iFTuwcuk0UGqGFE2jwozJG%2B5X0wzylwMx7HQ%3D&reserved=0