[OAUTH-WG] OAuth 2.1 Draft version 12 expired 19.05.2025

Dear OAuth Working Group, I have noticed that the latest draft (draft-ietf-oauth-v2-1-12), for OAuth 2.1 has expired on May 19, 2024. I would like to inquire whether this indicates that the specification is nearing finalization, or

[OAUTH-WG] OAuth 2.1 ideas

Hi all, I am new to IETF so apologies if I'm not doing this correctly. I had a few suggestions for things to add to the 2.1 spec based on scenarios encountered from running a large authorization server. Let me know your thoughts or if I should be using a different channel (like github) to contribu

Re: [OAUTH-WG] OAuth 2.1 & B2E apps (Jaap Francke)

ething that follows a well-known and > well-implemented pattern documented elsewhere? If so, a pointer would be > useful. If not, this seems like something that deserves more discussion if > not > more definition. > > Nits: > The reference to abr-twitter-reply will go awa

Re: [OAUTH-WG] OAuth 2.1 & B2E apps (Jaap Francke)

ask. -- Message: 2 Date: Thu, 2 Mar 2023 18:59:26 +0000 From: Jaap Francke To: "oauth@ietf.org" Subject: [OAUTH-WG] OAuth 2.1 & B2E apps Message-ID: Content-Type: text/plain; charset="windows-1252" Hi all, I?d like to pitch

[OAUTH-WG] OAuth 2.1 & B2E apps

Hi all, I’d like to pitch the idea of changing the abstract OAuth description to incorporate how OAuth is used in many B2E applications. In my view, OAuth 2.1 is a great opportunity to do so, without the need to make any changes in the core protocol itself, so nothing gets ‘broken’. The 2.1 RFC

[OAUTH-WG] OAuth 2.1: Should auth-param in WWW-Authenticate be optional?

In https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-07 section 5.2.3 (The WWW-Authenticate Response Header Field): All challenges for this token type MUST use the auth-scheme value Bearer. This scheme MUST be followed by one or more auth-param values. Why is at least one au

Re: [OAUTH-WG] OAuth 2.1 Sections 4.1.2.1. Error Response (Authorization Endpoint) and 5.2. Error Response (Token Endpoint)

I see how this could be confusing, so I'll make a note to clarify it. However, the only two error codes that would be returned from the authorization endpoint would be HTTP 200 or 302, because this is always returned to the browser, not to the OAuth client. In the case of the authorization server

[OAUTH-WG] OAuth 2.1 Sections 4.1.2.1. Error Response (Authorization Endpoint) and 5.2. Error Response (Token Endpoint)

