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
wrote:
> Perfect, and really good info! but most people, if we need to
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
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
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
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
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 wrote:
> Would you clarify what text works Brian?
>
> On Sat, Mar 7, 2020 at 3:24 PM Brian Campbell
> wrote:
>
>> Yeah, that
Would you clarify what text works Brian?
On Sat, Mar 7, 2020 at 3:24 PM Brian Campbell
wrote:
> Yeah, that works for me.
>
> On Sat, Mar 7, 2020, 9:37 AM Dick Hardt wrote:
>
>> Brian: does that meet your requirements?
>>
>> If not, how about if we refer to OIDC as an example extension without
Yeah, that works for me.
On Sat, Mar 7, 2020, 9:37 AM Dick Hardt 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 <
>
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
wrote:
> I think keeping the response type as extension point and not mentioning
> implicit at all is
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 :
>
>
> How about if we add in a nonnormative reference to OIDC as an explicit
> example of an extension:
>
> "For
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
wrote:
> The name implicit grant is
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
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
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
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
15 matches
Mail list logo
