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

Torsten Lodderstedt torsten at lodderstedt.net
Tue Aug 13 15:34:22 UTC 2019


Hi Tony,

thanks for sharing your musings with us.

> On 1. Aug 2019, at 19:07, Anthony Nadalin <tonynad at microsoft.com> wrote:
> 
> Some musings: 
> 
> 1.	Claims, these should be just "entity" claims and not specific to “end_users”

I changed the terminology to end user Claims to conform to the OpenID Connect Core wording. I’m fine with entity given it is more generic, but I would be interested to come to a stable terminology.

Any options by other WG members? 

> 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.

Are you suggesting to replace the JSON Object with a JSON String + delimiter? What would be the benefit?

> 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.

The only difference to the address claim is a second street address field and street instead of locality. What would be the benefit?

> 4.	Name (Birth, given, etc.) needs to be more prescriptive,  No titles and/or suffixes shall be included.

The name definitions do not include titles or suffixes as there are separate claims for salutation and title. I’m not sure what your suggestion is.

> 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,

According to https://en.wikipedia.org/wiki/ISO/IEC_7812 this standard is mostly used to identify commercial card issuers. I’m not quite sure how applicable this standard is in the identity assurance space.

The German eID system, for example, represents the issuing state using ICAO country codes, which somehow fits into the current definition of the issuer element (+we have an outstanding ticket to use ICAO instead of ISO country codes).

> 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,

The issuer is the authority that issued the id document. 

> so I would tend not to use verifier unless you truly intend that this is the entity that verified the document

That’s the intention. The verifier shall represent the entity that verified the id document (integrity, authenticity, binding to person).

> (which could be a drivers license and no one verifies these since they don’t have access to the DL information).

I assume this is jurisdiction specific. 

Verifying an ID card or Passport is classically done by checking the security features + comparing the picture with the person’s face. Would you assume this to be a verification?

The verifier element is supposed to contain the identity of the entity that conducted this process. 

best regards,
Torsten. 

> 
> -----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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopen
>> 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%7C7d23f4c9a8494eb0c17b08d7169a7193%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002724897288563&sdata=yg4Aj0UzihQM1%2FlfMIO6fkUZC0Z253oH6AZYsqQ8dTo%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%7C7d23f4c9a8494eb0c17b08d7169a7193%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002724897288563&sdata=yg4Aj0UzihQM1%2FlfMIO6fkUZC0Z253oH6AZYsqQ8dTo%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%7C7d23f4c9a8494eb0c17b08d7169a7193%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002724897288563&sdata=m3hWEbhxprzUrM4NNygu3jmXjEjitZx1%2BUaz%2F4aG1VU%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%7C7d23f4c9a8494eb0c17b08d7169a7193%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002724897288563&sdata=rEjGA37sgpETML4AfyVVmrZmQ9JEAHtPmTcS2vNMm0E%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
> 

-------------- 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/194e5557/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list