<div dir="ltr">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.<div><br></div><div>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. This involves the user more directly in a granular processes of granting consent.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 6:26 AM Jeff LOMBARDO <<a href="mailto:jeff.lombardo@gmail.com">jeff.lombardo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hi Tornsten,</div><div><br></div><div>Not sure to be able to attend the call, so here is a list of comments in any case:</div><div>
<ol start="1" style="margin-bottom:0cm" type="1"><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">Using the User Info endpoint
looks effectively like the good way to split proofing from authentication.
I recognize the value o<i>f:</i><span></span></span></li><ul style="margin-bottom:0cm" type="circle"><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><i><span style="font-size:12pt;font-family:"Times New Roman",serif">organization</span></i><span style="font-size:12pt;font-family:"Times New Roman",serif"> as this might have been done
by the OP or a 3rd party<span></span></span></li><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><i><span style="font-size:12pt;font-family:"Times New Roman",serif">date</span></i><span style="font-size:12pt;font-family:"Times New Roman",serif"> but this should more
reflect <i>date_of_proofing</i> [see point 2]<span></span></span></li><ul style="margin-bottom:0cm" type="disc"><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">And
then we should have</span><span style="font-size:12pt;font-family:"Times New Roman",serif"> <i>date_of_next_proofing</i> [see point 2]:
timeout that is related to proofing, helping the RP to know when it should
callback for an update<span></span></span></li><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">This raise the question of
how to notify RP if proofing is revoked proven invalid before expiry.<span></span></span></li></ul></ul><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">Your proposition sounds like
<i>Vector of Trust</i> which emphases <i>SP-800-63-3</i><span></span></span></li><ul style="margin-bottom:0cm" type="circle"><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">I think we should try to
match it instead of trying to develop a parallel initiative<span></span></span></li><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">For example:<span></span></span></li><ul style="margin-bottom:0cm" type="disc"><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><i><span style="font-size:12pt;font-family:"Times New Roman",serif">Method</span></i><span style="font-size:12pt;font-family:"Times New Roman",serif"> and <i>Agent</i> fields
are already part of assurance evaluation in <i>SP-800-63-3</i> model<span></span></span></li><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">The Identity document
depending of the assurance level targeted can be more than one:<span></span></span></li><ul style="margin-bottom:0cm" type="circle"><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">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]<span></span></span></li><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">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.<span></span></span></li></ul><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">So, <i>Type</i> field, if necessary,
should focus on strength of evidence only not exact type of
evidence:<span></span></span></li><ul style="margin-bottom:0cm" type="circle"><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">For example: "Two
strong + 1 weak", "Two superior", etc.<span></span></span></li><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">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<span></span></span></li></ul><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">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 <i>VoT</i>
proves handy as it carries the whole information.<span></span></span></li></ul><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">Finally, we already know
how to map <i>SP-800-63-3</i> to <i>OMB </i>model and <i>eIDAS </i>model
[I call them the <i>Matrix of Trust</i>]<span></span></span></li></ul><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">I think it is very
dangerous, sensible, and risky to exchange document information (id,
expiry date, attributes) between OP and RP:<span></span></span></li><ul style="margin-bottom:0cm" type="circle"><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">This is against data
minimization;<span></span></span></li><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">This will be a new set of PII to
secure at RP;<span></span></span></li><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">This will a new external
data processing to declare at OP and for which OP SHALL gain the consent
for;<span></span></span></li><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">If the OP is Trusted, a
formal attestation that an IALx process has been performed SHALL be enough.<span></span></span></li><ul style="margin-bottom:0cm" type="disc"><li class="MsoNormal" style="line-height:normal;margin:0cm 0cm 8pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:"Times New Roman",serif">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<span></span></span></li></ul></ul></ol>
<p class="MsoNormal" style="margin:0cm 0cm 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><span> </span></p>
Best regards,</div><div><br></div><div>Jeff<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></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>
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>
</blockquote></div>
</blockquote></div>