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/ >> >>>>> _______________________________________________ >> >>>>> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
