[Openid-specs-ab] [E] OpenID Connect for Identity Proofing(Proposal)
Jeff LOMBARDO
jeff.lombardo at gmail.com
Fri Feb 15 03:25:36 UTC 2019
Sorry for my late follow up.
Le jeu. 14 févr. 2019 11:26, Torsten Lodderstedt <torsten at lodderstedt.net>
a écrit :
> Hi Jeff,
>
> thanks for your feedback! Please find my comments inline.
>
> > Am 14.02.2019 um 15:26 schrieb Jeff LOMBARDO <jeff.lombardo at gmail.com>:
> >
> > 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
>
> Do you mean the OP to determine when the RP should verify the user’s
> identity again?
>
> > • This raise the question of how to notify RP if
> proofing is revoked proven invalid before expiry.
>
> Under what circumstances do you see the need for such a notification? In
> the simplest case, the RP uses the OP to verify a user’s identity and then
> established its own credentials with the user. When the RP needs to
> re-evaluate the identity might depends on its legal context.
>
*Maybe an overthinked opinion but we saw Identity Fraud before with Paper.
We'll still see some even in Digital / Federated way. There my question.*
>
> > • 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
>
> I’m open for proposals. When I started this work at yes.com, I tried to
> utilize VoT but realized I need a syntax able to express different
> assurance levels etc for different claims in the same response/IDToken.
> That didn’t fit VoT.
>
*I don't understand why this does not fit. It is a 6 characters
representation in VoT where we need here 6 equivalent attributes. Overall
if there is somthing to fix in VoT we should look into that before trying
to think and push a new standard. Cause otherwise there will be a world of
standard and then no standard.*
>
> > • For example:
> > • Method and Agent fields are already part of
> assurance evaluation in SP-800-63-3 model
>
> Do you propose to rename the fields?
>
*No I propose to use VoT notation instead with carry values of Method and
Agent directly by expressing the levels of assurance of SP-800-63-3A.*
>
> > • 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]
>
> Sounds interesting. At least in Germany, the identity document will always
> be a single state issued document, typically the ID card sometimes the
> Passport and there are other identity documents, e.g. for refugees.
>
*I'm not talking about multiple state issued document. I just cite
SP-800-63-3 which states that level 2 (for example) can be reached if
validating:*
*•One evidence SUPERIOR (or STRONG if coming from a IAL2 source that can
directly confirm it)*
*Or*
*•Two evidences STRONG*
*Or*
*•One evidence STRONG and two FAIR*
*•Might also collect Biometric*
*WEAK, FAIR, STRONG, and SUPERIOR evidences having specific contraints.*
>
> > • 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.
>
> In my experience this largely depends on the legal requirements you may
> need to fulfill. I would wish the IDP could just attest to the RP that it
> verified the user identity according to the respective trust framework and
> is done. But that’s not the way legal text is written today (at least in
> Germany). For example, the Anti Money Laundering Law obliges the RP to
> store (and show in case of an audit) the identity document data. I was
> surprised to see that in first place, but that’s the law. Changing this
> will need some time ...
>
*I sincerely admit my non expertise of the AML laws you cite and
referenced. I will only bounce on one of your comment on the call: it is
possible if one IdP/OP is eIDAS certified. From my perspective, in the end
any IdP/OP/AP of importance SHALL be eIDAS compliant to server services
needing stringent AML assurance.*
> > • 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.
>
> Might work in US/CA, but not in the EU.
*it effectively comes from US NIST SP-800-63-3A but there are some very
good and official translation table. For example :*
[image: image.png]
*Or see attached.*
>
> > • 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
>
> Possible in some cases but not in all cases.
>
*I might be lost using SP-800-63-3 but it is a good standard so far.*
> > • 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]
>
> What does this mean?
>
*See my previous comment on translation fron NIST to eIDAS, we can do it to
other framework that encompass Identity proofing too [OMB is a US federal
fwk]*
[image: image.png]
>
> > • I think it is very dangerous, sensible, and risky to exchange
> document information (id, expiry date, attributes) between OP and RP:
>
> I basically agree.
>
> > • This is against data minimization;
>
> The objective of data minimization sometimes collides with the law (or
> other laws).
>
*But it is a best practice and main safeguard against data broker. limiting
the risks of data leak at your side without restricting the capability of
risk evaluation.*
>
> > • This will be a new set of PII to secure at RP;
>
> yep.
>
> > • This will a new external data processing to declare at
> OP and for which OP SHALL gain the consent for;
>
> Definitely! I assumed that and therefore not explicitly stated it in the
> document.
>
*Regaining consent once the data has been acquired can lead to consent
fatigue... so not having to share this data and then updating your consent
policy and finally acquiring a new consent for this new policy is good CX
if there is another way to do it that do not require sharing.*
>
> > • If the OP is Trusted, a formal attestation that an IALx
> process has been performed SHALL be enough.
>
> Again, depends on the jurisdiction and the particular IDP. For an eID
> system under eIDAS, attesting the data along with the eIDAS assurance level
> is legally sufficient from a RPs perspective. But eID systems under eIDAS
> need to be notified by a member state meaning the member state takes all
> liability for the identity attestation. Most member states will notify
> their official identity mechanisms only. In Germany, this is the eID Card.
> The problem is this card is rarely used for online transactions because it
> requires a card terminal or a compatible Android phone + app + the user to
> remember her PIN. There is therefore a market for other identity providers,
> like banks. Those IDPs are not regulated by eIDAS but nevertheless can
> fulfill the requirements imposed by some laws (telecommunication,
> anti-money laundering, eIDAS).
>
> In such a case it is up to the RP to evaluate the risk and use the data or
> not. That’s the reason why more data needs to be exposed then one might
> like.
>
>
> > • 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,
> Torsten.
>
> >
> > 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190214/067fb01a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 44215 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190214/067fb01a/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 43780 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190214/067fb01a/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Guidance on Levels of Assurance.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 101094 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190214/067fb01a/attachment.docx>
More information about the Openid-specs-ab
mailing list