Section 5.2. Error Response for the Token Endpoint states: The authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters with the response: "error": REQUIRED. A single ASCII [USASCII

Re: [OAUTH-WG] OAuth 2.1: Missing token?

The example at the end of section 5.2.2 suggests no error_code and just a 401/WWW-Authenticate header in this case: For example, in response to a protected resource request without authentication: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example" And the paragraph in

Re: [OAUTH-WG] OAuth 2.1: Missing token?

It may help to specifically clarify which interaction with the AS are we talking about here. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Fri, Feb 4, 2022 at 10:16 AM Johannes Koch wrote: > Hi there, > > a q

[OAUTH-WG] OAuth 2.1: Missing token?

Hi there, a question about https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04 5.2.3. Error Codes "invalid_request": The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one metho

[OAUTH-WG] OAuth 2.1 and TLS

Hi everybody, I provided some feedback on TLS usage on OAuth 2.1. You can find it in this commentable PR: - https://github.com/aaronpk/oauth-v2-1/pull/30/files As a first-time reader of this I-D I found that the various references to TLS were a bit confusing because: - sometimes it was explicit

Re: [OAUTH-WG] OAuth 2.1 + OAuth 2.0 for Native Apps: Private-Use URI Scheme Redirection enforcement

Please note that this simple validation (in combination with web application enforcing http(s) schemes) removes the need to implement and maintain a blocklist of potentially malicious schemes such as `javascript:/`, `vbscript:/`, and `data:/`. More details: https://security.lauritz-holtmann.de/pos

[OAUTH-WG] OAuth 2.1 + OAuth 2.0 for Native Apps: Private-Use URI Scheme Redirection enforcement

Hello everyone, Both RFC 8252 and OAuth 2.1 draft state that (paraphrasing) Apps MUST use a URI scheme based on a domain name under their control, > expressed in reverse order,

[OAUTH-WG] OAuth 2.1: improving terminology and relationship with other specs

Hi @all, I have recently started looking at OAuth2.1 spec and I proposed to align the terminology with the HTTP spec: - https://github.com/aaronpk/oauth-v2-1/pull/22 I suspect that more work on this field would improve the spec, eg: - https://github.com/aaronpk/oauth-v2-1/issues/created_by/iogg

Re: [OAUTH-WG] OAuth 2.1-03 - WG adoption?

Hello Dick! Unless the two typos that I have mentioned should be updated beforehand , no, I do not. Thank you, Sascha On Tue, 7 Jul 2020 at 16:36, Dick Hardt wrote: > Thanks Sascha and Vladimir for the feedback! > > Sascha: did you have a concern with the document being adopted by the WG? > >

Re: [OAUTH-WG] OAuth 2.1-03 - WG adoption?

Thanks Sascha and Vladimir for the feedback! Sascha: did you have a concern with the document being adopted by the WG? ᐧ On Tue, Jul 7, 2020 at 4:04 PM Sascha Preibisch wrote: > Hi all! > > Here is the rest of my feedback. At the end I also included a list of > typos and the summary of changes

Re: [OAUTH-WG] OAuth 2.1-03 - WG adoption?

Hi all! Here is the rest of my feedback. At the end I also included a list of typos and the summary of changes that I have found between RFC 6739 and the current draft. Regards, Sascha Section 2.3. Client Authentication - Draft and current: - both documents contain this

Re: [OAUTH-WG] OAuth 2.1-03 - WG adoption?

I find 03 well structured, well written and it shows that a lot of thought and work has gone into it. If this is a formal call for adoption - I support it. > - defined new client type - credentialed clients - a client that has > credentials, but the AS has not confirmed the identity of the clien

Re: [OAUTH-WG] OAuth 2.1-03 - WG adoption?

Hi all! I am reading through this document for the first time. I am mainly looking at it in comparison to OAuth 2.0 (RFC 6749) and with the eyes of a developer. I am trying to understand where phrases have changed and, of course, where features are changing. What is the best way to provide feedba

[OAUTH-WG] OAuth 2.1-03 - WG adoption?

Aaron, Torsten, and I -- with some help from Daniel -- have created a new version of draft-pareck-oauth-v2-1. I think we are ready for a WG adoption call (assuming the updated charter). Here is the doc: https://tools.ietf.org/html/draft-parecki-oauth-v2-1-03 Here is a link to the diff from -02:

[OAUTH-WG] OAuth 2.1 mimetype

Currently OAuth 2 uses application/json as their main mimetype for JSON responses. This has at least two drawbacks: 1. Content-negotiation is a good way to to version/alter behavior of endpoints/introduce extensions or modifications. 2. In systems that use Web Linking, it's harder to use a

Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

0 > compatibility mode to not break existing apps. > > > That is why I support OAuth 2.1 omitting ROPC. > > > Andreas Falk > > -- > *From:* OAuth on behalf of Aaron Parecki < > aa...@parecki.com> > *Sent:* 12 May 2020 20:19 > *To:* Francis P

Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

_ From: OAuth on behalf of Aaron Parecki Sent: 12 May 2020 20:19 To: Francis Pouatcha Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC > We are not talking about ROPC mandating OAuth2, but about OAuth-2.1 > forbidding the user of ROPC. Keep in min

Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

> We are not talking about ROPC mandating OAuth2, but about OAuth-2.1 forbidding the user of ROPC. Keep in mind that while the Security BCP explicitly forbids the use of the Password grant in OAuth 2.0, technically OAuth 2.1 just never includes it in the first place. Subtle difference. Aaron Par

Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

> We are not talking about ROPC mandating OAuth2, but about OAuth-2.1 > forbidding the user of ROPC. Absolutely and this seems like a good thing. ROPC seems very close to a use case that calls for OIDC instead of a OAuth2x token so I endorse the move. -- Jim Manico @Manicode Secure Coding Educ

Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

On Tue, May 12, 2020 at 9:50 AM Jim Manico wrote: > Forgive me if this question is late or poor context, but wouldn’t OIDC be > a better replacement for ROPC since it’s essentially a authentication flow? > > What use case for ROPC mandates OAuth2 over OIDC? > We are not talking about ROPC mandati

Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

Forgive me if this question is late or poor context, but wouldn’t OIDC be a better replacement for ROPC since it’s essentially a authentication flow? What use case for ROPC mandates OAuth2 over OIDC? -- Jim Manico @Manicode > On May 11, 2020, at 11:00 PM, Francis Pouatcha > wrote: > >  > I

[OAUTH-WG] OAuth 2.1 - recalling ROPC

I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password Credentials) with the following reasoning: Auth Code Grant: There are many use cases on the market where redirection based flows do not work. As we see in the "OAuth 2.1 - require PKCE?" thread, the complexity of user age

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

