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

[Nat Sakimura <[e-mail]>]

Is it? Apart from the implicit grant that does not use token endpoint, all
other grant references section 5.1 for the response, i.e., all shares the
same response.


2014-07-23 15:18 GMT-04:00 Thomas Broyer <[e-mail]>:

> 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" <[e-mail]> 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 <[e-mail]>:
>>
>>>  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:[e-mail]] *On Behalf Of *John
>>> Bradley
>>> *Sent:* Wednesday, July 23, 2014 10:33 AM
>>> *To:* [e-mail]
>>>
>>> *Cc:* [e-mail]
>>> *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, [e-mail] 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 <[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.
>>> 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
>>>
>>> [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
>>>
>>>
>>>
>>> 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/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>>> >>>>> _______________________________________________
>>> >>>>> OAuth mailing list
>>> >>>>> [e-mail]
>>> >>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> OAuth mailing list
>>> >>>> [e-mail]
>>> >>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Nat Sakimura (=nat)
>>> >>> Chairman, OpenID Foundation
>>> >>> http://nat.sakimura.org/
>>> >>> @_nat_en
>>> >>>
>>> >>> _______________________________________________
>>> >>> OAuth mailing list
>>> >>> [e-mail]
>>> >>> 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
>>> [e-mail]
>>> 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
>>> [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>>
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> OAuth mailing list
>>>
>>> [e-mail]
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>


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