Sorry for the delay here. >From the formal perspective, Torsten's language works for me as well. Thanks for taking the feedback into account.
I still worry that without an explicit reference to OIDC implicit+form_post, I will have the conversation "but can we still do this in OIDC now that implicit has been deprecated in OAuth?" countless times with customers, but I'm resigned to that anyway :) On Sat, Mar 7, 2020 at 3:36 PM Brian Campbell <bcampbell= 40pingidentity....@dmarc.ietf.org> wrote: > Sorry, was replying i. my phone on the weekend and trying to keep it > quick. I meant that I thought Torsten's suggestion was good. > > On Sat, Mar 7, 2020, 4:25 PM Dick Hardt <dick.ha...@gmail.com> wrote: > >> Would you clarify what text works Brian? >> >> On Sat, Mar 7, 2020 at 3:24 PM Brian Campbell <bcampb...@pingidentity.com> >> wrote: >> >>> Yeah, that works for me. >>> >>> On Sat, Mar 7, 2020, 9:37 AM Dick Hardt <dick.ha...@gmail.com> wrote: >>> >>>> Brian: does that meet your requirements? >>>> >>>> If not, how about if we refer to OIDC as an example extension without >>>> saying it is implicit? >>>> ᐧ >>>> >>>> On Sat, Mar 7, 2020 at 8:29 AM Torsten Lodderstedt < >>>> tors...@lodderstedt.net> wrote: >>>> >>>>> I think keeping the response type as extension point and not >>>>> mentioning implicit at all is sufficient to support Brian’s objective. >>>>> >>>>> Am 07.03.2020 um 17:06 schrieb Dick Hardt <dick.ha...@gmail.com>: >>>>> >>>>> >>>>> How about if we add in a nonnormative reference to OIDC as an explicit >>>>> example of an extension: >>>>> >>>>> "For example, OIDC defines an implicit grant with additional security >>>>> features." >>>>> >>>>> or similar language >>>>> ᐧ >>>>> >>>>> On Sat, Mar 7, 2020 at 5:27 AM Brian Campbell < >>>>> bcampb...@pingidentity.com> wrote: >>>>> >>>>>> The name implicit grant is unfortunately somewhat >>>>>> misleading/confusing but, for the case at hand, the extension mechanism >>>>>> isn't grant type so much as response type and even response mode. >>>>>> >>>>>> The perspective shared during the office hours call was, paraphrasing >>>>>> as best I can, that there are legitimate uses of implicit style flows in >>>>>> OpenID Connect (that likely won't be updated) and it would be really nice >>>>>> if this new 2.1 or whatever it's going to be document didn't imply that >>>>>> they were disallowed or problematic or otherwise create unnecessary FUD >>>>>> or >>>>>> confusion for the large population of existing deployments.. >>>>>> >>>>>> On Fri, Feb 28, 2020 at 1:56 PM Dick Hardt <dick.ha...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> I'm looking to close out this topic. I heard that Brian and Vittorio >>>>>>> shared some points of view in the office hours, and wanted to confirm: >>>>>>> >>>>>>> + Remove implicit flow from OAuth 2.1 and continue to highlight that >>>>>>> grant types are an extension mechanism. >>>>>>> >>>>>>> For example, if OpenID Connect were to be updated to refer to OAuth >>>>>>> 2.1 rather than OAuth 2..0, OIDC could define the implicit grant type >>>>>>> with >>>>>>> all the appropriate considerations. >>>>>>> >>>>>>> >>>>>>> ᐧ >>>>>>> >>>>>>> On Tue, Feb 18, 2020 at 10:49 PM Dominick Baier < >>>>>>> dba...@leastprivilege.com> wrote: >>>>>>> >>>>>>>> No - please get rid of it. >>>>>>>> >>>>>>>> ——— >>>>>>>> Dominick Baier >>>>>>>> >>>>>>>> On 18. February 2020 at 21:32:31, Dick Hardt (dick.ha...@gmail.com) >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hey List >>>>>>>> >>>>>>>> (I'm using the OAuth 2.1 name as a placeholder for the doc that >>>>>>>> Aaron, Torsten, and I are working on) >>>>>>>> >>>>>>>> Given the points Aaron brought up in >>>>>>>> >>>>>>>> >>>>>>>> https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU >>>>>>>> >>>>>>>> >>>>>>>> Does anyone have concerns with dropping the implicit flow from the >>>>>>>> OAuth 2.1 document so that developers don't use it? >>>>>>>> >>>>>>>> /Dick >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> >>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>> privileged material for the sole use of the intended recipient(s). Any >>>>>> review, use, distribution or disclosure by others is strictly >>>>>> prohibited... If you have received this communication in error, please >>>>>> notify the sender immediately by e-mail and delete the message and any >>>>>> file >>>>>> attachments from your computer. Thank you.* >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibited.. >>> If you have received this communication in error, please notify the sender >>> immediately by e-mail and delete the message and any file attachments from >>> your computer. Thank you.* >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited... > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > 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
