The situations are rather different.
On Thu, Jul 24, 2014 at 11:25 AM, Anthony Nadalin <tony...@microsoft.com> wrote: > OMG, how can you say that when the Dynamkc Reg does the same thing > (duplicates) but that is OK to do > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian > Campbell > *Sent:* Thursday, July 24, 2014 10:22 AM > > *To:* John Bradley > *Cc:* oauth@ietf.org list > *Subject:* Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > > > I'm sorry to miss what will likely be a very engaging meeting today. > > The premise that some developers are using OAuth in a insecure way to do > authentication is something we can probably all agree on. > > It doesn't necessarily follow from that premise, however, that the > solution is yet another spec which either duplicates some subset of OpenID > Connect (in a different SDO) or forks how to do SSO/authentication using > OAuth. > > > > On Thu, Jul 24, 2014 at 7:25 AM, John Bradley <ve7...@ve7jtb.com> wrote: > > I am not against discussion in the WG. > > > > I happen to agree with Phil's fundamental premise that some developers are > using OAuth in a insecure way to do authentication. > > > > That raises the question of how to best educate them, and or address > technical barriers. > > > > It is on the second point that people's opinions seem to divide. > > > > Some people thing that if we have a OAuth flow that eliminates the access > token (primarily to avoid asking for consent as I understand it) and just > return a id_token from the token endpoint that can be done in a spec short > enough to het people to read. The subtext of this is that the Connect > specification is too large that it scare people, and they don't find the > spec in the first place because it is not a RFC. > > > > An other common possession is that if you don't want to prompt the user > for consent then don't ask for scopes. Twisting the OAuth spec to not > return an access token is not OAuth, yes you could use a different > endpoint rather than the token endpoint, but that is not OAuth. Connect > was careful not to break the OAuth spec. As long as you are willing to > take a access token with no scopes (the client needs to understand that > there are no attributes one way or another anyway or it will break) then > you don't need to change OAuth. You can publish a profile of connect that > satisfies the use case. > > > > I think Mike has largely done that but it might be better being less > stingy on references back to the larger spec. > > > > The questions are do we modify OAuth to not return an access token, and if > so how, and if we do is it still OAuth. > > > > The other largely separable question is do we create confusion in the > market and slow the the adoption of identity federation on top of OAuth, or > find a way to make this look like a positive alignment of interests around > a subset of Connect. > > > > There are a number of options. > > 1: We can do a profile in the OIDF and publish it as a IETF document. > Perhaps the cleanest from an IPR point of view. > > 2:We can do a profile in the OAuth WG referencing connect. > > 3:We can do a AD sponsored profile that is not in the OAuth WG. > > 4:We can do a small spec in OAuth to add response_type to the token > endpoint. in combination with 1, 2, or 3 > > > > I agree that stoping developers doing insecure things needs to be > addressed somehow. > > I am not personally convinced that Oauth without access tokens is sensible. > > > > Looking forward to the meeting:) > > > > John B. > > > > On Jul 24, 2014, at 6:52 AM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > > > I'd note that the reaction at the conference to Ian's statement was > overwhelmingly positive. There was a wide range of industry people here - > implementers, practitioners, deployers, strategists, etc. - and it seems > pretty clear that the "rough consensus" of the industry at large is that > a4c is not wanted or needed. > > > > On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <sakim...@gmail.com> wrote: > > 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 > > > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
