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

From: Justin Richer <[email-masked]>
Date: Wed, 23 Jul 2014 22:02:13 -0400

But... this proposal issues id_tokens. Is this proposal stupid for doing so, or does Microsoft not actually implement it as written?

Also, I can't find any mention of this in your docs. Can you point us to it?

And doesn't Microsoft implement OpenID Connect already? You guys joined the OIDC interop with your implementation after all. If you're doing both, great, all the more reason to do this work in OIDF.

--Justin

/sent from my phone/

On Jul 23, 2014 9:55 PM, Anthony Nadalin <[email-masked]> wrote:
>
> I already indicated that Microsoft has implemented this and is in production, as id_tokens are stupid on intersystem and partner collaboration sites 
>
> -----Original Message----- 
> From: Justin Richer [mailto:[email-masked]] 
> Sent: Wednesday, July 23, 2014 6:52 PM 
> To: Anthony Nadalin 
> Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt 
>
> And which IdP is that? Can you point us to the implementation? 
>
> --Justin 
>
> /sent from my phone/ 
>
> On Jul 23, 2014 9:43 PM, Anthony Nadalin <[email-masked]> wrote: 
> > 
> > >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 
> > 
> >   
> > 
> > Folks are already working on this and it does not take a anything from 
> > OAuth to make it work, OAuth Tokens can be used and there is not a 
> > need for OAuth POP Tokens. A4C is already in use on one of the largest 
> > IdPs, but I don’t think you would understand how useful it is 
> > 
> >   
> > 
> > From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley 
> > Sent: Wednesday, July 23, 2014 1:54 PM 
> > To: [email-masked] 
> > Cc: [email-masked] list 
> > Subject: Re: [OAUTH-WG] New Version Notification for 
> > draft-hunt-oauth-v2-user-a4c-05.txt 
> > 
> >   
> > 
> > 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, [email-masked] 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 <[email-masked]> 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 <[email-masked]>: 
> >>>>> 
> >>>>> 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" <[email-masked]> 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 <[email-masked]>: 
> >>>>>>> 
> >>>>>>> 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" <[email-masked]> 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 <[email-masked]>: 
> >>>>>>>>> 
> >>>>>>>>> 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:[email-masked]] On Behalf Of John 
> >>>>>>>>> Bradley 
> >>>>>>>>> Sent: Wednesday, July 23, 2014 10:33 AM 
> >>>>>>>>> To: [email-masked] 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> Cc: [email-masked] 
> >>>>>>>>> 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, [email-masked] 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 <[email-masked]>: 
> >>>>>>>>>>> 
> >>>>>>>>>>> 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. <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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:[email-masked]] On Behalf Of 
> >>>>>>>>>>> Phil Hunt 
> >>>>>>>>>>> Sent: Wednesday, July 23, 2014 7:09 AM 
> >>>>>>>>>>> To: Nat Sakimura 
> >>>>>>>>>>> Cc: <[email-masked]> 
> >>>>>>>>>>> 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 
> >>>>>>>>>>> 
> >>>>>>>>>>> [email-masked] 
> >>>>>>>>>>> 
> >>>>>>>>>>>   
> >>>>>>>>>>> 
> >>>>>>>>>>>   
> >>>>>>>>>>> 
> >>>>>>>>>>>   
> >>>>>>>>>>> 
> >>>>>>>>>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura <[email-masked]> 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 <[email-masked]>: 
> >>>>>>>>>>> 
> >>>>>>>>>>> The draft is very clear. 
> >>>>>>>>>>> 
> >>>>>>>>>>> Phil 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> On Jul 23, 2014, at 0:46, Nat Sakimura <[email-masked]> wrote: 
> >>>>>>>>>>>> 
> >>>>>>>>>>>> The new grant type that I was talking about was 
> >>>>>>>>>>>> 
> >>>>>>>>>>>> "authorization_code_but_do_not_return_access_nor_refresh_to 
> >>>>>>>>>>>> ken", 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 <[email-masked]>: 
> >>>>>>>>>>>> 
> >>>>>>>>>>>> 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 <[email-masked]> wrote: 
> >>>>>>>>>>>> > 
> >>>>>>>>>>>> > What about just defining a new grant type in this WG? 
> >>>>>>>>>>>> > 
> >>>>>>>>>>>> > 
> >>>>>>>>>>>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt <[email-masked]>: 
> >>>>>>>>>>>> >> 
> >>>>>>>>>>>> >> 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 <[email-masked]> wrote: 
> >>>>>>>>>>>> >> 
> >>>>>>>>>>>> >>> +1 to Justin. 
> >>>>>>>>>>>> >>> 
> >>>>>>>>>>>> >>> 
> >>>>>>>>>>>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <[email-masked]>: 
> >>>>>>>>>>>> >>>> 
> >>>>>>>>>>>> >>>> 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 <[email-masked]> wrote: 
> >>>>>>>>>>>> >>>> 
> >>>>>>>>>>>> >>>>> 
> >>>>>>>>>>>> >>>>> 
> >>>>>>>>>>>> >>>>> 
> >>>>>>>>>>>> >>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <[email-masked]> 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/ 
> >>>>>>>>>>>> >>>>> _______________________________________________ 
> >>>>>>>>>>>> >>>>> OAuth mailing list 
> >>>>>>>>>>>> >>>>> [email-masked] 
> >>>>>>>>>>>> >>>>> https://www.ietf.org/mailman/listinfo/oauth 
> >>>>>>>>>>>> >>>> 
> >>>>>>>>>>>> >>>> 
> >>>>>>>>>>>> >>>> 
> >>>>>>>>>>>> >>>> _______________________________________________ 
> >>>>>>>>>>>> >>>> OAuth mailing list 
> >>>>>>>>>>>> >>>> [email-masked] 
> >>>>>>>>>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth 
> >>>>>>>>>>>> >>>> 
> >>>>>>>>>>>> >>> 
> >>>>>>>>>>>> >>> 
> >>>>>>>>>>>> >>> 
> >>>>>>>>>>>> >>> -- 
> >>>>>>>>>>>> >>> Nat Sakimura (=nat) 
> >>>>>>>>>>>> >>> Chairman, OpenID Foundation http://nat.sakimura.org/ 
> >>>>>>>>>>>> >>> @_nat_en 
> >>>>>>>>>>>> >>> 
> >>>>>>>>>>>> >>> _______________________________________________ 
> >>>>>>>>>>>> >>> OAuth mailing list 
> >>>>>>>>>>>> >>> [email-masked] 
> >>>>>>>>>>>> >>> 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 
> >>>>>>>>>>> [email-masked] 
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>>   
> >>>>>>>>>>> 
> >>>>>>>>>>> -- 
> >>>>>>>>>>> Thomas Broyer 
> >>>>>>>>>>> /tɔ.ma.bʁwa.je/ 
> >>>>>>>>>>> 
> >>>>>>>>>>> _______________________________________________ 
> >>>>>>>>>>> OAuth mailing list 
> >>>>>>>>>>> [email-masked] 
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>>   
> >>>>>>>>>>> 
> >>>>>>>>>>> -- 
> >>>>>>>>>>> Thomas Broyer 
> >>>>>>>>>>> /tɔ.ma.bʁwa.je/ 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> _______________________________________________ 
> >>>>>>>>>>> OAuth mailing list 
> >>>>>>>>>>> [email-masked] 
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>>   
> >>>>>>>>>>> 
> >>>>>>>>>>> -- 
> >>>>>>>>>>> Nat Sakimura (=nat) 
> >>>>>>>>>>> 
> >>>>>>>>>>> Chairman, OpenID Foundation 
> >>>>>>>>>>> http://nat.sakimura.org/ 
> >>>>>>>>>>> @_nat_en 
> >>>>>>>>>>> 
> >>>>>>>>>>>   
> >>>>>>>>>>> 
> >>>>>>>>>>> _______________________________________________ 
> >>>>>>>>>>> 
> >>>>>>>>>>> OAuth mailing list 
> >>>>>>>>>>> 
> >>>>>>>>>>> [email-masked] 
> >>>>>>>>>>> 
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth 
> >>>>>>>>>> 
> >>>>>>>>>>   
> >>>>>>>>>> 
> >>>>>>>>>>   
> >>>>>>>>>> 
> >>>>>>>>>> _______________________________________________ 
> >>>>>>>>>> OAuth mailing list 
> >>>>>>>>>> [email-masked] 
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> _______________________________________________ 
> >>>>>>>>> OAuth mailing list 
> >>>>>>>>> [email-masked] 
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth 
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>>   
> >>>>>>>> 
> >>>>>>>> -- 
> >>>>>>>> Nat Sakimura (=nat) 
> >>>>>>>> 
> >>>>>>>> Chairman, OpenID Foundation 
> >>>>>>>> http://nat.sakimura.org/ 
> >>>>>>>> @_nat_en 
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> _______________________________________________ 
> >>>>>>>> OAuth mailing list 
> >>>>>>>> [email-masked] 
> >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth 
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>>   
> >>>>>> 
> >>>>>> -- 
> >>>>>> Nat Sakimura (=nat) 
> >>>>>> 
> >>>>>> Chairman, OpenID Foundation 
> >>>>>> http://nat.sakimura.org/ 
> >>>>>> @_nat_en 
> >>>>> 
> >>>>> _______________________________________________ 
> >>>>> OAuth mailing list 
> >>>>> [email-masked] 
> >>>>> https://www.ietf.org/mailman/listinfo/oauth 
> >>>> 
> >>>> _______________________________________________ 
> >>>> OAuth mailing list 
> >>>> [email-masked] 
> >>>> https://www.ietf.org/mailman/listinfo/oauth 
> >> 
> >>   
> >> 
> >>

