Speaking for myself, yes. Defining the simple ID_token grant showing how an ID token only can be returned is my minimum objective.
I think there needs to be some discussion in the WG on certain features which may be better suited only within OIDC and those features which fit better as a foundational piece in IETF OAuth WG. Phil @independentid www.independentid.com phil.h...@oracle.com On Jul 22, 2014, at 1:29 PM, 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
