<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">If the AS has no mechanism to remember grants for clients, then it needs to return a interaction required error if it receives prompt=none.<div class=""><br class=""></div><div class="">John B.<br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 1:22 PM, Takahiko Kawasaki <<a href="mailto:daru.tk@gmail.com" class="">daru.tk@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Dear Torsten, John, Justin,<br class=""><br class="">Thank you very much for your valuable comments. It seems there is an undocumented but shared assumption that prompt=none expects authorization servers have a mechanism to remember previous grants and reuse them. I now think that if an AS implementation does not have such a mechanism, it should avoid issuing tokens (authorization codes, access tokens and ID tokens) when an authorization request comes with prompt=none.<br class=""><br class="">Best Regards,<br class="">Takahiko Kawasaki<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-01-03 5:56 GMT+09:00 Justin Richer <span dir="ltr" class=""><<a href="mailto:jricher@mit.edu" target="_blank" class="">jricher@mit.edu</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">John, you’re technically correct that it’s “OAuth not OIDC” but you’re ignoring the fact that most OIDC implementations are built upon standalone OAuth systems which continue to offer basic OAuth functionality as well. In our implementation at least, the processing of the “prompt” parameter is handled the same way for all requests regardless of whether or not the “openid” scope was used. I doubt our method of processing these parameters is uncommon.<br class="">
<br class="">
But this still isn’t a security problem. What “prompt=none” means is that the AS can only say “yes” or “you need to ask the user”. The cases where it can say “yes” are limited to those where the user would not have been prompted anyway. Namely, the user already has authorized the client for the scopes being requested, or the client is whitelisted, or some other consideration like that. If there’s anything that would cause user interaction, including a login, then the response returns with “you need to go ask the user”. This is fine for both OIDC and OAuth transactions.<br class="">
<br class="">
What wouldn’t be fine is if the server needed to display something to the user, even a notification, in the normal case but it turned off that functionality for the “prompt=none” request. That’s not what’s being asked for in the protocol, though.<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
— Justin<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
<br class="">
> On Jan 1, 2016, at 2:02 PM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" class="">ve7jtb@ve7jtb.com</a>> wrote:<br class="">
><br class="">
> If the request doesn’t contain the openid scope then it is not OpenID Connect, it is just OAuth.<br class="">
><br class="">
> So there is no case where a client could do connect and not request any scopes.<br class="">
><br class="">
> Many sites remember authorization grants the user has consented to for a particular site, and don’t re-prompt the user for consent each time.<br class="">
><br class="">
> If a request with prompt=none arrives and the client is asking for scopes that the user previously consented to including checking remember this in the UI, then<br class="">
> a code with those grants can be returned.<br class="">
><br class="">
> In the case of OAuth asking for no scopes then the server would generate an error unless it is configured with some default scope.<br class="">
><br class="">
> I guess you could generate code and AT with no scopes attached but that would be sort of strange.<br class="">
><br class="">
> John B.<br class="">
><br class="">
><br class="">
><br class="">
>> On Jan 1, 2016, at 12:09 PM, Takahiko Kawasaki <<a href="mailto:daru.tk@gmail.com" class="">daru.tk@gmail.com</a>> wrote:<br class="">
>><br class="">
>> Dear All,<br class="">
>><br class="">
>> I have a question about prompt=none which is defined in "OpenID Connect Core 1.0, 3.1.2.1. Authentication Request".<br class="">
>><br class="">
>> The description in the specification says as follows:<br class="">
>><br class="">
>> The Authorization Server MUST NOT display any authentication or<br class="">
>> consent user interface pages. An error is returned if an End-User<br class="">
>> is not already authenticated or the Client does not have pre-<br class="">
>> configured consent for the requested Claims or does not fulfill<br class="">
>> other conditions for processing the request. The error code will<br class="">
>> typically be login_required, interaction_required, or another<br class="">
>> code defined in Section 3.1.2.6. This can be used as a method to<br class="">
>> check for existing authentication and/or consent.<br class="">
>><br class="">
>> If an End-User is already authenticated and the Client does not request any claim (e.g. does not request an ID token), is it allowed to issue an authorization code and/or an access token? For example, if a request comes with prompt=none and response_type=code (and other necessary parameters), is it allowed to issue an authorization code without any interaction with the End-User? Doesn't this cause a security issue? What happens if an End-User who has already logged in a certain SNS and he loads a malicious HTML that makes a request to the SNS with prompt=none and response_type=code behind the scenes without letting him know the request?<br class="">
>><br class="">
>> What use case justifies prompt=none? It is difficult for my poor imagination to make up a secure use case of prompt=none (except the case of response_type=none) unless there are undocumented conditions (e.g. an out-of-band consent prior to a request). What were discussed in WG about prompt=none?<br class="">
>><br class="">
>> If an implementation of authorization server does not provide any means for End-Users to set "pre-configured consent" (3.1.2.1. Authentication Request) for claims and does not provide other out-of-band consent for issuing authorization codes and access tokens, I guess that the implementation cannot help but reject any request with prompt=none unless it comes with response_type=none. What do you think?<br class="">
>><br class="">
>><br class="">
>> Best Regards,<br class="">
>> Takahiko Kawasaki<br class="">
>> _______________________________________________<br class="">
>> Openid-specs-ab mailing list<br class="">
>> <a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br class="">
><br class="">
> _______________________________________________<br class="">
> Openid-specs-ab mailing list<br class="">
> <a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br class="">
<br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></blockquote></div><br class=""></div></div></body></html>