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 <ve7...@ve7jtb.com>: > 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, tors...@lodderstedt.net 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 <tors...@lodderstedt.net> > 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 <t.bro...@gmail.com>: > > 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" <sakim...@gmail.com> 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 <t.bro...@gmail.com>: >> >>> 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" <sakim...@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.jo...@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-boun...@ietf.org] *On Behalf Of *John >>>>> Bradley >>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM >>>>> *To:* tors...@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, tors...@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.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. >>>>> 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 >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> 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/ <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 >>>> >>>> >> >> >> -- >> 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
