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

Tue Aug 13 15:38:13 UTC 2019

The first sentence of the introduction is supposed to explain the goal. 

"This specification defines an extension to OpenID Connect [OpenID] to address the use case of strong identity verification of a natural person in accordance with certain laws. Examples include Anti Money Laundering Laws, Telecommunication Acts, Anti Terror Laws, and regulations on trust services, such as eIDAS [eIDAS].”

I’m open for concrete suggestions as to how to improve the text. 

> On 1. Aug 2019, at 19:20, Anthony Nadalin <tonynad at microsoft.com> wrote:
> 
> 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%7C16e55b8b8d7143b2662608d716a2d1f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002760871831091&sdata=MW3Uc%2BL0enj5F31RMwHhekiJ%2B046%2Bd0FrLe6UE3eKYU%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%7C16e55b8b8d7143b2662608d716a2d1f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002760871831091&sdata=MW3Uc%2BL0enj5F31RMwHhekiJ%2B046%2Bd0FrLe6UE3eKYU%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%7C16e55b8b8d7143b2662608d716a2d1f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002760871831091&sdata=Sa63Fd%2FB35QlADN%2FMQedZf0uThzY0v0HvlR0wsPnykY%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%7C16e55b8b8d7143b2662608d716a2d1f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002760871831091&sdata=hwUcPAaAezIc06Y6pXaaEslSc8jZUjW6UbA1fxiOVgw%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%7C16e55b8b8d7143b2662608d716a2d1f5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002760871831091&sdata=w7Yp2e3deS3GmYHbWoKZswxmC2No0YIv3PtPLY%2B0oZI%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/2569eee0/attachment.p7s>