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
