<div dir="ltr"><div dir="ltr">AAMVA validates the data provided to it by the client (from the user) against state issued identity documents.<div>It provides NO USER DATA to the client.</div><div><br></div><div>In the US only one bank needs KYC in a financial transaction, typically the bank that is transmitting the funds. That bank is never asked to provide KYC data to any non-sovereign entity,</div><div>I hear that there is a reluctance for banks to become IdPs, but there is no official statement.</div><div><br></div><div>Here is an identity model that i proposed several years ago. You should note that the dashed line between the user objects in the OP and AP is the one that i believe needs some clarification.</div><div><a href="https://tcwiki.azurewebsites.net/index.php?title=Identity_Model_Overview">https://tcwiki.azurewebsites.net/index.php?title=Identity_Model_Overview</a>.</div><div><br></div><div>It is the following from paragraph 39 of the GDPR that i believe you are violating (or perhaps just defining your way around.) It seems that you (and maybe Germany) define the data as necessary. The US does not. Perhaps it is legally necessary, it is not technically necessary.</div><div><br></div><div> The personal
data should be adequate, relevant and <u>limited to what is necessary</u> for the purposes for which they are processed.
This requires, in particular, ensuring that the period for which the personal data are stored is limited to a strict
minimum. Personal data should be processed only if the purpose of the processing could not reasonably be
fulfilled by other means. <br></div><div><br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 8:27 AM Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.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"><br>
<br>
> Am 14.02.2019 um 16:00 schrieb Tom Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>:<br>
> <br>
> I cannot see how the User info endpoint can be used to separate authn from attribute proof. As i read the spec the User info endpoint must be a part of the OP. I believe that we must find a way to separate the User info endpoint from the OP completely to solve the problem.<br>
> <br>
> We have a use case funded by NIST and supported by AAMVA in the US. There the AAMVA would validate claims that were presented. In other words, the RP (client) would collect the data (claims) from the user and send them to AAMVA for validation. The data would NOT be supplied by AAMVA.<br>
<br>
What does AAMVA validate? The fact the set of data is consistent or the binding of this data to the particular user (account)?<br>
<br>
> This involves the user more directly in a granular processes of granting consent.<br>
> <br>
> Peace ..tom<br>
> <br>
> <br>
> On Thu, Feb 14, 2019 at 6:26 AM Jeff LOMBARDO <<a href="mailto:jeff.lombardo@gmail.com" target="_blank">jeff.lombardo@gmail.com</a>> wrote:<br>
> Hi Tornsten,<br>
> <br>
> Not sure to be able to attend the call, so here is a list of comments in any case:<br>
> • Using the User Info endpoint looks effectively like the good way to split proofing from authentication. I recognize the value of:<br>
> • organization as this might have been done by the OP or a 3rd party<br>
> • date but this should more reflect date_of_proofing [see point 2]<br>
> • And then we should have date_of_next_proofing [see point 2]: timeout that is related to proofing, helping the RP to know when it should callback for an update<br>
> • This raise the question of how to notify RP if proofing is revoked proven invalid before expiry.<br>
> • Your proposition sounds like Vector of Trust which emphases SP-800-63-3<br>
> • I think we should try to match it instead of trying to develop a parallel initiative<br>
> • For example:<br>
> • Method and Agent fields are already part of assurance evaluation in SP-800-63-3 model<br>
> • The Identity document depending of the assurance level targeted can be more than one:<br>
> • A combination of multiple lower strength document can be equivalent to stronger strength document [Disclaimer: I will give a talk about this at EIC 2019]<br>
> • You don't want / won't be able to represent all possible combination and the Identity Assurance Level has already done the job for you if you trust the OP.<br>
> • So, Type field, if necessary, should focus on strength of evidence only not exact type of evidence:<br>
> • For example: "Two strong + 1 weak", "Two superior", etc.<br>
> • But even there, two different values may reflect in the same assurance level which should be your only base for risk evaluation at the RP<br>
> • Note that a high assurance level proofing under a low-level authentication assurance lowers the overall assurance level of the transaction. That's where the VoT proves handy as it carries the whole information.<br>
> • Finally, we already know how to map SP-800-63-3 to OMB model and eIDAS model [I call them the Matrix of Trust]<br>
> • I think it is very dangerous, sensible, and risky to exchange document information (id, expiry date, attributes) between OP and RP:<br>
> • This is against data minimization;<br>
> • This will be a new set of PII to secure at RP;<br>
> • This will a new external data processing to declare at OP and for which OP SHALL gain the consent for;<br>
> • If the OP is Trusted, a formal attestation that an IALx process has been performed SHALL be enough.<br>
> • If x is lower than y (RP lower bound for risk acceptance) then it will be the RP accountability to switch to a higher assuring OP or to perform the missing proofing steps through local document collection and validation<br>
> <br>
> Best regards,<br>
> <br>
> Jeff<br>
> <br>
> Le jeu. 14 févr. 2019, à 08 h 06, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>> a écrit :<br>
> Hi Jeff, <br>
> <br>
> I agree that authentication and identity assurance must be treated separately. The proposal is based on that concept (see intro). <br>
> <br>
> kind regards,<br>
> Torsten. <br>
> <br>
> > Am 12.02.2019 um 20:53 schrieb Jeff LOMBARDO <<a href="mailto:jeff.lombardo@gmail.com" target="_blank">jeff.lombardo@gmail.com</a>>:<br>
> > <br>
> > Thanks Torsten, that's very interesting to see new use cases poping up. Great initiative.<br>
> > <br>
> > I will read carefully as I'm very attached to 63A and even if as a starter I tend to thing like Tom (and by extension John.<br>
> > <br>
> > Best,<br>
> > <br>
> > JF<br>
> > <br>
> > Le lun. 11 févr. 2019, à 15 h 26, Tom Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> a écrit :<br>
> > At a recent conference on strong identities (dec 10-11 redmond) John brady suggested that we needed to separate identity claims from authentication.<br>
> > <br>
> > I strongly support John’s concept.<br>
> > <br>
> > From my perspective what that means is that the OP should be primarily in the business of authentication.<br>
> > <br>
> > Verified claims should not be mixed into that same basket.<br>
> > <br>
> > I would strong support creating some sort of “attribute provider” (whatever) to supplied claims.<br>
> > <br>
> > Note that the verified claims working group ahs a different meaning for verified.<br>
> > <br>
> > I believe to avoid confusion this concept needs a different name, like validated claims.<br>
> > <br>
> > <br>
> > <br>
> > thx ..tom<br>
> > <br>
> > <br>
> > <br>
> > From: Hjelm, Bjorn via Openid-specs-ab<br>
> > Sent: Monday, February 11, 2019 11:35 AM<br>
> > To: Artifact Binding/Connect Working Group; Torsten Lodderstedt<br>
> > Cc: Hjelm, Bjorn; Paul Grassi<br>
> > Subject: Re: [Openid-specs-ab] [E] OpenID Connect for Identity Proofing(Proposal)<br>
> > <br>
> > <br>
> > <br>
> > Torsten,<br>
> > <br>
> > Thank you for submitting this draft. I see a clear need for this functionality. Besides support for NIST SP 800-63A, I would also like to discuss how this work aligns with some of the discussions in the iGov WG about developing support for NISTIR 8112.<br>
> > <br>
> > <br>
> > <br>
> > Looking forward to a productive WG discussion.<br>
> > <br>
> > <br>
> > <br>
> > BR,<br>
> > <br>
> > Bjorn<br>
> > <br>
> > <br>
> > <br>
> > On 2/9/19, 4:41 AM, "Openid-specs-ab on behalf of Torsten Lodderstedt via 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 <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
> > <br>
> > <br>
> > <br>
> > Hi all,<br>
> > <br>
> > <br>
> > please find attached a document specifying an OpenID Connect Extension for the purpose of strong Identity Proofing. On behalf of <a href="http://yes.com" rel="noreferrer" target="_blank">yes.com</a>, I would be delighted to contribute this document to the AB/Connect Working Group.<br>
> > <br>
> > <br>
> > Background: At IIW I held a session about Identity Proofing with OpenID Connect to get a feeling regarding the communities appetite to standardize an OpenID Extension for this important but also challenging topic. The feedback was tremendous so I started to work on this specification. It is based on <a href="http://yes.com" rel="noreferrer" target="_blank">yes.com</a>’s experience with strong identity attestation in highly regulated contexts in the European Union, mainly in Germany. For example, it will be used to attest user identities in the context of creating Qualified (Remote) Electronic Signature according to eIDAS. This kind of signature is legally equivalent to a traditional (wet) signature on paper.<br>
> > <br>
> > <br>
> > The approach taken is focused on fulfilling the business requirements for natural person identification in the EU. So my assumption (and hope) is we together as a WG will refine and enhance the concept to cover the requirements of jurisdictions around the world. I look forward to having productive discussions.<br>
> > <br>
> > <br>
> > best regards,<br>
> > <br>
> > Torsten.<br>
> > <br>
> > <br>
> > <br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > <br>
> > Openid-specs-ab mailing list<br>
> > <br>
> > <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> > <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>
> > <br>
> > <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>
> <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>
<br>
</blockquote></div>