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

Anthony Nadalin tonynad at microsoft.com
Thu Aug 1 19:01:19 UTC 2019


Agree but Issue with that is it’s not used in most of the ISO standards and need something all jurisdictions can accept, thus using the international std where possible

From: Tom Jones <thomasclinganjones at gmail.com>
Sent: Thursday, August 1, 2019 11:59 AM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: Marcos Sanz <sanz at denic.de>; Anthony Nadalin <tonynad at microsoft.com>
Subject: Re: [Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06

schema.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Ctonynad%40microsoft.com%7C60b7b833d77041975de608d716b2545f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002827501396418&sdata=nn%2BaTgrD6HgtYbtlliUp1AWqXjMOxZmYgDDH6LsE3eQ%3D&reserved=0> has a comprehensive structure for address.
Peace ..tom


On Thu, Aug 1, 2019 at 10:08 AM Anthony Nadalin via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:
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<mailto: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<mailto:sanz at denic.de>>
Cc: Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>>; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net<mailto: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<mailto:sanz at denic.de>> wrote:
>
> Hi Torsten,
>
>> a new revision of
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopen<https://open>
> id.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.net&data=02%7C01%7Ctonynad%40microsoft.com%7C60b7b833d77041975de608d716b2545f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002827501396418&sdata=L19pn7kW8jTAx5vxpoAAvlyLEGMXcGGnPHEZqfa6%2Bs0%3D&reserved=0>%2Fspecs%2Fopenid-connect-4-identity-assurance-1_0.html&data=02%7C01%7Ctonynad%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Ctonynad%40microsoft.com%7C60b7b833d77041975de608d716b2545f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002827501396418&sdata=wsEzoZbkmrP4zcQKXVXP96PQIlvMjeKXOH%2BMNfUf3PE%3D&reserved=0>%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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F4.1.1.3&data=02%7C01%7Ctonynad%40microsoft.com%7C60b7b833d77041975de608d716b2545f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002827501396418&sdata=rz2ek7rY0pbvc5ZmFprytCVI7FKdraFpaz1LBlu7XF8%3D&reserved=0>: 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.com&data=02%7C01%7Ctonynad%40microsoft.com%7C60b7b833d77041975de608d716b2545f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002827501396418&sdata=RCVLkJIESb55c7xW30xc33Bgm6DQoXaMl2fJcxoVz4k%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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.com&data=02%7C01%7Ctonynad%40microsoft.com%7C60b7b833d77041975de608d716b2545f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002827501396418&sdata=RCVLkJIESb55c7xW30xc33Bgm6DQoXaMl2fJcxoVz4k%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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Foneserver.oneop.com%2Fclaim_source&data=02%7C01%7Ctonynad%40microsoft.com%7C60b7b833d77041975de608d716b2545f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002827501396418&sdata=%2BUR2fe913kcw2pz5ACmztkM4mu7e5rf4ypLm2iqIvdo%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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fanotherserver.yetanotherop.com%2F&data=02%7C01%7Ctonynad%40microsoft.com%7C60b7b833d77041975de608d716b2545f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002827501396418&sdata=kGMhHESV%2BLO9dG2PQWByiN4%2F5tMYLt9eW0cje0zWkNE%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<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C01%7Ctonynad%40microsoft.com%7C60b7b833d77041975de608d716b2545f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002827501396418&sdata=%2FuIdSRdN5cMIES4oeKBpIvpoccMsTFLVB2%2Fdy8zCjME%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190801/cf9b7077/attachment-0001.html>


More information about the Openid-specs-ab mailing list