Subject: Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?

From: Brian Campbell <[email-masked]>
Date: Sat, 7 Mar 2020 16:23:51 -0700

Yeah, that works for me.

On Sat, Mar 7, 2020, 9:37 AM Dick Hardt <[email-masked]> 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 <
> [email-masked]> 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 <[email-masked]>:
>>
>> 
>> 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 <[email-masked]>
>> 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 <[email-masked]> 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 <
>>>> [email-masked]> wrote:
>>>>
>>>>> No - please get rid of it.
>>>>>
>>>>> ———
>>>>> Dominick Baier
>>>>>
>>>>> On 18. February 2020 at 21:32:31, Dick Hardt ([email-masked])
>>>>> 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
>>>>> [email-masked]
>>>>> 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
>> [email-masked]
>> 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._

---

From: Dick Hardt <[email-masked]>
Date: Sat, 7 Mar 2020 15:25:19 -0800

Would you clarify what text works Brian?

On Sat, Mar 7, 2020 at 3:24 PM Brian Campbell <[email-masked]>
wrote:

>>> On Sat, Mar 7, 2020 at 5:27 AM Brian Campbell <
>>> [email-masked]> wrote:
>>>
>>>> The perspective shared during the office hours call was, paraphrasing
>>>> as best I can, that there are legitimate uses of implicit style flows in
>>>>> 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.
>>>>>
>>>>>
>>>>> ᐧ
>>>>>
>>>>>> (I'm using the OAuth 2.1 name as a placeholder for the doc that
>>>>>> Aaron, Torsten, and I are working on)
>>>>>>
> review, use, distribution or disclosure by others is strictly prohibited.

---

From: Brian Campbell <[email-masked]>
Date: Sat, 7 Mar 2020 16:35:37 -0700

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.

---

From: Brian Campbell <[email-masked]>
Date: Sat, 7 Mar 2020 06:27:07 -0700

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.

On Fri, Feb 28, 2020 at 1:56 PM Dick Hardt <[email-masked]> wrote:

> + Remove implicit flow from OAuth 2.1 and continue to highlight that grant
> types are an extension mechanism.
>
> rather than OAuth 2.0, OIDC could define the implicit grant type with all
> On Tue, Feb 18, 2020 at 10:49 PM Dominick Baier <[email-masked]>
> wrote:
>
>> Does anyone have concerns with dropping the implicit flow from the OAuth
>> 2.1 document so that developers don't use it?
>>
>> /Dick

---

From: Dick Hardt <[email-masked]>
Date: Sat, 7 Mar 2020 08:06:04 -0800

or similar language
ᐧ

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 7 Mar 2020 17:29:13 +0100

I think keeping the response type as extension point and not mentioning implicit at all is sufficient to support Brian’s objective.

> 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 <[email-masked]> 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. 
>> 
>>> 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 <[email-masked]> wrote:
>>>>> On 18. February 2020 at 21:32:31, Dick Hardt ([email-masked]) 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)
>>>>> 
>>>>> Does anyone have concerns with dropping the implicit flow from the OAuth 2.1 document so that developers don't use it?
>>>>> 
>>>>> /Dick
>> 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.

---

From: Dick Hardt <[email-masked]>
Date: Sat, 7 Mar 2020 08:36:49 -0800

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 12 Mar 2020 11:14:43 -0700

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=
[email-masked]> 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.
>
>>>>> I think keeping the response type as extension point and not
>>>>> mentioning implicit at all is sufficient to support Brian’s objective.
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> confusion for the large population of existing deployments..
>>>>>>
>>>>>> 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.*
>>>>>
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Jared Jennings <[email-masked]>
Date: Wed, 18 Mar 2020 06:14:21 -0500

I agree, but would add that as long as it says "this is being drop", but
does not impact "that", then the reader can understand context. "This does
not change support for implicit response that OpenID Connect (OIDC) makes
use of".

my two cents.

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152

On Thu, Mar 12, 2020 at 1:15 PM Vittorio Bertocci <Vittorio=
[email-masked]> wrote:

