<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Section 11.2<o:p></o:p></p>
<p class="MsoNormal">I’m worried about the proliferation of documents that each jurisdiction may have as you have listed just the one for Germany, this list could have hundreds of them and not sure how I would interpret them<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net>
<b>On Behalf Of </b>Anthony Nadalin via Openid-specs-ab<br>
<b>Sent:</b> Thursday, August 1, 2019 12:01 PM<br>
<b>To:</b> Tom Jones <thomasclinganjones@gmail.com>; Artifact Binding/Connect Working Group <openid-specs-ab@lists.openid.net><br>
<b>Cc:</b> Anthony Nadalin <tonynad@microsoft.com><br>
<b>Subject:</b> Re: [Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> Tom Jones <<a href="mailto:thomasclinganjones@gmail.com">thomasclinganjones@gmail.com</a>>
<br>
<b>Sent:</b> Thursday, August 1, 2019 11:59 AM<br>
<b>To:</b> Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>><br>
<b>Cc:</b> Marcos Sanz <<a href="mailto:sanz@denic.de">sanz@denic.de</a>>; Anthony Nadalin <<a href="mailto:tonynad@microsoft.com">tonynad@microsoft.com</a>><br>
<b>Subject:</b> Re: [Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Ctonynad%40microsoft.com%7Cfdfebf27d5fb44439a6708d716b2aee0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002829019715496&sdata=%2Bylj0Z1dUk6jgLLLW3M6O6UrLX5yy%2FgnqXb2HIjpVCg%3D&reserved=0">schema.org</a>
has a comprehensive structure for address.<br clear="all">
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Peace ..tom<o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">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://open" target="_blank">https://open</a><br>
> <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fid.net&data=02%7C01%7Ctonynad%40microsoft.com%7Cfdfebf27d5fb44439a6708d716b2aee0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002829019725490&sdata=qteiGdCI3tWjvBMDeu5BYLTq2v1ohz6pWJAuyum6kfQ%3D&reserved=0" target="_blank">
id.net</a>%2Fspecs%2Fopenid-connect-4-identity-assurance-1_0.html&data=02%7C01%7Ctonynad%<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Ctonynad%40microsoft.com%7Cfdfebf27d5fb44439a6708d716b2aee0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002829019725490&sdata=14x24OUZqbhNxbFFICeoqq0PVkef7IEJld4pSOP%2FSBM%3D&reserved=0" 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="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F4.1.1.3&data=02%7C01%7Ctonynad%40microsoft.com%7Cfdfebf27d5fb44439a6708d716b2aee0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002829019735487&sdata=RiIH3iPBzAHgpLICFuCskfUSgz4UkLvkPRj%2B%2BiMp6xI%3D&reserved=0" 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%7Cfdfebf27d5fb44439a6708d716b2aee0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002829019745486&sdata=MvfSRCDk%2B07tsJuBafp1so3GI%2FwpoMNJ0g1QKuAd218%3D&reserved=0" 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%7Cfdfebf27d5fb44439a6708d716b2aee0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002829019745486&sdata=MvfSRCDk%2B07tsJuBafp1so3GI%2FwpoMNJ0g1QKuAd218%3D&reserved=0" 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%7Cfdfebf27d5fb44439a6708d716b2aee0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002829019755488&sdata=TEtrHdtHLvCggj0k0fPmekBH69SeGaruQe4kvERd0Uk%3D&reserved=0" 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%7Cfdfebf27d5fb44439a6708d716b2aee0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002829019765484&sdata=Dl%2BH0XAeOr9A%2BH2YMh7MevzdaaFuPk2OihRMTtoMXLw%3D&reserved=0" 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="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C01%7Ctonynad%40microsoft.com%7Cfdfebf27d5fb44439a6708d716b2aee0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002829019765484&sdata=gduKFwlP%2Fks7Jj13jgYceYG8zx2BCSHJ75%2BzQxRzjTQ%3D&reserved=0" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>