Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[[e-mail]]

 

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 <[e-mail]>:
> 
> 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. <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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:[e-mail]] ON BEHALF OF Phil Hunt
> SENT: Wednesday, July 23, 2014 7:09 AM
> TO: Nat Sakimura
> CC: <[e-mail]>
> 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] 
> 
> [e-mail] 
> 
> On Jul 23, 2014, at 9:43 AM, Nat Sakimura <[e-mail]> 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 <[e-mail]>: 
> 
> The draft is very clear. 
> 
> Phil 
> 
> On Jul 23, 2014, at 0:46, Nat Sakimura <[e-mail]> 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 <[e-mail]>: 
> 
> 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 <[e-mail]> wrote:
>>
>> What about just defining a new grant type in this WG?
>>
>>
>> 2014-07-22 12:56 GMT-04:00 Phil Hunt <[e-mail]>:
>>>
>>> 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 <[e-mail]> wrote:
>>>
>>>> +1 to Justin. 
>>>>
>>>>
>>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <[e-mail]>:
>>>>>
>>>>> 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 <[e-mail]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <[e-mail]> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth [5]
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth [5]
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/ [6]
>>>> @_nat_en
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth [5]

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

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

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

_______________________________________________
OAuth mailing list
[e-mail]
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/