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

[Nat Sakimura <[e-mail]>]

And here is a quote from Ian's blog.

And although the authentication wheel is round, that doesn’t mean it isn’t
> without its lumps. First, we do see some reinventing the wheel just to
> reinvent the wheel. OAuth A4C is simply not a fruitful activity and should
> be put down.



> (Source)
> http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html



2014-07-23 16:53 GMT-04:00 John Bradley <[e-mail]>:

> I thought I did post this to the list.
>
> I guess I hit the wrong reply on my phone.
>
> John B.
> Sent from my iPhone
>
> On Jul 23, 2014, at 4:50 PM, [e-mail] wrote:
>
> we are two, at least :-)
>
> Why didn't you post this on the list?
>
> When will be be arriving?
>
> Am 23.07.2014 16:39, schrieb John Bradley:
>
> Ian Glazer mentioned this in his keynote at CIS yesterday.
>
> His advice was please stop,  we are creating confusion and uncertainty.
>
> We are becoming our own wort enemy. ( my view though Ian may share it)
>
> Returning just an id_ token from the token endpoint has little real value.
>
> Something really useful to do would be sorting out channel_id so we can do
> PoP for id tokens to make them and other cookies secure in the front
> channel.   I think that is a better use of time.
>
> I may be in the minority opinion on that,  it won't be the first time.
>
>
> John B.
> Sent from my iPhone
>
> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <[e-mail]>
> wrote:
>
>  You are right from a theoretical perspective. Practically this was
> caused by editorial decisions during the creation of the RFC. As far as I
> remember, there was a definition of the (one) token endpoint response in
> early versions. No one every considered to NOT respond with an access token
> from the token endpoint. So one might call it an implicit assumption.
>
> I'm worried that people get totally confused if an exception is introduced
> now given the broad adoption of OAuth based on this assumption.
>
> regards,
> Torsten.
>
> Am 23.07.2014 um 15:41 schrieb Thomas Broyer <[e-mail]>:
>
>  Is it said anywhere that ALL grant types MUST use Section 5.1 responses?
> Each grant type references Section 5.1, and "access token request" is only
> defined in the context of the defined grant types. Section 2.2 doesn't talk
> about the request or response format.
> Le 23 juil. 2014 21:32, "Nat Sakimura" <[e-mail]> a écrit :
>
>> 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
>>
>   _______________________________________________
> 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