<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Have a great end of week,</div><div><br></div><div>Jeff<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 15 févr. 2019, à 13 h 22, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jeff,<br>
<br>
> <br>
> 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. <br>
> <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>
> <br>
> I’m open for proposals. When I started this work at <a href="http://yes.com" rel="noreferrer" target="_blank">yes.com</a>, 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.<br>
> <br>
> 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. <br>
<br>
VoT (<a href="https://tools.ietf.org/html/draft-richer-vectors-of-trust-15" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-richer-vectors-of-trust-15</a> & <a href="https://openid.bitbucket.io/iGov/openid-igov-profile-id1.html#vot" rel="noreferrer" target="_blank">https://openid.bitbucket.io/iGov/openid-igov-profile-id1.html#vot</a>) 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. <br>
<br>
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. <br>
<br>
My proposal allows the OP to provide RPs with verified and non-verified claims in the same ID Token (or User Info Response). <br>
<br>
<br>
> <br>
> > • For example:<br>
> > • Method and Agent fields are already part of assurance evaluation in SP-800-63-3 model<br>
> <br>
> Do you propose to rename the fields?<br>
> <br>
> 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. <br>
> <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>
> <br>
> 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.<br>
> <br>
> 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:<br>
> •One evidence SUPERIOR (or STRONG if coming from a IAL2 source that can directly confirm it)<br>
> Or<br>
> •Two evidences STRONG<br>
> Or<br>
> •One evidence STRONG and two FAIR<br>
> •Might also collect Biometric<br>
> <br>
> WEAK, FAIR, STRONG, and SUPERIOR evidences having specific contraints.<br>
<br>
I know what SP-800-63-3 states but those rules cannot be applied in the jurisdictions I’m (a bit) familiar with. <br>
<br>
> <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>
> <br>
> 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 ...<br>
> <br>
> 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.<br>
<br>
That would be great! Since then all IDPs and RP would based on the same legal framework. Unfortunately, this won’t happen anytime soon. <br>
<br>
Please take a look at eIDAS (<a href="https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R0910" rel="noreferrer" target="_blank">https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R0910</a>) 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. <br>
<br>
> <br>
> <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>
> <br>
> Might work in US/CA, but not in the EU.<br>
> <br>
> it effectively comes from US NIST SP-800-63-3A but there are some very good and official translation table.<br>
<br>
What does „official“ mean? Is there a agreement between US and EU to mutually recognize those standards?<br>
<br>
best regards,<br>
Torsten. <br>
<br>
> For example :<br>
> <br>
> <br>
> <image.png><br>
> Or see attached.<br>
> <br>
> <br>
> <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>
> <br>
> Possible in some cases but not in all cases. <br>
> <br>
> I might be lost using SP-800-63-3 but it is a good standard so far.<br>
> <br>
> <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>
> <br>
> What does this mean?<br>
> <br>
> 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]<br>
> <br>
> <image.png><br>
> <br>
> > • I think it is very dangerous, sensible, and risky to exchange document information (id, expiry date, attributes) between OP and RP:<br>
> <br>
> I basically agree. <br>
> <br>
> > • This is against data minimization;<br>
> <br>
> The objective of data minimization sometimes collides with the law (or other laws).<br>
> <br>
> 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.<br>
> <br>
> <br>
> > • This will be a new set of PII to secure at RP;<br>
> <br>
> yep. <br>
> <br>
> > • This will a new external data processing to declare at OP and for which OP SHALL gain the consent for;<br>
> <br>
> Definitely! I assumed that and therefore not explicitly stated it in the document. <br>
> <br>
> 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. <br>
> <br>
> > • If the OP is Trusted, a formal attestation that an IALx process has been performed SHALL be enough.<br>
> <br>
> 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). <br>
> <br>
> 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. <br>
> <br>
> <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>
> Torsten. <br>
> <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>
> <Guidance on Levels of Assurance.docx><br>
<br>
</blockquote></div></div>