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