. -- Mike *From:* Torsten Lodderstedt *Sent:* Sunday, May 10, 2020 3:15 AM *To:* Mike Jones *Cc:* Daniel Fett ; oauth@ietf.org *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE? Hi Mike, Mike Jones schrieb am Fr. 8. Mai 2020 um 18:55: OAuth 2.1 was supposed to not

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

> On 10. May 2020, at 21:02, Mike Jones wrote: > > > Did I got it right that nonce does not protect public clients from code > > theft/replay? > > I believe that the OpenID Connect Code Hash (“c_hash”) claim protects against > this. c_hash is designed to prevent injection at a legit clie

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

My apologies for a tangent on an already-long thread... On Fri, May 08, 2020 at 08:50:16AM +0200, Daniel Fett wrote: > > Yes, this will make a number of implementations non-spec-compliant, but > I do not think that this is a huge problem. Software needs to adapt all > the time and a software that

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

OAuth 2.0 was incompatible with > OAuth 1.0 by design. > > > > *From:* Dick Hardt > *Sent:* Sunday, May 10, 2020 12:58 PM > *To:* Mike Jones > *Cc:* Torsten Lodderstedt ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE? > > > > Just

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

: [OAUTH-WG] OAuth 2.1 - require PKCE? Just as upgrading to OAuth 2.0 from OAuth 1.0 was voluntary, why is upgrading to OAuth 2.1 not voluntary? OAuth 2.0 obsoleted OAuth 1.0, just as OAuth 2.1 is obsoleting OAuth 2.1. Our goal is for new deployments, that are reading the drafts, to use the best

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

t.com>> Cc: Daniel Fett mailto:f...@danielfett.de>>; oauth@ietf.org<mailto:oauth@ietf.org> Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.1 - require PKCE? Hi Mike, Mike Jones mailto:40microsoft@dmarc.ietf.org>> schrieb am Fr. 8. Mai 2020 um 18:55: OAuth 2.1 was supposed t

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

PM > *To:* Mike Jones > *Cc:* Torsten Lodderstedt ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE? > > > > Hi Mike, I would consider upgrading to OAuth 2.1 to be voluntary, just as > the other extensions. Similarly, OAuth 1.0 deployments upgrading to OAut

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

the draft, then there would be no perception problem, as it would be clear that adoption of 2.1 would be voluntary, just like the other extension specs. From: Dick Hardt Sent: Sunday, May 10, 2020 12:38 PM To: Mike Jones Cc: Torsten Lodderstedt ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

> Did I got it right that nonce does not protect public clients from code > theft/replay? I believe that the OpenID Connect Code Hash (“c_hash”) claim protects against this. I’d be interested in hearing John Bradley’s take on this. -- Mike

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

Mike Jones schrieb am Sa. 9. Mai 2020 um 20:46: > There’s a huge ecosystem of successful, secure OAuth 2.0 and OpenID > Connect deployments that we have the responsibility to be stewards of. > This working group should be proud of what it’s accomplished. Part of good > stewardship is not unneces

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

