<html 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:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Yes, you old me. Please point to the legal requirement. It seems that the laws of the EU are in conflict here.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>thx ..tom</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:torsten@lodderstedt.net">Torsten Lodderstedt</a><br><b>Sent: </b>Friday, February 15, 2019 10:33 AM<br><b>To: </b><a href="mailto:thomasclinganjones@gmail.com">thomasclinganjones@gmail.com</a><br><b>Cc: </b><a href="mailto:tonynad@microsoft.com">Anthony Nadalin</a>; <a href="mailto:openid-specs-ab@lists.openid.net">Artifact Binding/Connect Working Group</a><br><b>Subject: </b>Re: [Openid-specs-ab] [E] OpenID Connect forIdentityProofing(Proposal)</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Am 15.02.2019 um 19:07 schrieb <thomasclinganjones@gmail.com> <thomasclinganjones@gmail.com>:</p><p class=MsoNormal>> </p><p class=MsoNormal>> That is not a use case – it is a solution.</p><p class=MsoNormal>> </p><p class=MsoNormal>> Let’s solve the same problem the way it is done in the US. A bank does in-person proofing of a users ID documents. The person asks to deal with another bank. That bank send a couple of ACH payments (or withdrawals) to the user’s bank account. The person verifies the transaction with the second bank (or gov’t agency). The KYU proof of the first bank is acceptable to the second bank. Not other data is transferred.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>You already proposed this when we talked at IIW. It might work in the US, but it does not fulfill the legal requirements in the EU (I already told you). </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-----</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I would like to make a general note: I’m not sure where this discussion will lead us. My objective is to work towards an international standard to convey data for strong identity assurance (thanks Tony!) that could be used across jurisdictions. And this standard should solve real world business problems. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The approach I propose might look alien to some people on first sight. And honestly speaking, I’m not super happy with the amount of data being exchanged between the involved parties. But in the end, that’s what the current law in Germany forces us to do. Changing the law will take much longer then building the software to comply with it. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’m not interested in endless discussions of whether what we do is legal in our jurisdiction. It is, since it has been checked by a tons of lawyers and is officially certified as identification approach under eIDAS (and for sure compliant with GDPR).</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I suggest we start gathering the requirements from other jurisdiction and based on that work towards a joined solution. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>My proposal can easily be enhanced to just carry assurance levels if that’s sufficient for other use cases and jurisdictions. I already marked the respective place in the document before I sent it to the list. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>best regards,</p><p class=MsoNormal>Torsten. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> </p><p class=MsoNormal>> ..tom</p><p class=MsoNormal>> To: Anthony Nadalin</p><p class=MsoNormal>> Cc: Artifact Binding/Connect Working Group; Tom Jones</p><p class=MsoNormal>> Subject: Re: [Openid-specs-ab] [E] OpenID Connect for IdentityProofing(Proposal)</p><p class=MsoNormal>> </p><p class=MsoNormal>> _Anyone_ can enter a person’s data, it does not need to be the person herself. That’s not what I mean by identity proofing.</p><p class=MsoNormal>> </p><p class=MsoNormal>> Let me first explain a use case, I will come back to identity proofing in the second step.</p><p class=MsoNormal>> </p><p class=MsoNormal>> - Use Case Opening a banking account</p><p class=MsoNormal>> A person wants to electronically open a new bank account with a bank he never had a business relationship before.</p><p class=MsoNormal>> </p><p class=MsoNormal>> The person claims a name, address and other person data. The bank accepts the application, opens the new account and issues credentials (username + password, potentially bound to the person’s fido key) to the person.</p><p class=MsoNormal>> </p><p class=MsoNormal>> The person now can use the bank account to transfer money to remote destinations ….</p><p class=MsoNormal>> </p><p class=MsoNormal>> - Identity Proofing</p><p class=MsoNormal>> </p><p class=MsoNormal>> Anti money laundering law obliges the bank to verify the person’s identity before it does business with her. Let’s assume the bank uses DLDV to check the data. All the bank learns, yes, there is a John Smith born 1/1/1976 in New York City. The user in front of the computer actually opening the bank account could be someone else. All this person needs to know is John’s person data.</p><p class=MsoNormal>> </p><p class=MsoNormal>> To really verify the user is John, the bank would need to establish a really strong binding between the user in front of the computer and the identity. If John’s drivers license would be an eID, he could let it assert his identity towards the bank. He would need to proof legit ownership of the eID, e.g. by entering a pin. One can also use an IDP in a similar role. As a pre-requisite, the IDP must have (physically) checked Johns drivers license in advance, associated the respective data with a user account AND issued strong credentials for that account to John.</p><p class=MsoNormal>> </p><p class=MsoNormal>> > Am 15.02.2019 um 18:43 schrieb Anthony Nadalin <tonynad@microsoft.com>:</p><p class=MsoNormal>> ></p><p class=MsoNormal>> > Torsten, not sure what you mean by " It does not tell the caller whether the user it interacts with is this person.", as it actually may not be nor does it have to.</p><p class=MsoNormal>> ></p><p class=MsoNormal>> > -----Original Message-----</p><p class=MsoNormal>> > From: Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net> On Behalf Of Torsten Lodderstedt via Openid-specs-ab</p><p class=MsoNormal>> > Sent: Friday, February 15, 2019 9:34 AM</p><p class=MsoNormal>> > To: Tom Jones <thomasclinganjones@gmail.com></p><p class=MsoNormal>> > Cc: Torsten Lodderstedt <torsten@lodderstedt.net>; Artifact Binding/Connect Working Group <openid-specs-ab@lists.openid.net></p><p class=MsoNormal>> > Subject: Re: [Openid-specs-ab] [E] OpenID Connect for Identity Proofing(Proposal)</p><p class=MsoNormal>> ></p><p class=MsoNormal>> ></p><p class=MsoNormal>> ></p><p class=MsoNormal>> >> Am 14.02.2019 um 19:22 schrieb Tom Jones <thomasclinganjones@gmail.com>:</p><p class=MsoNormal>> >></p><p class=MsoNormal>> >> Their API is public, their processes are not. It is my understanding that they do the lookup in the state databases directly. I cannot tell you anything about that api.</p><p class=MsoNormal>> ></p><p class=MsoNormal>> > I took a look onto the "Driver's License Data Verification (DLDV) Service" (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.aamva.org%2FDLDV%2F&data=02%7C01%7Ctonynad%40microsoft.com%7Ccbf217f0de88480fc9cf08d6936bca54%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636858488509504792&sdata=AJnAPaW3m3huHFVy%2FiRvCHJOCfaxT2Zi35DowYLrsWU%3D&reserved=0 and https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.movemag.org%2Fidentity-management%2F172-it-s-a-match.html&data=02%7C01%7Ctonynad%40microsoft.com%7Ccbf217f0de88480fc9cf08d6936bca54%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636858488509504792&sdata=0Eu1uJ86ZwMz55NX%2Bi71fpw1TFEK1bMSeXIwfdkK%2F1w%3D&reserved=0)</p><p class=MsoNormal>> ></p><p class=MsoNormal>> > The service tells the caller whether the data presented in the request is the same as what the issuer has on file. That’s basically a check whether the data presented are consistent, e.g. there is a person John Smith born on 1/1/1976 in New York City.</p><p class=MsoNormal>> ></p><p class=MsoNormal>> > It does not tell the caller whether the user it interacts with is this person.</p><p class=MsoNormal>> ></p><p class=MsoNormal>> > How is this link typically established?</p><p class=MsoNormal>> ></p><p class=MsoNormal>> >> This is becoming more interesting because the DHS 'Real ID law', which</p><p class=MsoNormal>> >> mandates a certain level of proofing be be able to get on an airplane (or certain other venues.) My state already offers two levels of proofing (assurance if you will.) I can use my enhanced state driver's license as a stand-in for a passport and visa to Canada.</p><p class=MsoNormal>> >></p><p class=MsoNormal>> >> Health is now the topic of most interest to me. What sort of user consent is required for each of about 6 different categories of data that could be transferred between providers.</p><p class=MsoNormal>> >> I think that you are going the wrong way with sending more data than is required for the proofing process. Current history is not on your side. Legally i have no information about what might be required.</p><p class=MsoNormal>> >> Peace ..tom</p><p class=MsoNormal>> >></p><p class=MsoNormal>> >></p><p class=MsoNormal>> >> On Thu, Feb 14, 2019 at 10:09 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:</p><p class=MsoNormal>> >></p><p class=MsoNormal>> >>> Am 14.02.2019 um 17:47 schrieb Tom Jones <thomasclinganjones@gmail.com>:</p><p class=MsoNormal>> >>></p><p class=MsoNormal>> >>> AAMVA validates the data provided to it by the client (from the</p><p class=MsoNormal>> >>> user) against state issued identity documents</p><p class=MsoNormal>> >></p><p class=MsoNormal>> >> I’m trying to understand the process. I assume the client sends a set of data to a AAMVA via an API. Does AAMVA look that data up in databases containing the data of state issued identity documents?</p><p class=MsoNormal>> > </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>