---

From: Justin Richer <[email-masked]>
Date: Thu, 24 Jul 2014 13:18:17 -0400

We do the same thing with well-known (ie, whitelisted) client apps for both OIDC and vanilla OAuth. These are cases where the consent decision isn't in the users' hands, so we don't ask them. But here's the thing: that's an implementation detail of our AS policy, the clients are all just doing OAuth so the developers don't notice, and the users (for the most part) don't even realize they're going through an OAuth flow. Coupled with SSO, things "just work" for these cases, for both users and developers.

And I would further argue that if it's an unknown or untrusted client, I *want* user consent, even for just authentication. TOFU works great here.

--Justin

/sent from my phone/

On Jul 24, 2014 11:33 AM, [email-masked] wrote:
>
> I honestely don't understand why you care about omiting the access token on the token endpoint response. You want to omit user consent? Fine, do it. There is no text in the spec that forces an AS to explicitely acquire user consent. Authorization from the resource owner can be acquired in many ways, showing an user consent page is just one option. We authorize DT internal services using a pre-configured policy. So the customer will never (need to) see a consent screen. The same approach can be used in enterprise deployments. 
>
> regards,
> Torsten.
>
> Am 24.07.2014 10:49, schrieb Mike Jones:
>>
>> Here's a point of technical discussion for your consideration about the current content of a4c and a possible simplification.
>>
>>  
>>
>> Having thought about the views expressed about defining the new response type and grant type values, I came up with a possible syntax change that would be much more minimal and accomplish the same thing.  Rather than defining a new response type and a new grant type, instead, we could just use the existing code flow and say that it's legal for the token endpoint to return the value "access_token=none".  That way, the delta to OAuth 2.0 for the no-access-token case would be very small and the syntax of the response from the token endpoint would be unchanged.
>>
>>  
>>
>> And while people might initially think that since we'd be defining a distinguished access_token result value we might be stepping on implementations, "none" doesn't meet the minimum entropy requirements in OAuth 2.0, so wouldn't conflict with any conforming implementation.
>>
>>  
>>
>>                                                             Best wishes,
>>
>>                                                             -- Mike
>>
>>  
>>
>> From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
>> Sent: Thursday, July 24, 2014 7:34 AM
>> To: John Bradley
>> Cc: [email-masked] list
>> +1
>> On Jul 24, 2014, at 10:25 AM, John Bradley <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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 <[email-masked]>:
>>>
>>>  
>>>
>>>>> 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
>>>>>
>>>>>
>>>>>>> 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. 
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>>> 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 
>>>>>>>>
>>>>>>>> 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. 
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>> 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. 
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>>>> 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 
>>>>>>>>>>
>>>>>>>>>>  
>>>>>>>>>>
>>>>>>>>>> From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
>>>>>>>>>> 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
>>>>>>>>>> Also, I take back my statement on the grant type in my previous mail. 
>>>>>>>>>>
>>>>>>>>>>  
>>>>>>>>>>
>>>>>>>>>>     (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
>>>>>>>>>>
>>>>>>>>>>     
>>>>>>>>>>
>>>>>>>>>>  
>>>>>>>>>>
>>>>>>>>>>  
>>>>>>>>>>
>>>>>>>>>>  
>>>>>>>>>>
>>>>>>>>>>> "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, 
>>>>>>>>>>>
>>>>>>>>>>> At the same time, if any other specification wanted to define 
>>>>>>>>>>>
>>>>>>>>>>> other type of tokens and have it returned from the token endpoint, 
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>  
>>>>>>>>>>>
>>>>>>>>>>> >> That would be nice. However oidc still needs the new grant type in order to implement the same flow. 
>>>>>>>>>>> >>
>>>>>>>>>>> >> Phil
>>>>>>>>>>> >>
>>>>>>>>>>> >>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come back ;-) )
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> --
>>>>>>>>>>> >>>>> Thomas Broyer
>>>>>>>>>>> >>>>> /tɔ.ma.bʁwa.je/