[Openid-specs-ab] [E] OpenID Connect forIdentityProofing(Proposal)

Fri Feb 15 22:01:49 UTC 2019

Hi Tornstern,

6 days time frame (from submission to what look like a consensus to go
ahead) including 48 hours of element checking and context comprehension
might be the alienest part of this whole thread if being considered endless
discussions.

I'm personally glad that at the end of the day it looks and sounds like
your proposition is rock solid and adding value. Sorry if explaining your
proposal to people (won't say peer as I'm considering myself below all the
good brains here) you submit to sounds like lost of time.

Considering laws, GDPR being a spin off the German privacy law, you might
not have the same lecture by the same lawyer. I met numerous  lawyer who
struggled with  interpretation for people like me (both EU and non EU
Citizens). Non EU citizens, resident of EU. Etc.

All those (AML, KYC, GDPR, eIDAS) may perfectly fit one in the other in
Germany. This is not the case on Canada (for what I can speak of).

So my point, and I think the point of people who challenged the proposition
so far (for the best of it as it is rock solid), was to be sure that, on
top of serving Germany interests this is compliant with rules they also
have to follow. Unless we renamed this as the DE_ID_Proofing_mechanism.

French say *ne confondons pas vitesse et précipitation *[do not confuse
speed with precipitation, not sure this exist on English].

With only best regards,

Jeff

Le ven. 15 févr. 2019 16:31, Tom Jones via Openid-specs-ab <
openid-specs-ab at lists.openid.net> a écrit :

> Yes, you old me. Please point to the legal requirement. It seems that the
> laws of the EU are in conflict here.
>
>
>
> thx ..tom
>
>
>
> *From: *Torsten Lodderstedt <torsten at lodderstedt.net>
> *Sent: *Friday, February 15, 2019 10:33 AM
> *To: *thomasclinganjones at gmail.com
> *Cc: *Anthony Nadalin <tonynad at microsoft.com>; Artifact Binding/Connect
> Working Group <openid-specs-ab at lists.openid.net>
> *Subject: *Re: [Openid-specs-ab] [E] OpenID Connect
> forIdentityProofing(Proposal)
>
>
>
>
>
>
>
> > Am 15.02.2019 um 19:07 schrieb <thomasclinganjones at gmail.com> <
> thomasclinganjones at gmail.com>:
>
> >
>
> > That is not a use case – it is a solution.
>
> >
>
> > 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.
>
>
>
> 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).
>
>
>
> -----
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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).
>
>
>
> I suggest we start gathering the requirements from other jurisdiction and
> based on that work towards a joined solution.
>
>
>
> 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.
>
>
>
> best regards,
>
> Torsten.
>
>
>
> >
>
> > ..tom
>
> > To: Anthony Nadalin
>
> > Cc: Artifact Binding/Connect Working Group; Tom Jones
>
> > Subject: Re: [Openid-specs-ab] [E] OpenID Connect for
> IdentityProofing(Proposal)
>
> >
>
> > _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.
>
> >
>
> > Let me first explain a use case, I will come back to identity proofing
> in the second step.
>
> >
>
> > - Use Case Opening a banking account
>
> > A person wants to electronically open a new bank account with a bank he
> never had a business relationship before.
>
> >
>
> > 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.
>
> >
>
> > The person now can use the bank account to transfer money to remote
> destinations ….
>
> >
>
> > - Identity Proofing
>
> >
>
> > 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.
>
> >
>
> > 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.
>
> >
>
> > > Am 15.02.2019 um 18:43 schrieb Anthony Nadalin <tonynad at microsoft.com
> >:
>
> > >
>
> > > 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.
>
> > >
>
> > > -----Original Message-----
>
> > > From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On
> Behalf Of Torsten Lodderstedt via Openid-specs-ab
>
> > > Sent: Friday, February 15, 2019 9:34 AM
>
> > > To: Tom Jones <thomasclinganjones at gmail.com>
>
> > > Cc: Torsten Lodderstedt <torsten at lodderstedt.net>; Artifact
> Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
>
> > > Subject: Re: [Openid-specs-ab] [E] OpenID Connect for Identity
> Proofing(Proposal)
>
> > >
>
> > >
>
> > >
>
> > >> Am 14.02.2019 um 19:22 schrieb Tom Jones <
> thomasclinganjones at gmail.com>:
>
> > >>
>
> > >> 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.
>
> > >
>
> > > 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
> )
>
> > >
>
> > > 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.
>
> > >
>
> > > It does not tell the caller whether the user it interacts with is this
> person.
>
> > >
>
> > > How is this link typically established?
>
> > >
>
> > >> This is becoming more interesting because the DHS 'Real ID law', which
>
> > >> 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.
>
> > >>
>
> > >> 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.
>
> > >> 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.
>
> > >> Peace ..tom
>
> > >>
>
> > >>
>
> > >> On Thu, Feb 14, 2019 at 10:09 AM Torsten Lodderstedt <
> torsten at lodderstedt.net> wrote:
>
> > >>
>
> > >>> Am 14.02.2019 um 17:47 schrieb Tom Jones <
> thomasclinganjones at gmail.com>:
>
> > >>>
>
> > >>> AAMVA validates the data provided to it by the client (from the
>
> > >>> user) against state issued identity documents
>
> > >>
>
> > >> 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?
>
> > >
>
>
>
>
> _______________________________________________
> 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/20190215/ec7d616a/attachment.html>