<div dir="ltr"><a href="http://schema.org">schema.org</a> has a comprehensive structure for address.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 1, 2019 at 10:08 AM Anthony Nadalin via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Some musings: <br>
<br>
1. Claims, these should be just "entity" claims and not specific to “end_users”<br>
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.<br>
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.<br>
4. Name (Birth, given, etc.) needs to be more prescriptive, No titles and/or suffixes shall be included.<br>
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).<br>
<br>
-----Original Message-----<br>
From: Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>> On Behalf Of Torsten Lodderstedt via Openid-specs-ab<br>
Sent: Thursday, August 1, 2019 6:39 AM<br>
To: Marcos Sanz <<a href="mailto:sanz@denic.de" target="_blank">sanz@denic.de</a>><br>
Cc: Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>>; Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
Subject: Re: [Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06<br>
<br>
Hi Marcos, <br>
<br>
thanks again for your review. <br>
<br>
> On 31. Jul 2019, at 12:22, Marcos Sanz <<a href="mailto:sanz@denic.de" target="_blank">sanz@denic.de</a>> wrote:<br>
> <br>
> Hi Torsten,<br>
> <br>
>> a new revision of<br>
> <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopen" rel="noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopen</a><br>
> <a href="http://id.net" rel="noreferrer" target="_blank">id.net</a>%2Fspecs%2Fopenid-connect-4-identity-assurance-1_0.html&data=02%7C01%7Ctonynad%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C7d23f4c9a8494eb0c17b08d7169a7193%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002724897288563&sdata=%2F3j9MyX4kks2avmVRZgML6oA%2BaWRFbPu9lvOJmXwha0%3D&reserved=0 is available.<br>
> <br>
> it's really getting closer :-)<br>
<br>
good to hear :-) <br>
<br>
> <br>
> Typos:<br>
> - There's still one instance of "verified_person_data" in section 5.1<br>
<br>
thanks. It seems to be pretty persistent ;-). <br>
<br>
> - Section <a href="http://4.1.1.3" rel="noreferrer" target="_blank">4.1.1.3</a>: s/eletronic signatue/electronic signature/<br>
<br>
fixed.<br>
<br>
> <br>
> Besides that, here at ID4me we were wondering how should we <br>
> syntactically express aggregated/distributed verified_claims answers <br>
> when they stem from/point at two or more different claims providers on <br>
> the light of the examples of sections 6.6 and 6.7. Should it be <br>
> something like<br>
> <br>
> { <br>
> "iss":"<a href="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" rel="noreferrer" target="_blank">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</a>", <br>
> "sub":"248289761001",<br>
> "_claim_names":{ <br>
> "verified_claims":{ <br>
> "claims":{ <br>
> "given_name":"src1",<br>
> "family_name":"src1",<br>
> "address":"src2"<br>
> }<br>
> }<br>
> },<br>
> "_claim_sources":{ <br>
> "src1":{ <br>
> "JWT":"..."<br>
> },<br>
> "src2":{ <br>
> "JWT":"..."<br>
> }<br>
> }<br>
> }<br>
> <br>
> respectively<br>
> <br>
> { <br>
> "iss":"<a href="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" rel="noreferrer" target="_blank">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</a>", <br>
> "sub":"248289761001",<br>
> "_claim_names":{ <br>
> "verified_claims":{ <br>
> "claims":{ <br>
> "given_name":"src1",<br>
> "family_name":"src1",<br>
> "address":"src2"<br>
> }<br>
> }<br>
> },<br>
> "_claim_sources":{ <br>
> "src1":{ <br>
> "endpoint":"<a href="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" rel="noreferrer" target="_blank">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</a>",<br>
> },<br>
> "src2":{ <br>
> "endpoint":"<a href="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" rel="noreferrer" target="_blank">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</a>",<br>
> "access_token":"ksj3n283dkeafb76cdef"<br>
> }<br>
> }<br>
> }<br>
> <br>
> I'd need some standards guidance on that.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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? <br>
<br>
best regards,<br>
Torsten. <br>
<br>
> <br>
> Thanks and regards,<br>
> Marcos<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>