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

I hadn't realized the JSON response that requires the access_token field is
defined per grant_type, so I'd be OK to "extend the semantics" as in the
current draft.
That was actually my main concern: that the token endpoint mandates
access_token; but its actually not the case.
Le 23 juil. 2014 20:46, "Nat Sakimura" <sakimura@gmail.com> a écrit :

> I agree with John that overloading response_type @ authz endpoint is a bad
> idea. It completely changes the semantics of this parameter. NOTE: what I
> was proposing was not this parameter, but a new parameter response_type @
> token endpoint.
>
> I also think overloading grant_type is a bad idea since it changes its
> semantics. I quote the definition here again:
>
> grant
>     credential representing the resource owner's authorization
>  grant_type
> type of grant sent to the token endpoint to obtain the access token
>
> It is not about controlling what is to be returned from the token
> endpoint, but the hint to the token endpoint describing the type of
> credential the endpoint has received. It seems the "control of what is
> being returned from token endpoint"  is just a side effect.
>
> I am somewhat ambivalent[1] in changing the semantics of token endpoint,
> but in as much as "text is the king" for a spec., we probably should not
> change the semantics of it as Torsten points out. If it is ok to change
> this semantics, I believe defining a new parameter to this endpoint to
> control the response would be the best way to go. This is what I have
> described previously.
>
> Defining a new endpoint to send code to get ID Token and forbidding the
> use of it against token endpoint would not change the semantics of any
> existing parameter or endpoint, which is good. However, I doubt if it is
> not worth doing. What's the point of avoiding access token scoped to
> UserInfo endpoint after all? Defining a new endpoint for just avoiding the
> access token for userinfo endpoint seems way too much the heavy wait way
> and it breaks interoperabiliy: it defeats the purpose of standardization.
>
> I have started feeling that no change is the best way out.
>
> Nat
>
> [1]  If instead of saying "Token endpoint - used by the client to
> exchange an authorization grant for an access token, typically with
> client authentication", it were saying "Token endpoint - used by the
> client to exchange an authorization grant for tokens, typically with
> client authentication", then it would have been OK. It is an expansion of
> the capability rather than changing the semantics.
>
>
>
> 2014-07-23 13:39 GMT-04:00 Mike Jones <Michael.Jones@microsoft.com>:
>
>>  You need the alternative response_type value (“code_for_id_token” in
>> the A4C draft) to tell the Authorization Server to return a code to be used
>> with the new grant type, rather than one to use with the
>> “authorization_code” grant type (which is what response_type=code does).
>>
>>
>>
>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley
>> *Sent:* Wednesday, July 23, 2014 10:33 AM
>> *To:* torsten@lodderstedt.net
>>
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>> draft-hunt-oauth-v2-user-a4c-05.txt
>>
>>
>>
>> If we use the token endpoint then a new grant_type is the best way.
>>
>>
>>
>> It sort of overloads code, but that is better than messing with
>> response_type for the authorization endpoint to change the response from
>> the token_endpoint.  That is in my opinion a champion bad idea.
>>
>>
>>
>> In discussions developing Connect we decided not to open this can of
>> worms because no good would come of it.
>>
>>
>>
>> The token_endpoint returns a access token.  Nothing requires scope to be
>> associates with the token.
>>
>>
>>
>> That is the best solution.  No change required.  Better interoperability
>> in my opinion.
>>
>>
>>
>> Still on my way to TO, getting in later today.
>>
>>
>>
>> John B.
>>
>>
>>
>>
>>
>> Sent from my iPhone
>>
>>
>> On Jul 23, 2014, at 12:15 PM, torsten@lodderstedt.net wrote:
>>
>>  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.broyer@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. <jricher@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.broyer@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.Jones@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.
>> 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-bounces@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
>>
>> phil.hunt@oracle.com
>>
>>
>>
>>
>>
>>
>>
>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura <sakimura@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
>>
>>
>>
>> Nat
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2014-07-23 7:21 GMT-04:00 Phil Hunt <phil.hunt@oracle.com>:
>>
>> The draft is very clear.
>>
>> Phil
>>
>>
>> On Jul 23, 2014, at 0:46, Nat Sakimura <sakimura@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 <jricher@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 <sakimura@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.hunt@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 <sakimura@gmail.com> wrote:
>> >>
>> >>> +1 to Justin.
>> >>>
>> >>>
>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <jricher@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.broyer@gmail.com>
>> wrote:
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <
>> Michael.Jones@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/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>> >>>>> _______________________________________________
>> >>>>> OAuth mailing list
>> >>>>> OAuth@ietf.org
>> >>>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> OAuth mailing list
>> >>>> OAuth@ietf.org
>> >>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Nat Sakimura (=nat)
>> >>> Chairman, OpenID Foundation
>> >>> http://nat.sakimura.org/
>> >>> @_nat_en
>> >>>
>> >>> _______________________________________________
>> >>> OAuth mailing list
>> >>> OAuth@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/oauth
>> >
>> >
>> >
>> >
>> > --
>> > Nat Sakimura (=nat)
>> > Chairman, OpenID Foundation
>> > http://nat.sakimura.org/
>> > @_nat_en
>>
>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>>
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>>
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>> --
>> Thomas Broyer
>> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>> --
>> Thomas Broyer
>> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>>
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> OAuth@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>>  _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>