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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