. > Kind regards, Torsten. > >-- Mike > > > > *From:* OAuth *On Behalf Of * Daniel Fett > *Sent:* Thursday, May 7, 2020 11:50 PM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE? &g

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

There’s a huge ecosystem of successful, secure OAuth 2.0 and OpenID Connect deployments that we have the responsibility to be stewards of. This working group should be proud of what it’s accomplished. Part of good stewardship is not unnecessarily bifurcating the ecosystem into non-interoperabl

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

> > Aaron, I believe you’re trying to optimize the wrong thing. You’re > concerned about “the amount of explanation this will take”. That’s > optimizing for spec simplicity – a goal that I do understand. However, by > writing these few sentences or paragraphs, we’ll make it clear to > developers

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

of approval by the OAuth working group. -- Mike From: Phillip Hunt Sent: Friday, May 8, 2020 12:45 PM To: Dick Hardt Cc: Philippe De Ryck ; Mike Jones ; OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? We are not discussing

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

On Fri, May 8, 2020 at 12:42 PM Aaron Parecki wrote: > > FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is > OAuth 2.0 with best practices. > > The line there is kind of fuzzy. The objective is not to introduce new > concepts, however there are some changes defined that are

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

We are not discussing anything new here. We are discussing adoption of best practice. The disconnect appears to be that one dependent standard’s “typical” use (nonces) does not have the ietf consensus as best practice. This lack of consensus needs to be resolved. Phil > On May 8, 2020, at

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

> FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is OAuth 2.0 with best practices. The line there is kind of fuzzy. The objective is not to introduce new concepts, however there are some changes defined that are "breaking changes" from plain OAuth 2.0, because those things b

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

FYI: An objective of OAuth 2.1 is not to introduce anything new -- it is OAuth 2.0 with best practices. On Thu, May 7, 2020 at 10:36 PM Philippe De Ryck < phili...@pragmaticwebsecurity.com> wrote: > From working with a lot of developers on understanding OAuth 2.0 and OIDC, > I definitely vote for

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

