<div dir="ltr">FAPI pt 2 is hard to decipher, but it appears to require OpenID Connect, which requires openid scope. That said it also says:<div><br></div><div>"

<span style="color:rgb(0,0,0);font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">While the name ID Token suggests that it is something that provides the identity of the resource owner (subject), it is not necessarily so. While it does identify the authorization server by including the issuer identifier, it is perfectly fine to have ephemeral subject identifier. In this case, the ID Token acts as a detached signature of the issuer to the authorization response and it was an explicit design decision of OpenID Connect Core to make the ID Token act as a detached signature.</span>

"</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 4:52 AM, Torsten Lodderstedt 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">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>
Torsten. <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>