[Openid-specs-ab] [E] OpenID Connect for Identity Proofing(Proposal)
Jeff LOMBARDO
jeff.lombardo at gmail.com
Fri Feb 15 20:38:25 UTC 2019
Thanks for the drive within your use case, which is clearer for me now even
if it sounds like it should have been from the begining.
Effectively VoT is global. I think I lost the track when looking at your
examples loosing the sense of the goals you try to achieve as your example
comprehend claims that all come from one document (the eID) which under VoT
is still good as one document related claims proofing = global proofing of
the assertion.
Maybe you should expand your example with not proofed claims (that are not
on the eID) andeven add an example with verified claims coming from
different documents.
Have a great end of week,
Jeff
Le ven. 15 févr. 2019, à 13 h 22, Torsten Lodderstedt <
torsten at lodderstedt.net> a écrit :
> Hi Jeff,
>
> >
> > 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.
>
> VoT (https://tools.ietf.org/html/draft-richer-vectors-of-trust-15 &
> https://openid.bitbucket.io/iGov/openid-igov-profile-id1.html#vot)
> combine assurance levels for Identity Proofing, Primary Credential Usage,
> and Assertion Presentation in a single value carried in an acr or vot claim
> in an ID Token.
>
> This essentially means there can only be a single value for the Identity
> Assurance Level, effectively meaning all claims in the ID Token must adhere
> to this level.
>
> My proposal allows the OP to provide RPs with verified and non-verified
> claims in the same ID Token (or User Info Response).
>
>
> >
> > > • 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.
>
> I know what SP-800-63-3 states but those rules cannot be applied in the
> jurisdictions I’m (a bit) familiar with.
>
> >
> > > • 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.
>
> That would be great! Since then all IDPs and RP would based on the same
> legal framework. Unfortunately, this won’t happen anytime soon.
>
> Please take a look at eIDAS (
> https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R0910)
> Article 7. It defines the prerequisites for an identity service to become a
> eID system. It basically says only member states can notify or recognize
> such a system. This makes sense the member state is takes liability for the
> respective eID system. Some member states, like Italy, will notify
> commercial identity providers. Other member states, like Germany, are not
> moving into this direction. This means there will be identity providers
> capable of strongly proofing identity that cannot slip under the eIDAS
> umbrella.
>
> >
> >
> > > • 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.
>
> What does „official“ mean? Is there a agreement between US and EU to
> mutually recognize those standards?
>
> best regards,
> Torsten.
>
> > For example :
> >
> >
> > <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.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
> > >
> >
> > <Guidance on Levels of Assurance.docx>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190215/b280b75b/attachment.html>
More information about the Openid-specs-ab
mailing list