tt Sent: Thursday, May 7, 2020 11:50 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? +1 to all what Aaron said. Thanks for pointing this out! We need to address this in the security BCP and this will be a normative change that affects OpenID Connect Core (just as our cur

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

+1 Phil > On May 7, 2020, at 11:50 PM, Daniel Fett wrote: > >  > +1 to all what Aaron said. Thanks for pointing this out! > > We need to address this in the security BCP and this will be a normative > change that affects OpenID Connect Core (just as our current recommendation > on the usag

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

+1 to all what Aaron said. Thanks for pointing this out! We need to address this in the security BCP and this will be a normative change that affects OpenID Connect Core (just as our current recommendation on the usage of nonce). We would then have: - use PKCE, except if you use OIDC with a nonc

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

From working with a lot of developers on understanding OAuth 2.0 and OIDC, I definitely vote for simplicity. Understanding the subtle nuances of when a nonce is fine and when PKCE should be used is impossible without in-depth knowledge of the flows and their properties. Misunderstandings will ca

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

Aaron, I believe you’re trying to optimize the wrong thing. You’re concerned about “the amount of explanation this will take”. That’s optimizing for spec simplicity – a goal that I do understand. However, by writing these few sentences or paragraphs, we’ll make it clear to developers that hun

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

Backing up a step or two, there's another point here that I think has been missed in these discussions. PKCE solves two problems: stolen authorization codes for public clients, and authorization code injection for all clients. We've only been talking about authorization code injection on the list

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

-- Mike >> >> >> >> *From:* Aaron Parecki >> *Sent:* Wednesday, May 6, 2020 12:24 PM >> *To:* Mike Jones >> *Cc:* Dick Hardt ; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE? >> >> >> >> Yes, th

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

the change to the Security BCP to make it self-consistent. -- Mike From: Aaron Parecki Sent: Wednesday, May 6, 2020 1:43 PM To: Mike Jones Cc: Dick Hardt ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? Going back to this

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

t; >> *From:* Aaron Parecki >> *Sent:* Wednesday, May 6, 2020 12:24 PM >> *To:* Mike Jones >> *Cc:* Dick Hardt ; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE? >> >> >> >> Yes, the BCP says *clients* may use either PKCE or nonce

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

t; > > > *From:* Aaron Parecki > *Sent:* Wednesday, May 6, 2020 12:24 PM > *To:* Mike Jones > *Cc:* Dick Hardt ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth 2.1 - require PKCE? > > > > Yes, the BCP says *clients* may use either PKCE or nonce to prevent > aut

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

. -- Mike From: Phillip Hunt Sent: Wednesday, May 6, 2020 1:16 PM To: Mike Jones Cc: Aaron Parecki ; Steinar Noem ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? Why couldn’t OIDC evolve as a spec to conform and match FAPI and 2.1? Phil On May 6, 2020, at 12:34

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

-- Mike > > From: Aaron Parecki > Sent: Wednesday, May 6, 2020 12:29 PM > To: Steinar Noem > Cc: Phillip Hunt ; Mike Jones > ; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? > > I should add that even some OpenID Connect profiles require PKCE,

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

stewards of the OAuth ecosystem. -- Mike From: Aaron Parecki Sent: Wednesday, May 6, 2020 12:29 PM To: Steinar Noem Cc: Phillip Hunt ; Mike Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? I should add that even some

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

Jones Cc: Dick Hardt ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE? Yes, the BCP says *clients* may use either PKCE or nonce to prevent authorization code injection. Shortly after that quoted segment is the below: > Authorization servers MUST support PKCE [RFC7636]. On

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

r the OpenID Connect nonce. Trying to retroactively impose >>>> unnecessary requirements on existing deployments is unlikely to succeed and >>>> will significantly reduce the relevance of the OAuth 2.1 effort. >>>> >>>> >>>> >>>> In particular, authorization servers shouldn’t be

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

ort >>> PKCE when they already support the OpenID Connect nonce. And clients >>> shouldn’t reject responses from servers that don’t support PKCE when they >>> do contain the OpenID Connect nonce. Doing so would unnecessarily break >>> things and create confusion

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

>>>> >>>> In particular, authorization servers shouldn’t be required to support PKCE >>>> when they already support the OpenID Connect nonce. And clients shouldn’t >>>> reject responses from servers that don’t support PKCE when they do contain

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

ct nonce. Doing so would unnecessarily break >> things and create confusion in the marketplace. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of * Dick Hardt >> *Sen

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

And clients shouldn’t >> reject responses from servers that don’t support PKCE when they do contain >> the OpenID Connect nonce. Doing so would unnecessarily break things and >> create confusion in the marketplace. >> >> >> >> -- Mike >&

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

port PKCE when they do contain > the OpenID Connect nonce. Doing so would unnecessarily break things and > create confusion in the marketplace. > > > > -- Mike > > > > *From:* OAuth *On Behalf Of * Dick H

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

Behalf Of Dick Hardt Sent: Wednesday, May 6, 2020 10:48 AM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth 2.1 - require PKCE? Hello! We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best practice for OAuth 2.0. It is not common in OpenID Connect servers as the nonce solves

[OAUTH-WG] OAuth 2.1 - require PKCE?

Hello! We would like to have PKCE be a MUST in OAuth 2.1 code flows. This is best practice for OAuth 2.0. It is not common in OpenID Connect servers as the nonce solves some of the issues that PKCE protects against. We think that most OpenID Connect implementations also support OAuth 2.0, and henc

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

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 worry

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

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 conce

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

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 happen

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

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 W

[OAUTH-WG] OAuth 2.1 - IANA Considerations

Please ignore the IANA Considerations section of the draft. https://tools.ietf.org/id/draft-parecki-oauth-v2-1-00.html#name-iana-considerations There are no new IANA registrations, which is what this section should state. Apologies for any confusion. /Dick ᐧ _

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

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 implici

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

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

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

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 >

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

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 < > tors...@lodderstedt

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

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 suffic

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

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 e

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

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 unfortunately

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

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

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

can access, have attributes specific to >>>>>>>>>>>>> their use in OAuth2, and so on. Many existing systems have access >>>>>>>>>>>>> controls based on users, roles, permissions and so on and expect >>>>>>>

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

ntly converted some code from ROPC to >> JWT bearer for exactly this use-case, it went from a couple of lines of >> code to two screens of code. For service to service API calls within a >> datacenter I’m not convinced this resulted in a material increase in >> security for t

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

e AS can access, have attributes specific to >>>>>>>>>>>>> their use in OAuth2, and so on. Many existing systems have access >>>>>>>>>>>>> controls based on users, roles, permissions and so on and expect >>>&

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

not OAuth and we need to get rid of it. > > Hans. > > On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki wrote: > Agreed. Plus, the Security BCP is already effectively acting as a grace > period since it currently says the password grant MUST NOT be used, so in > the OAuth 2.0

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

come up with one...) > In reality it turned out just to be a one off that people used as an easy > way out to stick to an anti-pattern and still claim to do OAuth 2.0. It is > plain wrong, it is not OAuth and we need to get rid of it. > > Hans. > > On Tue, Feb 18, 2020 at 1

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

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 update

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

t; > > > > > > > > > > > > > > — Neil > > > > > > > > > > > > > > > > > > > > > On 19 Feb 2020, at 21:35, Torsten Lodderstedt > > > > > > > > > > > wrote: > > >

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

eil > >>>>>>>> > >>>>>>>>> On 19 Feb 2020, at 21:35, Torsten Lodderstedt > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Can you explain

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

Sent from my LG Stylo 5+, an AT&T 4G LTE smartphone-- Original message--From: Brian CampbellDate: Mon, Feb 24, 2020 9:04 AMTo: Neil Madden;Cc: Matthew De Haast;oauth@ietf.org;Richard Backman, Annabelle;Subject:Re: [OAUTH-WG] OAuth 2.1: dropping password grantConcur with the senti

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

you mentioned? >> >>>>>>>>> >> >>>>>>>>>> Am 19.02.2020 um 22:03 schrieb Neil Madden < >> neil.mad...@forgerock.com>: >> >>>>>>>>>> >> >>>>>>>>&g

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

On Mon, Feb 24, 2020 at 6:49 AM Neil Madden wrote: > Well, kinda. People can still theoretically use OAuth 1 too, but the world > has moved on - software has dropped support for it, websites don’t support > it, and so on > I’m a bit confused about what OAuth 2.1 is intended to be. If it’s not

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

> OAuth2 client (typically so that some lower layer of the system can still > perform its required permission checks). > >>>>>>>>>> > >>>>>>>>>> There are better grant types for this - e.g. JWT bearer - but > they are a bit

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

gt;>>>>> I very much agree with this with regards to real users. >>>>>>>>>> >>>>>>>>>> The one legitimate use-case for ROPC I’ve seen is for service >>>>>>>>>> accounts - where you essentially want

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

Well, kinda. People can still theoretically use OAuth 1 too, but the world has moved on - software has dropped support for it, websites don’t support it, and so on. I’m a bit confused about what OAuth 2.1 is intended to be. If it’s not a new version of OAuth (“obsoletes” the old RFC), then is n

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

t;>> >>>>>>>>>> I very much agree with this with regards to real users. >>>>>>>>>> >>>>>>>>>> The one legitimate use-case for ROPC I’ve seen is for service >>>>>>>>>>

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

ment. Having recently converted some code > from ROPC to JWT bearer for exactly this use-case, it went from a couple of > lines of code to two screens of code. For service to service API calls > within a datacenter I’m not convinced this resulted in a material increase > in security for the

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

ans Zandbelt wrote: >>>>>>>>>> >>>>>>>>>> I would also seriously look at the original motivation behind ROPC: I know it has been deployed and is used in quite a lot of places but I have never actually come across a use case where i

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

gt;>>>>>>> >>>>>>>>>> I very much agree with this with regards to real users. >>>>>>>>>> >>>>>>>>>> The one legitimate use-case for ROPC I’ve seen is for service >>>>>>>>

  1   2   >