The "response type" of the token endpoint is controlled by the value of
the parameter "grant_type". So there is no need to introduce a new
parameter. 

wrt to a potential "no_access_token" grant type. I do not consider this
a good idea as it changes the semantics of the token endpoint (as
already pointed out by Thomas). This endpoint ALWAYS responds with an
access token to any grant type. I therefore would prefer to use another
endpoint for the intended purpose. 

regards,
Torsten. 

Am 23.07.2014 13:04, schrieb Nat Sakimura: 

> IMHO, changing the semantics of "response_type" @ authz endpoint this way is 
> not a good thing. 
> Instead, defining a new parameter "response_type" @ token endpoint, as I 
> described in my previous message, 
> probably is better. At least, it does not change the semantics of the 
> parameters of RFC6749. 
> 
> Nat 
> 
> 2014-07-23 12:48 GMT-04:00 Thomas Broyer <t.bro...@gmail.com>:
> 
> No, I mean response_type=none and response_type=id_token don't generate a 
> code or access token so you don't use the Token Endpoint (which is not the 
> same as the Authentication Endpoint BTW). 
> With response_type=code_for_id_token, you get a code and exchange it for an 
> id_token only, rather than an access_token, so you're changing the semantics 
> of the Token Endpoint. 
> 
> I'm not saying it's a bad thing, just that you can't really compare none and 
> id_token with code_for_id_token. 
> 
> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. <jric...@mitre.org> wrote:
> 
> It's only "not using the token endpoint" because the token endpoint 
> copy-pasted and renamed the authentication endpoint. 
> 
> -- Justin 
> 
> On Jul 23, 2014, at 9:30 AM, Thomas Broyer <t.bro...@gmail.com> wrote: 
> 
> Except that these are about not using the Token Endpoint at all, whereas the 
> current proposal is about the Token Endpoint not returning an access_token 
> field in the JSON. 
> 
> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <michael.jo...@microsoft.com> 
> wrote:
> 
> The response_type "none" is already used in practice, which returns no access 
> token. It was accepted by the designated experts and registered in the IANA 
> OAuth Authorization Endpoint Response Types registry at 
> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint
>  [1]. The registered "id_token" response type also returns no access token. 
> 
> So I think the question of whether response types that result in no access 
> token being returned are acceptable within OAuth 2.0 is already settled, as a 
> practical matter. Lots of OAuth implementations are already using such 
> response types. 
> 
> -- Mike 
> 
> FROM: OAuth [mailto:oauth-boun...@ietf.org] ON BEHALF OF Phil Hunt
> SENT: Wednesday, July 23, 2014 7:09 AM
> TO: Nat Sakimura
> CC: <oauth@ietf.org>
> SUBJECT: Re: [OAUTH-WG] New Version Notification for 
> draft-hunt-oauth-v2-user-a4c-05.txt 
> 
> Yes. This is why it has to be discussed in the IETF. 
> 
> Phil 
> 
> @independentid 
> 
> www.independentid.com [2] 
> 
> phil.h...@oracle.com 
> 
> On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakim...@gmail.com> wrote: 
> 
> Reading back the RFC6749, I am not sure if there is a good way of suppressing 
> access token from the response and still be OAuth. It will break whole bunch 
> of implicit definitions like: 
> 
> authorization server
> The server issuing access tokens to the client after successfully
> authenticating the resource owner and obtaining authorization. 
> 
> After all, OAuth is all about issuing access tokens. 
> 
> Also, I take back my statement on the grant type in my previous mail. 
> 
> The definition of grant and grant_type are respectively: 
> 
> grant 
> 
> credential representing the resource owner's authorization 
> 
> grant_type 
> 
> (string representing the) type of grant sent to the token endpoint to obtain 
> the access token 
> 
> Thus, the grant sent to the token endpoint in this case is still 'code'. 
> 
> Response type on the other hand is not so well defined in RFC6749, but it 
> seems it is representing what is to be returned from the authorization 
> endpoint. To express what is to be returned from token endpoint, perhaps 
> defining a new parameter to the token endpoint, which is a parallel to the 
> response_type to the Authorization Endpoint seems to be a more symmetric way, 
> though I am not sure at all if that is going to be OAuth any more. One 
> straw-man is to define a new parameter called response_type to the token 
> endpoint such as: 
> 
> response_type 
> 
> OPTIONAL. A string representing what is to be returned from the token 
> endpoint. 
> 
> Then define the behavior of the endpoint according to the values as the 
> parallel to the multi-response type spec. 
> 
> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html [3] 
> 
> Nat 
> 
> 2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.h...@oracle.com>: 
> 
> The draft is very clear. 
> 
> Phil 
> 
> On Jul 23, 2014, at 0:46, Nat Sakimura <sakim...@gmail.com> wrote: 
> 
> The new grant type that I was talking about was 
> 
> "authorization_code_but_do_not_return_access_nor_refresh_token", so to speak. 
> 
> It does not return anything per se, but an extension can define something on 
> top of it. 
> 
> Then, OIDC can define a binding to it so that the binding only returns ID 
> Token. 
> 
> This binding work should be done in OIDF. Should there be such a grant type, 
> 
> it will be an extremely short spec. 
> 
> At the same time, if any other specification wanted to define 
> 
> other type of tokens and have it returned from the token endpoint, 
> 
> it can also use this grant type. 
> 
> If what you want is to define a new grant type that returns ID Token only, 
> 
> then, I am with Justin. Since "other response than ID Token" is only 
> 
> theoretical, this is a more plausible way forward, I suppose. 
> 
> Nat 
> 
> 2014-07-22 14:30 GMT-04:00 Justin Richer <jric...@mit.edu>: 
> 
> So the draft would literally turn into:
> 
> "The a4c response type and grant type return an id_token from the token 
> endpoint with no access token. All parameters and values are defined in OIDC."
> 
> Seems like the perfect mini extension draft for OIDF to do.
> 
> --Justin
> 
> /sent from my phone/ 
> 
> On Jul 22, 2014 10:29 AM, Nat Sakimura <sakim...@gmail.com> wrote:
>>
>> What about just defining a new grant type in this WG?
>>
>>
>> 2014-07-22 12:56 GMT-04:00 Phil Hunt <phil.h...@oracle.com>:
>>>
>>> That would be nice. However oidc still needs the new grant type in order to 
>>> implement the same flow. 
>>>
>>> Phil
>>>
>>> On Jul 22, 2014, at 11:35, Nat Sakimura <sakim...@gmail.com> wrote:
>>>
>>>> +1 to Justin. 
>>>>
>>>>
>>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jric...@mitre.org>:
>>>>>
>>>>> Errors like these make it clear to me that it would make much more sense 
>>>>> to develop this document in the OpenID Foundation. It should be something 
>>>>> that directly references OpenID Connect Core for all of these terms 
>>>>> instead of redefining them. It's doing authentication, which is 
>>>>> fundamentally what OpenID Connect does on top of OAuth, and I don't see a 
>>>>> good argument for doing this work in this working group.
>>>>>
>>>>> -- Justin
>>>>>
>>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <t.bro...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones 
>>>>>> <michael.jo...@microsoft.com> wrote:
>>>>>>>
>>>>>>> Thanks for your review, Thomas. The "prompt=consent" definition being 
>>>>>>> missing is an editorial error. It should be:
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> consent
>>>>>>>
>>>>>>> The Authorization Server SHOULD prompt the End-User for consent before 
>>>>>>> returning information to the Client. If it cannot obtain consent, it 
>>>>>>> MUST return an error, typically consent_required.
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> I'll plan to add it in the next draft.
>>>>>>
>>>>>>
>>>>>> It looks like the consent_required error needs to be defined too, and 
>>>>>> you might have forgotten to also import account_selection_required from 
>>>>>> OpenID Connect.
>>>>>> 
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> I agree that there's no difference between a response with multiple 
>>>>>>> "amr" values that includes "mfa" and one that doesn't. Unless a clear 
>>>>>>> use case for why "mfa" is needed can be identified, we can delete it in 
>>>>>>> the next draft.
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> How about "pwd" then? I fully understand that I should return "pwd" if 
>>>>>> the user authenticated using a password, but what "the service if a 
>>>>>> client secret is used" means in the definition for the "pwd" value?
>>>>>>
>>>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come back 
>>>>>> ;-) )
>>>>>>
>>>>>> --
>>>>>> Thomas Broyer
>>>>>> /tɔ.ma.bʁwa.je/ [4]
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth [5]
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth [5]
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/ [6]
>>>> @_nat_en
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth [5]
>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/ [6]
>> @_nat_en 
> 
> -- 
> Nat Sakimura (=nat) 
> 
> Chairman, OpenID Foundation
> http://nat.sakimura.org/ [6]
> @_nat_en 
> 
> -- 
> Nat Sakimura (=nat) 
> 
> Chairman, OpenID Foundation
> http://nat.sakimura.org/ [6]
> @_nat_en 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth [5]

 -- 
 Thomas Broyer
 /tɔ.ma.bʁwa.je/ [4] _______________________________________________
 OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth [5] 

 -- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ [4] 
_______________________________________________
 OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth [5]

 -- 
Nat Sakimura (=nat) 
Chairman, OpenID Foundation
http://nat.sakimura.org/ [6]
@_nat_en 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth [5]

 

Links:
------
[1]
http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint
[2] http://www.independentid.com/
[3] http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
[4] http://xn--nna.ma.xn--bwa-xxb.je/
[5] https://www.ietf.org/mailman/listinfo/oauth
[6] http://nat.sakimura.org/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to