>>> On Sat, Mar 7, 2020 at 3:24 PM Brian Campbell <
>>>>>>> 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..
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>> prohibited....  If you have received this communication in error, please

---

From: Justin Richer <[email-masked]>
Date: Wed, 18 Mar 2020 08:55:55 -0400

OpenID Connect is based on OAuth 2.0, not on OAuth 2.1. Therefore, it would not be affected at all, whether through the hybrid or implicit flows.

If OIDC pushes a revision to OAuth 2.1, then it would be bound by the features of OAuth 2.1 and would need to contend with that. But until that happens, everything we do with OAuth 2.1 has literally no effect on OAuth 2.0 systems, including OIDC.

 — Justin

> On Mar 18, 2020, at 7:14 AM, Jared Jennings <[email-masked]> wrote:
> 
> I agree, but would add that as long as it says "this is being drop", but does not impact "that", then the reader can understand context. "This does not change support for implicit response that OpenID Connect (OIDC) makes use of".
> 
> my two cents.
> 
> -Jared
> Skype:jaredljennings
> Signal:+1 816.730.9540
> On Thu, Mar 12, 2020 at 1:15 PM Vittorio Bertocci <Vittorio=[email-masked] <mailto:[email-masked]>> wrote:
> 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=[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> On Sat, Mar 7, 2020 at 3:24 PM Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> Yeah, that works for me.. 
> 
> On Sat, Mar 7, 2020, 9:37 AM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> 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 <torsten@lodderstedt..net <mailto:[email-masked]>> wrote:
>> Am 07.03.2020 um 17:06 schrieb Dick Hardt <[email-masked] <mailto:[email-masked]>>:
>> 
>> 
>> On Sat, Mar 7, 2020 at 5:27 AM Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 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 <[email-masked] <mailto:dick.hardt@gmail..com>> wrote:
>> On Tue, Feb 18, 2020 at 10:49 PM Dominick Baier <[email-masked] <mailto:[email-masked]>> wrote:
>> On 18. February 2020 at 21:32:31, Dick Hardt ([email-masked] <mailto:[email-masked]>) wrote:
>> 
>>> Hey List 
>>> 
>>> https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU <https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU>
>>> 
>>> 
>>> [email-masked] <mailto:[email-masked]> 
>>> https://www.ietf.org/mailman/listinfo/oauth <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.
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Jared Jennings <[email-masked]>
Date: Wed, 18 Mar 2020 08:03:08 -0500

Perfect, and really good info! but most people, if we need to worry about
the audience, are not going to put that together. They just read "OAUTH".
It's not a deal breaker, but if the document is going to be easy to read
and keep confusion to a minimum... then it would be nice if it addressed
concepts like this that might seem obvious to you.

Granted, I am coming at this from a consultant perspective who works with a
lot of companies who have architects that barely understand these
technologies, but are implementing them for the enterprise.

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540

On Wed, Mar 18, 2020 at 7:55 AM Justin Richer <[email-masked]> wrote:

> OpenID Connect is based on OAuth 2.0, not on OAuth 2.1. Therefore, it
> would not be affected at all, whether through the hybrid or implicit flows.
>
> If OIDC pushes a revision to OAuth 2.1, then it would be bound by the
> features of OAuth 2.1 and would need to contend with that. But until that
> happens, everything we do with OAuth 2.1 has literally no effect on OAuth
> 2.0 systems, including OIDC.
>
>  — Justin
>
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Mar 2020 11:43:03 -0700

Minimizing market confusing is an objective of the OAuth 2.1 draft.

Given you are one of the people explaining to the market, your suggestions
are of interest and welcome!

On Wed, Mar 18, 2020 at 6:03 AM Jared Jennings <[email-masked]>
wrote:

> and keep confusion to a minimum.... then it would be nice if it addressed
> Granted, I am coming at this from a consultant perspective who works with
> a lot of companies who have architects that barely understand these
>> happens, everything we do with OAuth 2..1 has literally no effect on OAuth