[Openid-specs-ab] [E] OpenID Connect for Identity Proofing(Proposal)
Tom Jones
thomasclinganjones at gmail.com
Thu Feb 14 16:47:44 UTC 2019
AAMVA validates the data provided to it by the client (from the user)
against state issued identity documents.
It provides NO USER DATA to the client.
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,
I hear that there is a reluctance for banks to become IdPs, but there is no
official statement.
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.
https://tcwiki.azurewebsites.net/index.php?title=Identity_Model_Overview.
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.
The personal data should be adequate, relevant and *limited to what is
necessary* 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.
Peace ..tom
On Thu, Feb 14, 2019 at 8:27 AM Torsten Lodderstedt <torsten at lodderstedt.net>
wrote:
>
>
> > Am 14.02.2019 um 16:00 schrieb Tom Jones via Openid-specs-ab <
> openid-specs-ab at lists.openid.net>:
> >
> > 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.
> >
> > 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.
>
> What does AAMVA validate? The fact the set of data is consistent or the
> binding of this data to the particular user (account)?
>
> > This involves the user more directly in a granular processes of granting
> consent.
> >
> > Peace ..tom
> >
> >
> > On Thu, Feb 14, 2019 at 6:26 AM Jeff LOMBARDO <jeff.lombardo at gmail.com>
> wrote:
> > Hi Tornsten,
> >
> > Not sure to be able to attend the call, so here is a list of comments in
> any case:
> > • Using the User Info endpoint looks effectively like the good way
> to split proofing from authentication. I recognize the value of:
> > • organization as this might have been done by the OP or a
> 3rd party
> > • date but this should more reflect date_of_proofing [see
> point 2]
> > • 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
> > • This raise the question of how to notify RP if
> proofing is revoked proven invalid before expiry.
> > • Your proposition sounds like Vector of Trust which emphases
> SP-800-63-3
> > • I think we should try to match it instead of trying to
> develop a parallel initiative
> > • For example:
> > • Method and Agent fields are already part of
> assurance evaluation in SP-800-63-3 model
> > • The Identity document depending of the assurance
> level targeted can be more than one:
> > • 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]
> > • 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.
> > • So, Type field, if necessary, should focus on
> strength of evidence only not exact type of evidence:
> > • For example: "Two strong + 1 weak", "Two
> superior", etc.
> > • 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
> > • 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.
> > • Finally, we already know how to map SP-800-63-3 to OMB
> model and eIDAS model [I call them the Matrix of Trust]
> > • I think it is very dangerous, sensible, and risky to exchange
> document information (id, expiry date, attributes) between OP and RP:
> > • This is against data minimization;
> > • This will be a new set of PII to secure at RP;
> > • This will a new external data processing to declare at
> OP and for which OP SHALL gain the consent for;
> > • If the OP is Trusted, a formal attestation that an IALx
> process has been performed SHALL be enough.
> > • 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
> >
> > Best regards,
> >
> > Jeff
> >
> > Le jeu. 14 févr. 2019, à 08 h 06, Torsten Lodderstedt <
> torsten at lodderstedt.net> a écrit :
> > Hi Jeff,
> >
> > I agree that authentication and identity assurance must be treated
> separately. The proposal is based on that concept (see intro).
> >
> > kind regards,
> > Torsten.
> >
> > > Am 12.02.2019 um 20:53 schrieb Jeff LOMBARDO <jeff.lombardo at gmail.com
> >:
> > >
> > > Thanks Torsten, that's very interesting to see new use cases poping
> up. Great initiative.
> > >
> > > 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.
> > >
> > > Best,
> > >
> > > JF
> > >
> > > Le lun. 11 févr. 2019, à 15 h 26, Tom Jones via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> a écrit :
> > > At a recent conference on strong identities (dec 10-11 redmond) John
> brady suggested that we needed to separate identity claims from
> authentication.
> > >
> > > I strongly support John’s concept.
> > >
> > > From my perspective what that means is that the OP should be primarily
> in the business of authentication.
> > >
> > > Verified claims should not be mixed into that same basket.
> > >
> > > I would strong support creating some sort of “attribute provider”
> (whatever) to supplied claims.
> > >
> > > Note that the verified claims working group ahs a different meaning
> for verified.
> > >
> > > I believe to avoid confusion this concept needs a different name, like
> validated claims.
> > >
> > >
> > >
> > > thx ..tom
> > >
> > >
> > >
> > > From: Hjelm, Bjorn via Openid-specs-ab
> > > Sent: Monday, February 11, 2019 11:35 AM
> > > To: Artifact Binding/Connect Working Group; Torsten Lodderstedt
> > > Cc: Hjelm, Bjorn; Paul Grassi
> > > Subject: Re: [Openid-specs-ab] [E] OpenID Connect for Identity
> Proofing(Proposal)
> > >
> > >
> > >
> > > Torsten,
> > >
> > > 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.
> > >
> > >
> > >
> > > Looking forward to a productive WG discussion.
> > >
> > >
> > >
> > > BR,
> > >
> > > Bjorn
> > >
> > >
> > >
> > > On 2/9/19, 4:41 AM, "Openid-specs-ab on behalf of Torsten Lodderstedt
> via Openid-specs-ab" <openid-specs-ab-bounces at lists.openid.net on behalf
> of openid-specs-ab at lists.openid.net> wrote:
> > >
> > >
> > >
> > > Hi all,
> > >
> > >
> > > please find attached a document specifying an OpenID Connect
> Extension for the purpose of strong Identity Proofing. On behalf of
> yes.com, I would be delighted to contribute this document to the
> AB/Connect Working Group.
> > >
> > >
> > > 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 yes.com’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.
> > >
> > >
> > > 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.
> > >
> > >
> > > best regards,
> > >
> > > Torsten.
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > >
> > > Openid-specs-ab mailing list
> > >
> > > Openid-specs-ab at lists.openid.net
> > >
> > > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> > >
> > >
> > >
> > > _______________________________________________
> > > Openid-specs-ab mailing list
> > > Openid-specs-ab at lists.openid.net
> > > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> >
> > _______________________________________________
> > 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/20190214/a8c7890c/attachment.html>
More information about the Openid-specs-ab
mailing list