<div dir="ltr">why would the needs of the rp impact the open id provider?<div>I can think of one reason that has been defined, that of assurance.</div><div>The RP may require a certain level of assurance, vis a vis the NIST sp 800-63 (either v2 or v3)</div><div>I would recommending a scope for assurance.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div>
<br><div class="gmail_quote">On Sat, Jul 28, 2018 at 10:36 PM, Dave Tonge via Openid-specs-fapi <span dir="ltr"><<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Hi Torsten</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">We have an issue open to make it more explicit about the `openid` scope value:</div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><a href="https://bitbucket.org/openid/fapi/issues/149/make-it-clear-that-the-entire-flow-is-oidc" target="_blank">https://bitbucket.org/openid/<wbr>fapi/issues/149/make-it-clear-<wbr>that-the-entire-flow-is-oidc</a></font><br></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">Your use-case is definitely valid and we've heard it a few times and definitely need a solution.</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">I'm hesitant to say that the hybrid flow should be able to be implemented without the `openid` scope value. </font><span style="font-family:"trebuchet ms",sans-serif">My understanding is that many implementations of authorisation servers use the presence of `openid` in the </span><span style="font-family:"trebuchet ms",sans-serif">scope to turn on all the OIDC related features such as: id tokens, hybrid flow, request object, claims parameter, </span><span style="font-family:"trebuchet ms",sans-serif">stricter processing rules, etc.</span></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">Wouldn't it be better to use another `scope` value for the RP to indicate that it wants a long-lived end-user identifier (and possibly other claims), rather than an "ephemeral subject identifier". From a spec perspective using a scope value of `openid` doesn't' guarantee the RP that they will receive back a long-lived user identifier.</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">I agree with you that it would be better to handle both use cases from a single client.</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">What do you think about using another scope value?</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif">Dave</font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div><div class="gmail_default"><font face="trebuchet ms, sans-serif"><br></font></div></div><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Sat, 28 Jul 2018 at 13:58, Torsten Lodderstedt via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.<wbr>openid.net</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Hi all,<br>
<br>
the "Read and Write API Security Profile" mandates the AS to use response type values "code id_token" or "code id_token token“ meaning an ID Token is provided in any case. In my understanding ID Token is primarily used to further secure the interaction, e.g. by providing the client with an iss claim used to detect mix-up.<br>
<br>
Is it possible for the RP to use this functionality without the „openid" scope value? The reason I’m asking is I would like to let a RP/client differentiate use cases where it just wants to obtain an access token for API access but is not interested in the user id and use cases where the same client (now as RP) wants to obtain user id and further claims. Using the scope value „openid“ to differentiate those use cases seams straightforward to me. Otherwise the RP would need to use two different client ids with different sub claim policies for the different use cases, which most likely will cause complexity in the AS/OP's consent handling as I assume the RP would like to be the same legal entity in both cases.  <br>
<br>
Thoughts? <br>
<br>
kind regards,<br></div></div><span class="">
Torsten. ______________________________<wbr>_________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>fapi</a><br>
</span></blockquote></div><span class="HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_8837857935574826839gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:1em;font-weight:bold;line-height:1.4"><div style="color:rgb(97,97,97);font-family:'Open Sans';font-size:14px;font-weight:normal;line-height:21px"><div style="font-family:Arial,Helvetica,sans-serif;font-size:0.925em;line-height:1.4;color:rgb(220,41,30);font-weight:bold"><div style="font-size:14px;font-weight:normal;color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4"><div style="font-weight:400;color:rgb(51,51,51);line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4">Dave Tonge</div><div style="font-size:0.8125em;line-height:1.4">CTO</div><div style="font-size:0.8125em;line-height:1.4;margin:0px"><a href="http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A" style="color:rgb(131,94,165)" target="_blank"><img alt="Moneyhub Enterprise" height="50" src="http://content.moneyhub.co.uk/images/teal_Moneyhub-Ent_logo_200x50.png" title="Moneyhub Enterprise" width="200" style="border:none;padding:0px;border-radius:2px;margin:7px"></a></div><div style="padding:8px 0px"><div style="padding:8px 0px"><span style="color:rgb(0,164,183);font-size:11px">Moneyhub Financial Technology, 2nd Floor, Whitefriars Business Centre, Lewins Mead, Bristol, BS1 2NT</span></div><span style="font-size:11px;line-height:15.925px;color:rgb(0,164,183);font-weight:bold"></span></div><span style="font-size:11px;line-height:15.925px;color:rgb(0,164,183);font-weight:bold">t: </span><span style="font-size:11px;line-height:15.925px">+44 (0)117 280 5120</span><br></div><div style="font-weight:400;color:rgb(97,97,97)"><font color="#00a4b7"><span style="font-size:11px;line-height:15.925px"><br></span></font><div style="color:rgb(51,51,51);line-height:1.4"><span style="font-size:0.75em">Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). </span><span style="font-size:10.5px">Moneyhub</span><span style="font-size:0.75em"> Financial Technology is entered on the Financial Services Register </span><span style="font-size:0.75em;background-color:transparent">(FRN </span><span style="font-size:0.75em;background-color:transparent;color:rgb(0,164,183);font-weight:bold">561538</span><span style="font-size:0.75em;background-color:transparent">) at <a href="http://fca.org.uk/register" target="_blank">fca.org.uk/register</a>. </span><span style="font-size:10.5px">Moneyh<wbr>ub</span><span style="font-size:0.75em;background-color:transparent"> Financial Technology is registered in England & Wales, company registration number </span><span style="font-size:0.75em;color:rgb(0,164,183);font-weight:bold;background-color:transparent">06909772</span><span style="font-size:0.75em;background-color:transparent"> </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:transparent"><font size="1">©</font></span><span style="font-size:0.75em;background-color:transparent"> . </span><span style="font-size:10.5px">Moneyhub</span><span style="background-color:transparent;font-size:0.75em"> <wbr>Financial Technology Limited 2018. </span><span style="background-color:transparent;font-size:0.75em;color:rgb(136,136,136)">DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Momentum Financial Technology Limited or of any other group company.</span></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</font></span><br>______________________________<wbr>_________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net">Openid-specs-fapi@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>fapi</a><br>
<br></blockquote></div><br></div>