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

Tom Jones thomasclinganjones at gmail.com
Thu Aug 1 18:58:53 UTC 2019


schema.org 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> 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> 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
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190801/3936adea/attachment-0001.html>


More information about the Openid-specs-ab mailing list