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

[Warren Parad]

Frankly I just don't understand.  You've even said in your original email,
that the oath spec is alive and well in enterprise deployments. And since
that is the case, it points to how successful the current state of the RFCs
are. So I can't fathom what would make sense to actually change.

If anything it may mean that some people's interpretations of specific
words in the documents have been taken to be more specific than intended,
however this can't be fixed by changing the words, someone will always
interpret them in an inconsistent manner.

So, at least from my perspective, there is nothing we need to do, nor
should do here as the language is already incredible open and has been
successful. That's more than anyone could hope for.

If you are interested in continuing down this path anyway, it would be most
helpful to focus on one single implementation where the exact wording
causes an actual problem in designing that system. And rather than
suggesting "we should change the words being used" which feels incredibly
arbitrary, please quote the actually source definition and share what is
problematic with it.

- Warren

On Mon, Apr 17, 2023, 16:14 Jaap Francke  wrote:

> Hi all,
>
>
>
> Early March I shared the suggestion to make the abstract OAuth protocol
> description a bit more generic so it would not only have a fit with B2C use
> cases but would suit B2E use cases as well.
> I haven’t seen any response from you – I find myself wondering why.
> As my suggestion still makes sense to me, I’d appreciate a response.
> Thanks in advance!
>
>
>
> Cheers, Jaap
>
>
>
> *From: *OAuth  on behalf of oauth-requ...@ietf.org
> 
> *Date: *Thursday, 2 March 2023 at 20:00
> *To: *oauth@ietf.org 
> *Subject: *OAuth Digest, Vol 173, Issue 7
>
> Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-requ...@ietf.org
>
> You can reach the person managing the list at
> oauth-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>1. Artart last call review of
>   draft-ietf-oauth-step-up-authn-challenge-12
>   (Robert Sparks via Datatracker)
>2. OAuth 2.1 & B2E apps (Jaap Francke)
>
>
> --
>
> Message: 1
> Date: Thu, 02 Mar 2023 10:41:34 -0800
> From: Robert Sparks via Datatracker 
> To: 
> Cc: draft-ietf-oauth-step-up-authn-challenge@ietf.org,
> last-c...@ietf.org,  oauth@ietf.org
> Subject: [OAUTH-WG] Artart last call review of
> draft-ietf-oauth-step-up-authn-challenge-12
> Message-ID: <167778249416.23678.7058306125542432...@ietfa.amsl.com>
> Content-Type: text/plain; charset="utf-8"
>
> Reviewer: Robert Sparks
> Review result: Ready with Issues
>
> Summary: essentially ready but with issues to consider before being
> published
> as a proposed standard RFC.
>
> Issues:
>
> I expected to find some discussion of considerations of avoiding "step
> down"
> given the intuitive appeal to "step up". Can the client or Authorization
> server
> notice if the resource server has through whatever fault asserted that it
> will
> only accept the use of an authentication context class that is blatantly
> inferior to what has already been provided? And if they notice, what is
> expected to happen? Or is it expected that this is allowed, particularly
> when a
> short max_age is also supplied?
>
> The document also suggests that the client hold on to, and possibly re-use
> in
> the future, access tokens that have been challenged as having insufficient
> user
> authorization. Is this behavior something 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 away with the changelog when
> the RFC
> Editor removes it. It would be kind to acknowledge that in the note to the
> RFC
> Editor so that they know it's expected and don't have to ask.
>
>
>
>
>
> --
>
> Message: 2
> Date: Thu, 2 Mar 2023 18:59:26 +
> From: Jaap Francke 
> To: "oauth@ietf.org" 
> Subject: [OAUTH-WG] OAuth 2.1 & B2E apps
> Message-ID:
> <
> am0pr06mb418002174bf153ed05d93839e4...@am0pr06mb4180.eurprd06.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="windows-1252"
>
> 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 would be just acknowledging how OAuth is 

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

[Jaap Francke]

Hi all,

Early March I shared the suggestion to make the abstract OAuth protocol 
description a bit more generic so it would not only have a fit with B2C use 
cases but would suit B2E use cases as well.
I haven’t seen any response from you – I find myself wondering why.
As my suggestion still makes sense to me, I’d appreciate a response.
Thanks in advance!

Cheers, Jaap

From: OAuth  on behalf of oauth-requ...@ietf.org 

Date: Thursday, 2 March 2023 at 20:00
To: oauth@ietf.org 
Subject: OAuth Digest, Vol 173, Issue 7
Send OAuth mailing list submissions to
oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org

You can reach the person managing the list at
oauth-ow...@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Artart last call review of
  draft-ietf-oauth-step-up-authn-challenge-12
  (Robert Sparks via Datatracker)
   2. OAuth 2.1 & B2E apps (Jaap Francke)


--

Message: 1
Date: Thu, 02 Mar 2023 10:41:34 -0800
From: Robert Sparks via Datatracker 
To: 
Cc: draft-ietf-oauth-step-up-authn-challenge@ietf.org,
last-c...@ietf.org,  oauth@ietf.org
Subject: [OAUTH-WG] Artart last call review of
draft-ietf-oauth-step-up-authn-challenge-12
Message-ID: <167778249416.23678.7058306125542432...@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"

Reviewer: Robert Sparks
Review result: Ready with Issues

Summary: essentially ready but with issues to consider before being published
as a proposed standard RFC.

Issues:

I expected to find some discussion of considerations of avoiding "step down"
given the intuitive appeal to "step up". Can the client or Authorization server
notice if the resource server has through whatever fault asserted that it will
only accept the use of an authentication context class that is blatantly
inferior to what has already been provided? And if they notice, what is
expected to happen? Or is it expected that this is allowed, particularly when a
short max_age is also supplied?

The document also suggests that the client hold on to, and possibly re-use in
the future, access tokens that have been challenged as having insufficient user
authorization. Is this behavior something 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 away with the changelog when the RFC
Editor removes it. It would be kind to acknowledge that in the note to the RFC
Editor so that they know it's expected and don't have to ask.





--

Message: 2
Date: Thu, 2 Mar 2023 18:59:26 +
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 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 would be just acknowledging how OAuth is already used widely today.

To the best of my understanding, OAuth (as per RFC6749) originated from a 
Business-to-Consumer (B2C) context.
The typical example that is frequently used to explain OAuth is about an 
enduser (resource owner) that can grant a printing service (client) access to 
their protected photos stored at a photo sharing service (resource server).
What I see in everyday practice in the IAM field, is that OAuth is used for 
Business-to-employee (B2E) applications (often in combination with the OIDC 
extension).
In this context, the enduser is not the resource owner. Instead, the company is 
owning the resources stored at its resource servers and employees (or other 
type of endusers) are granted access  based on roles/rules implemented at the 
resource server.
One may say that OAuth was not designed for such B2E scenarios, but I would say 
that the protocol is perfectly suitable. Practice proves this.
I don?t have hard data to further prove my point but I expect OAuth is 
worldwide being used more often for B2E like applications than it is for B2C 
applications.

The good news is that the narrative around the core specs can be re-written to 
make it more generally applicable without changing the protocol itself.
I think this will be beneficial to anyone working with OAuth, newbies or 
experienced IAM workforce. In my view things will be easier to understand and 
closer to daily practice.

The main changes I?m proposing for section 1 are the 

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

[Aaron Parecki]

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 communicating the error to the
user, that would be HTTP 200 so that their browser will render the page
rather than show its own error.

In the case of the authorization server communicating the error to the
client, it would of course have to send HTTP 302 so that the browser is
redirected to the client.

I do see the HTTP 302 included as an example in 4.1.2.1 but I agree this
could be made more explicit, thanks!

Aaron


On Sat, Feb 12, 2022 at 6:50 PM  wrote:

> 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 
> ] 
> error code from the
>
> Following:
>
>
> (error list omitted for breviate)
>
>
>
> Section 4.1.2.1. Error Response for the Authorization Endpoint contains the
>
> Same error list but no direction about what HTTP status code should be 
> returned.
> Wouldn’t it be helpful in the OAuth 2.1 draft to enhance section 4.1.2.1. 
> Error
>
> Response with the same or similar guidance regarding the current HTTP status 
> code
>
> to return?
>
>
>
>
>
>
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
>
>
> REMI Networks
>
> 2335 Dunwoody Crossing Suite E
>
> Dunwoody, GA 30338-8221
>
>
> ___
> 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

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

[Neil Madden]

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 section 5.2.3 immediately following the section you quote 
is even more explicit:

   If the request lacks any authentication information (e.g., the client
   was unaware that authentication is necessary or attempted using an
   unsupported authentication method), the resource server SHOULD NOT
   include an error code or other error information.

So, no error_code at all if no access token supplied.

Kind regards,

Neil

> On 4 Feb 2022, at 09:15, Johannes Koch 
>  wrote:
> 
>   EntSec couldn't recognize this email as this is the first time you 
> received an email from this sender johannes.koch=40avenga.com @ dmarc.ietf.org
> 
> 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 method for including an access
>   token, or is otherwise malformed.  The resource server SHOULD
>   respond with the HTTP 400 (Bad Request) status code.
> 
>"invalid_token":  The access token provided is expired, revoked,
>   malformed, or invalid for other reasons.  The resource SHOULD
>   respond with the HTTP 401 (Unauthorized) status code.  The client
>   MAY request a new access token and retry the protected resource
>   request.
> 
> Now, what is the intended error code for the situation where no access token 
> is provided? The description for invalid_token seems to imply that one token 
> was provided.
> As the token may be seen as a required parameter, invalid_request may be 
> appropriate. However, a missing token smells more like HTTP 401 
> (Unauthorized).
> 
> Should this be an additional error code (missing_token)? Or should this case 
> be added to invalid_token?
> 
> -- 
> Johannes Koch
> ___
> 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

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

[Warren Parad]

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 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 method for including an access
>   token, or is otherwise malformed.  The resource server SHOULD
>   respond with the HTTP 400 (Bad Request) status code.
>
>"invalid_token":  The access token provided is expired, revoked,
>   malformed, or invalid for other reasons.  The resource SHOULD
>   respond with the HTTP 401 (Unauthorized) status code.  The client
>   MAY request a new access token and retry the protected resource
>   request.
>
> Now, what is the intended error code for the situation where no access
> token is provided? The description for invalid_token seems to imply that
> one token was provided.
> As the token may be seen as a required parameter, invalid_request may be
> appropriate. However, a missing token smells more like HTTP 401
> (Unauthorized).
>
> Should this be an additional error code (missing_token)? Or should this
> case be added to invalid_token?
>
> --
> Johannes Koch
> ___
> 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

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

[Filip Skokan]

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/post/sso-security-redirect-uri/

Best,
*Filip*


On Thu, 3 Dec 2020 at 10:59, Filip Skokan  wrote:

> 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, as recommended by Section 3.8 of [RFC7595] for
>> private-use URI schemes. e.g. com.example.app:/
>
>
> My question is, is the AS right to reject client registrations that do not
> follow this specific requirement, to e.g. reject myapp:/oauth2/example-issuer
> on the account of it not being neither claimed https scheme, an http: +
> loopback interface, nor having a "." (dot) character suggesting it is a
> reverse domain scheme?
>
> Best,
> *Filip*
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Sascha Preibisch]

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?
>
> ᐧ
>
> 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 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 description: "... the authorization
>> server (e.g., password, public/private key pair)"
>> - since the client usually uses a 'client secret', maybe this could be
>> worded as such:
>> - suggestion: "... the authorization server (e.g., client secret,
>> public/private key pair)"
>>
>> Draft:
>>
>> "The authorization server MAY establish a client authentication method
>> with public clients, which converts them to credentialed clients.
>> However, the authorization server MUST NOT rely on credentialed
>> client authentication for the purpose of identifying the client."
>>
>> - Does this mean that credentialed clients are as trustworthy/ not
>> trustworthy as public clients?
>>
>> Draft:
>>
>> "Clients in possession of a client password, also known as a client
>> secret, ..."
>>
>> - Maybe this could simply be changed to:
>> "Clients in possession of a client secret ..."
>>
>> Section 3.1.2.2 Registration Requirements
>> -
>>
>> Draft:
>>
>> "Lack of requiring registration of redirect URIs enables an attacker
>> to use the authorization endpoint as an open redirector as described
>> in Section 9.18."
>>
>> - is that still required since redirect_uris have to be pre-registered
>> now?
>>
>> Section 4.1. Authorization Code Grant
>> -
>>
>> Draft:
>> - Figure 3, step (1), does not include 'code_challenge_method' Is that
>> intentionally?
>> - I am suggesting to include it to avoid potential questions and
>> confusion. It could listed as 'optional' as 'scope' is
>> - In addition, when referencing parameters, they should be spelled as
>> used in the protocol, i.e.: 'code_challenge' instead of
>> 'code_challenge'
>>
>> Section 4.1.1 Authorization Request
>> -
>>
>> Draft:
>>
>> "Clients use a unique secret per authorization request to protect  "
>>
>> - It would be less confusing if this section would start of with "PKCE
>> is required"
>> - Introducing a '... unique secret per ...' sounds like something very
>> new although this is referencing PKCE
>> - Suggestion (along the lines of):
>> "Clients MUST leverage PKCE per authorization request to protect ..."
>>
>> Section 4.1.2.1 Error Response
>> -
>>
>> Draft:
>>
>> "An AS MUST reject requests without a "code_challenge" from public
>> clients, and MUST reject such requests from other clients  unless
>> there is reasonable assurance that ..."
>>
>> - These statements are the ones that cause discussions between
>> developers and/ or third parties
>> - ' ... unless ...' is very difficult to grasp, even when looking into
>> section 9.8
>> - I would suggest to make it required
>>
>> Section 5.1 Successful Response
>> -
>>
>> Draft and current:
>>
>> - both documents describe the refresh_token response parameter and
>> describe it as such:
>> "OPTIONAL.  The refresh token, which can be used to obtain new access
>> tokens using the same authorization grant as described in > href="#section-6">Section 6"
>>
>> - As an enhancement, I suggest this update:
>> "OPTIONAL.  The refresh token, which can be used to obtain new access
>> tokens using the grant type "refresh_token" as described in > href="#section-6">Section 6"
>>
>> Section 6. Refreshing an Access Token
>> -
>>
>> Draft:
>>
>> Authorization servers SHOULD determine, based on a risk assessment,
>> whether to issue refresh tokens to a certain client.  If the
>> authorization server decides not to issue refresh tokens, the client
>> MAY refresh access tokens by utilizing other grant types, such as the
>> authorization code grant type.  In such a case, the authorization
>> server may utilize cookies and persistent grants to optimize the user
>> experience.
>>
>> - That paragraph sounds like a general advice for web developers and
>> should appear in an appendix for my taste
>> - ' ... based on risk assessment ... ' may exclude any implementation
>> that does not have such capabilities
>>
>> ===
>>
>> Draft:
>>
>> - this section includes this statement:
>> "Confidential or credentialed clients MUST authenticate with the
>> authorization server ..."
>>
>> - section 2.3 includes this statement and makes me wonder how
>> confident an authorization server can be when working with
>> 

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

[Dick Hardt]

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 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 description: "... the authorization
> server (e.g., password, public/private key pair)"
> - since the client usually uses a 'client secret', maybe this could be
> worded as such:
> - suggestion: "... the authorization server (e.g., client secret,
> public/private key pair)"
>
> Draft:
>
> "The authorization server MAY establish a client authentication method
> with public clients, which converts them to credentialed clients.
> However, the authorization server MUST NOT rely on credentialed
> client authentication for the purpose of identifying the client."
>
> - Does this mean that credentialed clients are as trustworthy/ not
> trustworthy as public clients?
>
> Draft:
>
> "Clients in possession of a client password, also known as a client
> secret, ..."
>
> - Maybe this could simply be changed to:
> "Clients in possession of a client secret ..."
>
> Section 3.1.2.2 Registration Requirements
> -
>
> Draft:
>
> "Lack of requiring registration of redirect URIs enables an attacker
> to use the authorization endpoint as an open redirector as described
> in Section 9.18."
>
> - is that still required since redirect_uris have to be pre-registered now?
>
> Section 4.1. Authorization Code Grant
> -
>
> Draft:
> - Figure 3, step (1), does not include 'code_challenge_method' Is that
> intentionally?
> - I am suggesting to include it to avoid potential questions and
> confusion. It could listed as 'optional' as 'scope' is
> - In addition, when referencing parameters, they should be spelled as
> used in the protocol, i.e.: 'code_challenge' instead of
> 'code_challenge'
>
> Section 4.1.1 Authorization Request
> -
>
> Draft:
>
> "Clients use a unique secret per authorization request to protect  "
>
> - It would be less confusing if this section would start of with "PKCE
> is required"
> - Introducing a '... unique secret per ...' sounds like something very
> new although this is referencing PKCE
> - Suggestion (along the lines of):
> "Clients MUST leverage PKCE per authorization request to protect ..."
>
> Section 4.1.2.1 Error Response
> -
>
> Draft:
>
> "An AS MUST reject requests without a "code_challenge" from public
> clients, and MUST reject such requests from other clients  unless
> there is reasonable assurance that ..."
>
> - These statements are the ones that cause discussions between
> developers and/ or third parties
> - ' ... unless ...' is very difficult to grasp, even when looking into
> section 9.8
> - I would suggest to make it required
>
> Section 5.1 Successful Response
> -
>
> Draft and current:
>
> - both documents describe the refresh_token response parameter and
> describe it as such:
> "OPTIONAL.  The refresh token, which can be used to obtain new access
> tokens using the same authorization grant as described in  href="#section-6">Section 6"
>
> - As an enhancement, I suggest this update:
> "OPTIONAL.  The refresh token, which can be used to obtain new access
> tokens using the grant type "refresh_token" as described in  href="#section-6">Section 6"
>
> Section 6. Refreshing an Access Token
> -
>
> Draft:
>
> Authorization servers SHOULD determine, based on a risk assessment,
> whether to issue refresh tokens to a certain client.  If the
> authorization server decides not to issue refresh tokens, the client
> MAY refresh access tokens by utilizing other grant types, such as the
> authorization code grant type.  In such a case, the authorization
> server may utilize cookies and persistent grants to optimize the user
> experience.
>
> - That paragraph sounds like a general advice for web developers and
> should appear in an appendix for my taste
> - ' ... based on risk assessment ... ' may exclude any implementation
> that does not have such capabilities
>
> ===
>
> Draft:
>
> - this section includes this statement:
> "Confidential or credentialed clients MUST authenticate with the
> authorization server ..."
>
> - section 2.3 includes this statement and makes me wonder how
> confident an authorization server can be when working with
> 'credentialed' clients':
> "However, the authorization server MUST NOT rely on credentialed
> client authentication for the purpose of identifying the client."
>
> - Any clarification, I would say about the client type 'credentialed'
> in general, would be helpful
>
> -
> Typos:
> 

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

[Sascha Preibisch]

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 description: "... the authorization
server (e.g., password, public/private key pair)"
- since the client usually uses a 'client secret', maybe this could be
worded as such:
- suggestion: "... the authorization server (e.g., client secret,
public/private key pair)"

Draft:

"The authorization server MAY establish a client authentication method
with public clients, which converts them to credentialed clients.
However, the authorization server MUST NOT rely on credentialed
client authentication for the purpose of identifying the client."

- Does this mean that credentialed clients are as trustworthy/ not
trustworthy as public clients?

Draft:

"Clients in possession of a client password, also known as a client secret, ..."

- Maybe this could simply be changed to:
"Clients in possession of a client secret ..."

Section 3.1.2.2 Registration Requirements
-

Draft:

"Lack of requiring registration of redirect URIs enables an attacker
to use the authorization endpoint as an open redirector as described
in Section 9.18."

- is that still required since redirect_uris have to be pre-registered now?

Section 4.1. Authorization Code Grant
-

Draft:
- Figure 3, step (1), does not include 'code_challenge_method' Is that
intentionally?
- I am suggesting to include it to avoid potential questions and
confusion. It could listed as 'optional' as 'scope' is
- In addition, when referencing parameters, they should be spelled as
used in the protocol, i.e.: 'code_challenge' instead of
'code_challenge'

Section 4.1.1 Authorization Request
-

Draft:

"Clients use a unique secret per authorization request to protect  "

- It would be less confusing if this section would start of with "PKCE
is required"
- Introducing a '... unique secret per ...' sounds like something very
new although this is referencing PKCE
- Suggestion (along the lines of):
"Clients MUST leverage PKCE per authorization request to protect ..."

Section 4.1.2.1 Error Response
-

Draft:

"An AS MUST reject requests without a "code_challenge" from public
clients, and MUST reject such requests from other clients  unless
there is reasonable assurance that ..."

- These statements are the ones that cause discussions between
developers and/ or third parties
- ' ... unless ...' is very difficult to grasp, even when looking into
section 9.8
- I would suggest to make it required

Section 5.1 Successful Response
-

Draft and current:

- both documents describe the refresh_token response parameter and
describe it as such:
"OPTIONAL.  The refresh token, which can be used to obtain new access
tokens using the same authorization grant as described in Section 6"

- As an enhancement, I suggest this update:
"OPTIONAL.  The refresh token, which can be used to obtain new access
tokens using the grant type "refresh_token" as described in Section 6"

Section 6. Refreshing an Access Token
-

Draft:

Authorization servers SHOULD determine, based on a risk assessment,
whether to issue refresh tokens to a certain client.  If the
authorization server decides not to issue refresh tokens, the client
MAY refresh access tokens by utilizing other grant types, such as the
authorization code grant type.  In such a case, the authorization
server may utilize cookies and persistent grants to optimize the user
experience.

- That paragraph sounds like a general advice for web developers and
should appear in an appendix for my taste
- ' ... based on risk assessment ... ' may exclude any implementation
that does not have such capabilities

===

Draft:

- this section includes this statement:
"Confidential or credentialed clients MUST authenticate with the
authorization server ..."

- section 2.3 includes this statement and makes me wonder how
confident an authorization server can be when working with
'credentialed' clients':
"However, the authorization server MUST NOT rely on credentialed
client authentication for the purpose of identifying the client."

- Any clarification, I would say about the client type 'credentialed'
in general, would be helpful

-
Typos:
-

Section 2.1. Client Types
-

Draft:

"credentialed":  Clients that have credentials and their identity has
been not been confirmed by the AS are designated as "credentialed
clients"

- I believe it should be:

"credentialed":  Clients that have credentials and their identity has
not been confirmed by the AS are designated as "credentialed clients"

Section 3.2.1 Client Authentication
-

Draft:

"Confidential 

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

[Vladimir Dzhuvinov]

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 client.
> Confidential clients have had their identity confirmed by the AS. We
> talked about changing the names of confidential and public, but
> thought that would be confusing. This new definition cleans up the
> text substantially.

I understand why this new client type was introduced. For the reader who
is not familiar with the recent OAuth RFCs and drafts - I suspect this
can still be confusing. There will likely be questions -- Why does this
difference between confidential and credentialed matter? What is a
concrete example of a credentialed client?

Also, people will likely ask themselves - what does the confirmation of
a (credentialed) client's identity by the AS actually mean and do?
(section 2.1)


>Authorization servers SHOULD consider the level of confidence in a
>client's identity when deciding whether they allow such a client
>access to more critical functions, such as the Client Credentials
>grant type.

Again, normative text that relies on the implementer being able to
assign levels of confidence in the client's identity, but is not
immediately obvious how to go about this.


There is mention in 9.1 about "enlisting the resource owner to confirm
identity" and "if there is a web application whose developer's identity
was verified...". But this talk about client identity is secondary and
happens in the context of client authentication.

Perhaps it will make sense to promote the discussion about identity to a
new 9.x section "Client identity" or "Client Identification", before
"Client Authentication". Addressing the topics what client identity is,
why does it matter (especially for security), and the "confirmation by
the AS". Then proceed with "Client Authentication" which now is freed to
focus on the credentials / auth methods aspects.

>Such credentials are either issued by the
>authorization server or registered by the developer of the client
>with the authorization server.

Credentials (public key) can also be registered by a client performing
dynamic registration (section 2.1)


Vladimir



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Sascha Preibisch]

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 feedback? In this mailing list?

Thanks,
Sascha

On Mon, 6 Jul 2020 at 09:44, Dick Hardt  wrote:
>
> 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:
>
> https://tools.ietf.org/rfcdiff?url2=draft-parecki-oauth-v2-1-03.txt
>
> This version incorporates feedback from the WG, as well as editorial changes 
> to improve readability. Highlights:
>
> - Appendix of current known extensions, and references to the Appendix so 
> that readers become aware of related work.
>
> - defined new client type - credentialed clients - a client that has 
> credentials, but the AS has not confirmed the identity of the client. 
> Confidential clients have had their identity confirmed by the AS. We talked 
> about changing the names of confidential and public, but thought that would 
> be confusing. This new definition cleans up the text substantially.
>
> - consistent use of redirect URI rather than mixing in redirect endpoint URI 
> and redirect endpoint.
>
> - adopted new language on when PKCE is required.
>
> - removed IANA section (nothing new is in 2.1)
>
> / Dick
>
>
>
> ___
> 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

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

[Francis Pouatcha]

The draft  draft-parecki-oauth-v2-1-02 mentions in the abstract:
"This specification replaces and obsoletes the OAuth 2.0
Authorization Framework described in RFC 6749."  Believe me we will witness
a lot of client calls asking for the replacement of ROPC  flows.

There is no way we can omit ROPC without providing an equivalent
alternative (From the perspective of simplicity). Even with the exact match
of redirect-uri included in oAuth-2.1, there is still a lot of hazard
associated with redirection on a user controlled device. The security BCP
(draft-ietf-oauth-security-topics-15) is still far from covering all use
cases as there are too many parameters involved in the redirection thread
models, as redirect-uri travel  through client devices, as client device
operating system decides which url get forwarded to which user agent, as
user default web browser might change in the course of a redirection flow,


The only really secure relationship between a user agent and a server is a
one  time established connection in which the user (RO) in control of
that user agent instance can prove ownership of some credentials without
leaving the context of the loaded application loaded by that user agent. In
oAuth2.0 this behavior is only guaranteed by the ROPC flow (Client
credential flow not being considered an end user flow). Each flow requiring
redirection leads to offloading and reloading of the application context of
the resource owner in the target user agent. User device configuration
might lead to reload in a different user agent leading to more confusion.

RFC8628 does not solve the problem. Once again, it is essential to
distinguish between an oAuth Client and a resource owner (RO). Resource
owner authorization flows can not be replaced by oAuth client
authorizations flows. Even if the oAuth Client runs on the user devices. It
is essential from AS to distinguish between client credentials  and
resource owner credentials, else we will break a lot of authorization
models out there.

As we do not have an equivalent alternative for ROPC, we have to raise the
attention of  implementers by mentioning that ROPC  must only be used if
AS / oAuth Client can guarantee security of the RO credentials exposed to
the oAuth Client. Without this, oAuth2.1 can not be a replacement of
oAuth2.0 but just a security BCP.

Related Topic:
We can have a better theoretical analysis of redirection thread models, if
oAuth2.1 includes draft-ietf-oauth-par-01. As this will solidify
redirection based approaches by limiting the quantity of information pushed
by oAuth Client over client devices to AS.

The oAuth2.1 as presented now is still not secure enough to replace
oAuth2.0-ROPX and not secure enough to be accepted in some critical
environments. In order to increase acceptance:
- Include ROPC  with provision/warning on sharing RO password with oAuth
Client.
- Include PAR to solidify redirection based flow.

On Tue, May 12, 2020 at 3:50 PM Falk Andreas 
wrote:

> > 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.
>
>
> As RFC 6749 clearly targets third-party applications, ROPC never has been
> a good fit.  It always felt like a bad workaround just for legacy
> applications.
>
>
> I am primarily looking at OAuth 2.1 from a developer's perspective.
> Unfortunately, developers often look for a shortcut and the easiest way to
> implement a required use case.
>
> You can find many entries on StackOverflow directing developers to use
> ROPC instead of a "complicated" redirection flow.
>
> Frameworks like Spring Security or Angular clearly follow a "secure by
> default" approach, this may also be a good direction to follow in future
> specifications.
>
>
> As Jim already pointed out, I also consider the ROPC being an
> authentication flow (for trusted first-party applications) and this use
> case is covered by OIDC.
>
>
> Same as for PKCE an AS may still provide ROPC in an OAuth 2.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 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 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 Parecki
>
>
> On Tue, May 12, 2020 at 10:23 AM Francis Pouatc

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

[Falk Andreas]

> 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.


As RFC 6749 clearly targets third-party applications, ROPC never has been a 
good fit.  It always felt like a bad workaround just for legacy applications.


I am primarily looking at OAuth 2.1 from a developer's perspective. 
Unfortunately, developers often look for a shortcut and the easiest way to 
implement a required use case.

You can find many entries on StackOverflow directing developers to use ROPC 
instead of a "complicated" redirection flow.

Frameworks like Spring Security or Angular clearly follow a "secure by default" 
approach, this may also be a good direction to follow in future specifications.


As Jim already pointed out, I also consider the ROPC being an authentication 
flow (for trusted first-party applications) and this use case is covered by 
OIDC.


Same as for PKCE an AS may still provide ROPC in an OAuth 2.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 

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 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 Parecki


On Tue, May 12, 2020 at 10:23 AM Francis Pouatcha 
mailto:40adorsys...@dmarc.ietf.org>> wrote:


On Tue, May 12, 2020 at 9:50 AM Jim Manico 
mailto:j...@manicode.com>> 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 mandating  OAuth2, but about OAuth-2.1 forbidding 
the user of ROPC.


--
Jim Manico
@Manicode

On May 11, 2020, at 11:00 PM, Francis Pouatcha 
mailto:40adorsys...@dmarc.ietf.org>> wrote:


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 agents on non controllable client devices still make user agent 
redirection a challenge.

Client Credentials Grant:
Requires the registration of an oAuth client.
- Citing the iot device use cases Beena which do not have a comfortable way to 
have iot devices register with AS.
- This is a registration flow for the oAuth client role  and for the RO 
(Resource Owner). Remember resource owner credentials might be sourced from 
system external to the AS  like company's LDAP. oAuth Client Credentials are 
generally managed by the AS.
For these reasons, we shall not use Client Credential Grant to manage RO 
authorization.

ROPC:
Having an oAuth Client proxy the auth request of the RO to the AS only presents 
a security risk if the oAuth Client is a third party application. Therefore, 
the decision on whether to accept ROPC for a specified client shall be left to 
the AS. Discarding this use case will take a lot of business from oAuth servers 
back to the old market.

Beside this, I mentioned in my previous post that there are use cases in the 
market where permanent passwords are replaced with one time passwords.

A lot of work is also being done in the direction of having the RO send signed 
proof of ownership to the AS through the ROPC  flow using the password field.

Therefore, I am ok with raising the attention of  implementers the same way we 
are doing with PKCE,  mentioning that ROPC  must only be used if  AS / oAuth 
Client can guarantee security of the RO credentials exposed to the oAuth Client.

/Francis
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
___
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

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

[Aaron Parecki]

> 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 Parecki


On Tue, May 12, 2020 at 10:23 AM Francis Pouatcha  wrote:

>
>
> 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 mandating  OAuth2, but about OAuth-2.1
> forbidding the user of ROPC.
>
>
>> --
>> Jim Manico
>> @Manicode
>>
>> On May 11, 2020, at 11:00 PM, Francis Pouatcha > 40adorsys...@dmarc.ietf.org> wrote:
>>
>> 
>> 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 agents on non controllable client devices still make
>> user agent redirection a challenge.
>>
>> Client Credentials Grant:
>> Requires the registration of an oAuth client.
>> - Citing the iot device use cases Beena which do not have a comfortable
>> way to have iot devices register with AS.
>> - This is a registration flow for the oAuth client role  and for the RO
>> (Resource Owner). Remember resource owner credentials might be sourced from
>> system external to the AS  like company's LDAP. oAuth Client Credentials
>> are generally managed by the AS.
>> For these reasons, we shall not use Client Credential Grant to manage RO
>> authorization.
>>
>> ROPC:
>> Having an oAuth Client proxy the auth request of the RO to the AS only
>> presents a security risk if the oAuth Client is a third party application.
>> Therefore, the decision on whether to accept ROPC for a specified client
>> shall be left to the AS. Discarding this use case will take a lot of
>> business from oAuth servers back to the old market.
>>
>> Beside this, I mentioned in my previous post that there are use cases in
>> the market where permanent passwords are replaced with one time passwords.
>>
>> A lot of work is also being done in the direction of having the RO send
>> signed proof of ownership to the AS through the ROPC  flow using the
>> password field.
>>
>> Therefore, I am ok with raising the attention of  implementers the same
>> way we are doing with PKCE,  mentioning that ROPC  must only be used if  AS
>> / oAuth Client can guarantee security of the RO credentials exposed to the
>> oAuth Client.
>>
>> /Francis
>> --
>> Francis Pouatcha
>> Co-Founder and Technical Lead at adorys
>> https://adorsys-platform.de/solutions/
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
> ___
> 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

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

[Jim Manico]

> 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 Education
+1 (808) 652-3805

> On May 12, 2020, at 1:23 PM, Francis Pouatcha  wrote:
> 
> 
> 
> 
>> 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 mandating  OAuth2, but about OAuth-2.1 
> forbidding the user of ROPC.
> 
>> 
>> --
>> Jim Manico
>> @Manicode
>> 
 On May 11, 2020, at 11:00 PM, Francis Pouatcha 
  wrote:
 
>>> 
>>> 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 agents on non controllable client devices still make 
>>> user agent redirection a challenge. 
>>> 
>>> Client Credentials Grant:
>>> Requires the registration of an oAuth client.
>>> - Citing the iot device use cases Beena which do not have a comfortable way 
>>> to have iot devices register with AS.
>>> - This is a registration flow for the oAuth client role  and for the RO 
>>> (Resource Owner). Remember resource owner credentials might be sourced from 
>>> system external to the AS  like company's LDAP. oAuth Client Credentials 
>>> are generally managed by the AS.
>>> For these reasons, we shall not use Client Credential Grant to manage RO 
>>> authorization.
>>> 
>>> ROPC:
>>> Having an oAuth Client proxy the auth request of the RO to the AS only 
>>> presents a security risk if the oAuth Client is a third party application. 
>>> Therefore, the decision on whether to accept ROPC for a specified client 
>>> shall be left to the AS. Discarding this use case will take a lot of 
>>> business from oAuth servers back to the old market.
>>> 
>>> Beside this, I mentioned in my previous post that there are use cases in 
>>> the market where permanent passwords are replaced with one time passwords.
>>> 
>>> A lot of work is also being done in the direction of having the RO send 
>>> signed proof of ownership to the AS through the ROPC  flow using the 
>>> password field.
>>> 
>>> Therefore, I am ok with raising the attention of  implementers the same way 
>>> we are doing with PKCE,  mentioning that ROPC  must only be used if  AS / 
>>> oAuth Client can guarantee security of the RO credentials exposed to the 
>>> oAuth Client. 
>>> 
>>> /Francis
>>> -- 
>>> Francis Pouatcha
>>> Co-Founder and Technical Lead at adorys
>>> https://adorsys-platform.de/solutions/
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Francis Pouatcha]

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 mandating  OAuth2, but about OAuth-2.1
forbidding the user of ROPC.


> --
> Jim Manico
> @Manicode
>
> On May 11, 2020, at 11:00 PM, Francis Pouatcha  40adorsys...@dmarc.ietf.org> wrote:
>
> 
> 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 agents on non controllable client devices still make
> user agent redirection a challenge.
>
> Client Credentials Grant:
> Requires the registration of an oAuth client.
> - Citing the iot device use cases Beena which do not have a comfortable
> way to have iot devices register with AS.
> - This is a registration flow for the oAuth client role  and for the RO
> (Resource Owner). Remember resource owner credentials might be sourced from
> system external to the AS  like company's LDAP. oAuth Client Credentials
> are generally managed by the AS.
> For these reasons, we shall not use Client Credential Grant to manage RO
> authorization.
>
> ROPC:
> Having an oAuth Client proxy the auth request of the RO to the AS only
> presents a security risk if the oAuth Client is a third party application..
> Therefore, the decision on whether to accept ROPC for a specified client
> shall be left to the AS. Discarding this use case will take a lot of
> business from oAuth servers back to the old market.
>
> Beside this, I mentioned in my previous post that there are use cases in
> the market where permanent passwords are replaced with one time passwords..
>
> A lot of work is also being done in the direction of having the RO send
> signed proof of ownership to the AS through the ROPC  flow using the
> password field.
>
> Therefore, I am ok with raising the attention of  implementers the same
> way we are doing with PKCE,  mentioning that ROPC  must only be used if  AS
> / oAuth Client can guarantee security of the RO credentials exposed to the
> oAuth Client.
>
> /Francis
> --
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Jim Manico]

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 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 agents on non controllable client devices still make user agent 
> redirection a challenge. 
> 
> Client Credentials Grant:
> Requires the registration of an oAuth client.
> - Citing the iot device use cases Beena which do not have a comfortable way 
> to have iot devices register with AS.
> - This is a registration flow for the oAuth client role  and for the RO 
> (Resource Owner). Remember resource owner credentials might be sourced from 
> system external to the AS  like company's LDAP. oAuth Client Credentials are 
> generally managed by the AS.
> For these reasons, we shall not use Client Credential Grant to manage RO 
> authorization.
> 
> ROPC:
> Having an oAuth Client proxy the auth request of the RO to the AS only 
> presents a security risk if the oAuth Client is a third party application. 
> Therefore, the decision on whether to accept ROPC for a specified client 
> shall be left to the AS. Discarding this use case will take a lot of business 
> from oAuth servers back to the old market.
> 
> Beside this, I mentioned in my previous post that there are use cases in the 
> market where permanent passwords are replaced with one time passwords.
> 
> A lot of work is also being done in the direction of having the RO send 
> signed proof of ownership to the AS through the ROPC  flow using the password 
> field.
> 
> Therefore, I am ok with raising the attention of  implementers the same way 
> we are doing with PKCE,  mentioning that ROPC  must only be used if  AS / 
> oAuth Client can guarantee security of the RO credentials exposed to the 
> oAuth Client. 
> 
> /Francis
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
> ___
> 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

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

[Dominick Baier]

In IdentityServer, the PKCE requirement is per client.

We started with a default of false - and now switched to true.

FWIW
———
Dominick Baier

On 10. May 2020 at 22:22:35, Mike Jones (
michael.jones=40microsoft@dmarc.ietf.org) wrote:

Exactly!



I believe that this also the same point that Brian Campbell was making
earlier about interoperability implications.



   -- Mike



*From:* Neil Madden 
*Sent:* Sunday, May 10, 2020 1:06 PM
*To:* Dick Hardt 
*Cc:* Mike Jones ; oauth@ietf.org; Torsten
Lodderstedt 
*Subject:* Re: [OAUTH-WG] Re: OAuth 2.1 - require PKCE?



But if an AS upgrades to OAuth 2.1 then it MUST reject authorization
requests that don’t include a code_challenge (section 4.1.2.1), so this
will only be possible when all clients support PKCE.



This makes it impossible for a 2.1-compliant AS to also support non-PKCE
2.0 clients (i.e., the vast majority of them).



I think we can have a 2.1 spec that says clients and servers MUST support
PKCE without this hard-fail clause. Otherwise I can’t see how we’d ever
ship with 2.1-compliance enabled out-of-the-box.



— Neil



On 10 May 2020, at 20:38, Dick Hardt  wrote:



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 OAuth
2.0 was voluntary.



Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?





On Sun, May 10, 2020 at 12:02 PM Mike Jones  wrote:

I agree with actively maintaining and improving the OAuth 2.0 specs by
adding enhancements that are voluntary to use.  I’ve worked on many such
improvements, including Dynamic Client Registration, Authorization
Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR,
etc.  The issue that’s the subject is the current discussion is whether to
make use of another enhancement, PKCE, mandatory in cases where it’s
actually not needed, rather than making its use voluntary like the other
enhancements, which I certainly support.



   -- 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 introduce breaking changes.

I cannot remember the WG met that decision. Can you please refer to the
respective thread?



Requiring exact redirect URI matching is already a breaking change. Do you
oppose against this as well?





If you want to do that, please do it in TxAuth instead.



Interesting statement. Does it mean you want to conserve OAuth 2.0 and
force any enhancements/improvements to go into TXAuth? This would cause
huge migration efforts for existing deployments wanting to benefit from
those enhancements.



I think existing deployments are better served by actively maintaining and
evolving the 2.x line. For example, PAR and RAR are attempts to improve
OAuth 2.x and make it usable for new use cases. That’s better protection of
existing investments than sending them of to TXAuth.

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?



+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 nonce, then you don't need PKCE,
except if you are a public client, then you still need PKCE.

- use state, except if you use PKCE, then you don't need state.



I think there are very good reasons to simplify this down to



- use PKCE

- you may or may not use state



First and foremost, not many people will understand why there are cases
when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
understanding *why* you have to do something is key to compliance. The
short version "PKCE protects the code; there is a specific case where it is
not needed, but its better to use it all the time" is easy to understand.
We will not see many implementations following the long version above
correctly.



Second, we dramatically reduce technical complexity by reducing cases that
need to be handled. We reduce correctness and compliance testing complexity
in the same way. We reduce the cost of security analysis, which scales
really badly to more cases.



And finally, using nonce to protect against code injection is less robust
than PKCE. AS have a better track record than clients when it comes to
correctly implementing security mechanisms.



Yes, this will make a number of implementations non-spec-compliant

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

[Torsten Lodderstedt]

> 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 client and must be enforced 
by the client - just like nonce. 

That might work with a confidential client, but in case of a public client, the 
attacker does not need to inject the code in order to redeem it. The attacker 
can just directly redeem the code for an access token without checking c_hash 
or nonce.

> I’d be interested in hearing John Bradley’s take on this.
>  
>-- Mike
>  
> From: Torsten Lodderstedt  
> Sent: Sunday, May 10, 2020 3:17 AM
> To: Mike Jones 
> Cc: Aaron Parecki ; Dick Hardt ; 
> OAuth WG 
> Subject: Re: 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 unnecessarily bifurcating the ecosystem into non-interoperable segments.  
> OAuth 2.1 should facilitate the already secure OAuth 2.0 deployments 
> remaining part of the interoperable OAuth 2.1 set of deployments – not 
> intentionally doing the opposite.
>  
> If it ain’t broke, don’t fix it!
> Did I got it right that nonce does not protect public clients from code 
> theft/replay? I would consider this a security issue.
>  
>-- Mike
>  
> From: Aaron Parecki  
> Sent: Friday, May 8, 2020 8:34 PM
> To: OAuth WG 
> Cc: Dick Hardt ; Torsten Lodderstedt 
> ; Mike Jones 
> Subject: Re: 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 hundreds or 
> thousands of deployed OpenID Connect RPs won’t have to change their 
> deployments.  That’s optimizing for interoperability and minimizing the 
> burden on developers, which are far more important.
>  
> I appreciate the concern about optimizing for spec simplicity. I also agree 
> that spec simplicity should not necessarily be the driving goal.
>  
> However, what you've described is the opposite of interoperability and 
> minimizing the burden on developers. Requiring PKCE in OAuth 2.1, without any 
> exceptions, will optimize for interoperability between OAuth 2.1 clients and 
> servers. Without the requirement of PKCE, there will always be the question 
> of "but does this OAuth 2.1 client work with this OAuth 2.1 server or not?", 
> which will only be able to be answered by investigating the docs to look for 
> PKCE support, or by checking the AS metadata document if it publishes one 
> (which it is not required to do).
>  
> Optimizing for interoperability and minimizing the burden on developers is 
> absolutely a good goal, and requiring PKCE is a great way to accomplish that. 
> OAuth 2.0 and OpenID Connect implementations that don't support PKCE will 
> continue to work as they currently do, they just won't be able to call 
> themselves OAuth 2.1 compliant, just as is the case as if they don't follow 
> the other recommendations that are in OAuth 2.1 and the Security BCP.
>  
> Aaron 
>  
>  
> On Thu, May 7, 2020 at 6:42 PM Mike Jones  wrote:
> 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 hundreds or 
> thousands of deployed OpenID Connect RPs won’t have to change their 
> deployments.  That’s optimizing for interoperability and minimizing the 
> burden on developers, which are far more important.
>  
> As Brian Campbell wrote, “They are not equivalent and have very different 
> ramifications on interoperability”.
>  
> Even if you’re optimizing for writing, taking a minimally invasive protocol 
> change approach will optimize that, overall.  If we proceed as you’re 
> suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
> SlashDot, blogs, and other developer forums, where confused developers will 
> ask “Why do I have to change my deployed code?” with the answers being 
> “Despite what the 2.1 spec says, there’s no need to change your deployed 
> code.”
>  
> I’d gladly write a few sentences in our new specs now to prevent ongoing 
> confusion and interop problems that would otherwise result.  Let me know when 
> you’re ready to incorporate them into 

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

[Benjamin Kaduk]

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 has not been changed in a while is probably
> not one you would want to use anyway. We are setting a new goal for
> implementations to meet and eventually, maintained implementations will
> get there.

It's probably worth an occasional reminder that though this is true for the
web-facing software most of us work on, it's not actually universally true
for *all* software.  Things that are rated as safety-critical software, or
the SCADA systems running billion-dollar industrial processes that only
take downtime for hardware upgrades, are written in a rather different
ecosystem.  :)

-Ben

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

We are NOT saying that an OAuth 2.0 compatible server is OAuth 2.1
compatible. For example, an OAuth 2.0 compatible server does not have to
support PKCE, support the implicit grant, support the Resource Owner
Password Credentials grant, support bearer tokens in the query string of
the URI, etc.
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-12

 We have stated the goal to be OAuth 2.0 with best practices. As noted
earlier, we are now discussing what is best practices.

Per my other email, no one is requiring a deployment to upgrade, and a
deployment may support both legacy OAuth 2.0 clients, and OAuth 2.1 clients
at the same time. We can add some non-normative text to explain that if you
like.

On Sun, May 10, 2020 at 1:24 PM Mike Jones 
wrote:

> The difference is that OAuth 2.1 is supposed to compatible with OAuth 2.0
> (which is my whole goal here), whereas 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 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 practices.
>
>
>
> If existing deployments don't want the advantages of a new version or
> extension, there is nobody forcing them to upgrade -- hence my confusion on
> your statement that it is "mandatory". Upgrading to OAuth 2.0 from OAuth
> 1.0 was not mandatory, and some deployments still use OAuth 1.0 today.
>
>
>
>
>
>
>
> ᐧ
>
>
>
> On Sun, May 10, 2020 at 12:51 PM Mike Jones 
> wrote:
>
> If I’m not mistaken, the OAuth 2.1 draft is intended to make OAuth 2.0
> (RFC 6749) obsolete, just like OAuth 2.0 (RFC 6749) made OAuth 1.0 (RFC
> 5849) obsolete.  That’s what makes me think developers would view updating
> as mandatory.  If you’re willing to remove the “replaces 6749” clause from
> 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 - 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 OAuth
> 2.0 was voluntary.
>
>
>
> Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?
>
>
>
>
>
> On Sun, May 10, 2020 at 12:02 PM Mike Jones  40microsoft@dmarc.ietf.org> wrote:
>
> I agree with actively maintaining and improving the OAuth 2.0 specs by
> adding enhancements that are voluntary to use.  I’ve worked on many such
> improvements, including Dynamic Client Registration, Authorization
> Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR,
> etc.  The issue that’s the subject is the current discussion is whether to
> make use of another enhancement, PKCE, mandatory in cases where it’s
> actually not needed, rather than making its use voluntary like the other
> enhancements, which I certainly support.
>
>
>
>-- 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 introduce breaking changes.
>
> I cannot remember the WG met that decision. Can you please refer to the
> respective thread?
>
>
>
> Requiring exact redirect URI matching is already a breaking change. Do you
> oppose against this as well?
>
>
>
>
>
> If you want to do that, please do it in TxAuth instead.
>
>
>
> Interesting statement. Does it mean you want to conserve OAuth 2.0 and
> force any enhancements/improvements to go into TXAuth? This would cause
> huge migration efforts for existing deployments wanting to benefit from
> those enhancements.
>
>
>
> I think existing deployments are better served by actively maintaining and
> evolving the 2.x line. For example, PAR and RAR are attempts to improve
> OAuth 2.x and make it usable for new use cases. That’s better protection of
> existing investments than se

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

[Mike Jones]

The difference is that OAuth 2.1 is supposed to compatible with OAuth 2.0 
(which is my whole goal here), whereas 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 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 
practices.

If existing deployments don't want the advantages of a new version or 
extension, there is nobody forcing them to upgrade -- hence my confusion on 
your statement that it is "mandatory". Upgrading to OAuth 2.0 from OAuth 1.0 
was not mandatory, and some deployments still use OAuth 1.0 today.



ᐧ

On Sun, May 10, 2020 at 12:51 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
If I’m not mistaken, the OAuth 2.1 draft is intended to make OAuth 2.0 (RFC 
6749) obsolete, just like OAuth 2.0 (RFC 6749) made OAuth 1.0 (RFC 5849) 
obsolete.  That’s what makes me think developers would view updating as 
mandatory.  If you’re willing to remove the “replaces 6749” clause from 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 mailto:dick.ha...@gmail.com>>
Sent: Sunday, May 10, 2020 12:38 PM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>>; 
oauth@ietf.org<mailto: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 OAuth 2.0 was 
voluntary.

Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?


On Sun, May 10, 2020 at 12:02 PM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
I agree with actively maintaining and improving the OAuth 2.0 specs by adding 
enhancements that are voluntary to use.  I’ve worked on many such improvements, 
including Dynamic Client Registration, Authorization Metadata, the Device Flow, 
Token Exchange, DPoP, and support PAR and RAR, etc.  The issue that’s the 
subject is the current discussion is whether to make use of another 
enhancement, PKCE, mandatory in cases where it’s actually not needed, rather 
than making its use voluntary like the other enhancements, which I certainly 
support.

   -- Mike

From: Torsten Lodderstedt 
mailto:40lodderstedt@dmarc.ietf.org>>
Sent: Sunday, May 10, 2020 3:15 AM
To: Mike Jones mailto:michael.jo...@microsoft.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 to not introduce breaking changes.
I cannot remember the WG met that decision. Can you please refer to the 
respective thread?

Requiring exact redirect URI matching is already a breaking change. Do you 
oppose against this as well?


If you want to do that, please do it in TxAuth instead.

Interesting statement. Does it mean you want to conserve OAuth 2.0 and force 
any enhancements/improvements to go into TXAuth? This would cause huge 
migration efforts for existing deployments wanting to benefit from those 
enhancements.

I think existing deployments are better served by actively maintaining and 
evolving the 2.x line. For example, PAR and RAR are attempts to improve OAuth 
2.x and make it usable for new use cases. That’s better protection of existing 
investments than sending them of to TXAuth.
Kind regards,
Torsten.


   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Daniel Fett
Sent: Thursday, May 7, 2020 11:50 PM
To: oauth@ietf.org<mailto: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 current recommendation on the 
usage of nonce).

We would then have:

- use PKCE, except if you use OIDC with a nonce, then you don't need PKCE, 
except if you are a public client, then you still need PKCE.
- use state, except if you use PKCE, then you don't need state.

I think there are very good reasons to simplify this down to

- use PKCE
- you may or may not use state

First and foremost, not many people will understand why there are cases when 
the BCP/OAuth 2.1 mandate PKCE and some where they don

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

[Mike Jones]

Exactly!

I believe that this also the same point that Brian Campbell was making earlier 
about interoperability implications.

   -- Mike

From: Neil Madden 
Sent: Sunday, May 10, 2020 1:06 PM
To: Dick Hardt 
Cc: Mike Jones ; oauth@ietf.org; Torsten 
Lodderstedt 
Subject: Re: [OAUTH-WG] Re: OAuth 2.1 - require PKCE?

But if an AS upgrades to OAuth 2.1 then it MUST reject authorization requests 
that don’t include a code_challenge (section 4.1.2.1), so this will only be 
possible when all clients support PKCE.

This makes it impossible for a 2.1-compliant AS to also support non-PKCE 2.0 
clients (i.e., the vast majority of them).

I think we can have a 2.1 spec that says clients and servers MUST support PKCE 
without this hard-fail clause. Otherwise I can’t see how we’d ever ship with 
2.1-compliance enabled out-of-the-box.

— Neil

On 10 May 2020, at 20:38, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

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 OAuth 2.0 was 
voluntary.

Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?


On Sun, May 10, 2020 at 12:02 PM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
I agree with actively maintaining and improving the OAuth 2.0 specs by adding 
enhancements that are voluntary to use.  I’ve worked on many such improvements, 
including Dynamic Client Registration, Authorization Metadata, the Device Flow, 
Token Exchange, DPoP, and support PAR and RAR, etc.  The issue that’s the 
subject is the current discussion is whether to make use of another 
enhancement, PKCE, mandatory in cases where it’s actually not needed, rather 
than making its use voluntary like the other enhancements, which I certainly 
support.

   -- Mike

From: Torsten Lodderstedt 
mailto:40lodderstedt@dmarc.ietf.org>>
Sent: Sunday, May 10, 2020 3:15 AM
To: Mike Jones mailto:michael.jo...@microsoft.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 to not introduce breaking changes.
I cannot remember the WG met that decision. Can you please refer to the 
respective thread?

Requiring exact redirect URI matching is already a breaking change. Do you 
oppose against this as well?


If you want to do that, please do it in TxAuth instead.

Interesting statement. Does it mean you want to conserve OAuth 2.0 and force 
any enhancements/improvements to go into TXAuth? This would cause huge 
migration efforts for existing deployments wanting to benefit from those 
enhancements.

I think existing deployments are better served by actively maintaining and 
evolving the 2.x line. For example, PAR and RAR are attempts to improve OAuth 
2.x and make it usable for new use cases. That’s better protection of existing 
investments than sending them of to TXAuth.
Kind regards,
Torsten.


   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Daniel Fett
Sent: Thursday, May 7, 2020 11:50 PM
To: oauth@ietf.org<mailto: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 current recommendation on the 
usage of nonce).

We would then have:

- use PKCE, except if you use OIDC with a nonce, then you don't need PKCE, 
except if you are a public client, then you still need PKCE.
- use state, except if you use PKCE, then you don't need state.

I think there are very good reasons to simplify this down to

- use PKCE
- you may or may not use state

First and foremost, not many people will understand why there are cases when 
the BCP/OAuth 2.1 mandate PKCE and some where they don't. However, 
understanding why you have to do something is key to compliance. The short 
version "PKCE protects the code; there is a specific case where it is not 
needed, but its better to use it all the time" is easy to understand. We will 
not see many implementations following the long version above correctly.

Second, we dramatically reduce technical complexity by reducing cases that need 
to be handled. We reduce correctness and compliance testing complexity in the 
same way. We reduce the cost of security analysis, which scales really badly to 
more cases.

And finally, using nonce to protect against code injection is less robust than 
PKCE. AS have a better track record than clients when it comes to correctly 
implementing security mechanisms.

Yes, this will make a n

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

[Dick Hardt]

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 practices.

If existing deployments don't want the advantages of a new version or
extension, there is nobody forcing them to upgrade -- hence my confusion on
your statement that it is "mandatory". Upgrading to OAuth 2.0 from OAuth
1.0 was not mandatory, and some deployments still use OAuth 1.0 today.



ᐧ

On Sun, May 10, 2020 at 12:51 PM Mike Jones 
wrote:

> If I’m not mistaken, the OAuth 2.1 draft is intended to make OAuth 2.0
> (RFC 6749) obsolete, just like OAuth 2.0 (RFC 6749) made OAuth 1.0 (RFC
> 5849) obsolete.  That’s what makes me think developers would view updating
> as mandatory.  If you’re willing to remove the “replaces 6749” clause from
> 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 - 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 OAuth
> 2.0 was voluntary.
>
>
>
> Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?
>
>
>
>
>
> On Sun, May 10, 2020 at 12:02 PM Mike Jones  40microsoft@dmarc.ietf.org> wrote:
>
> I agree with actively maintaining and improving the OAuth 2.0 specs by
> adding enhancements that are voluntary to use.  I’ve worked on many such
> improvements, including Dynamic Client Registration, Authorization
> Metadata, the Device Flow, Token Exchange, DPoP, and support PAR and RAR,
> etc.  The issue that’s the subject is the current discussion is whether to
> make use of another enhancement, PKCE, mandatory in cases where it’s
> actually not needed, rather than making its use voluntary like the other
> enhancements, which I certainly support.
>
>
>
>-- 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 introduce breaking changes.
>
> I cannot remember the WG met that decision. Can you please refer to the
> respective thread?
>
>
>
> Requiring exact redirect URI matching is already a breaking change. Do you
> oppose against this as well?
>
>
>
>
>
> If you want to do that, please do it in TxAuth instead.
>
>
>
> Interesting statement. Does it mean you want to conserve OAuth 2.0 and
> force any enhancements/improvements to go into TXAuth? This would cause
> huge migration efforts for existing deployments wanting to benefit from
> those enhancements.
>
>
>
> I think existing deployments are better served by actively maintaining and
> evolving the 2.x line. For example, PAR and RAR are attempts to improve
> OAuth 2.x and make it usable for new use cases. That’s better protection of
> existing investments than sending them of to TXAuth.
>
> 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?
>
>
>
> +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 nonce, then you don't need PKCE,
> except if you are a public client, then you still need PKCE.
>
> - use state, except if you use PKCE, then you don't need state.
>
>
>
> I think there are very good reasons to simplify this down to
>
>
>
> - use PKCE
>
> - you may or may not use state
>
>
>
> First and foremost, not many people will understand why there are cases
> when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
> understanding *why* you have to do something is key to compliance. The
> short versio

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

[Mike Jones]

If I’m not mistaken, the OAuth 2.1 draft is intended to make OAuth 2.0 (RFC 
6749) obsolete, just like OAuth 2.0 (RFC 6749) made OAuth 1.0 (RFC 5849) 
obsolete.  That’s what makes me think developers would view updating as 
mandatory.  If you’re willing to remove the “replaces 6749” clause from 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 - 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 OAuth 2.0 was 
voluntary.

Would you clarify why you think upgrading to OAuth 2.1 would be mandatory?


On Sun, May 10, 2020 at 12:02 PM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
I agree with actively maintaining and improving the OAuth 2.0 specs by adding 
enhancements that are voluntary to use.  I’ve worked on many such improvements, 
including Dynamic Client Registration, Authorization Metadata, the Device Flow, 
Token Exchange, DPoP, and support PAR and RAR, etc.  The issue that’s the 
subject is the current discussion is whether to make use of another 
enhancement, PKCE, mandatory in cases where it’s actually not needed, rather 
than making its use voluntary like the other enhancements, which I certainly 
support.

   -- Mike

From: Torsten Lodderstedt 
mailto:40lodderstedt@dmarc.ietf.org>>
Sent: Sunday, May 10, 2020 3:15 AM
To: Mike Jones mailto:michael.jo...@microsoft.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 to not introduce breaking changes.
I cannot remember the WG met that decision. Can you please refer to the 
respective thread?

Requiring exact redirect URI matching is already a breaking change. Do you 
oppose against this as well?


If you want to do that, please do it in TxAuth instead.

Interesting statement. Does it mean you want to conserve OAuth 2.0 and force 
any enhancements/improvements to go into TXAuth? This would cause huge 
migration efforts for existing deployments wanting to benefit from those 
enhancements.

I think existing deployments are better served by actively maintaining and 
evolving the 2.x line. For example, PAR and RAR are attempts to improve OAuth 
2.x and make it usable for new use cases. That’s better protection of existing 
investments than sending them of to TXAuth.
Kind regards,
Torsten.


   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Daniel Fett
Sent: Thursday, May 7, 2020 11:50 PM
To: oauth@ietf.org<mailto: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 current recommendation on the 
usage of nonce).

We would then have:

- use PKCE, except if you use OIDC with a nonce, then you don't need PKCE, 
except if you are a public client, then you still need PKCE.
- use state, except if you use PKCE, then you don't need state.

I think there are very good reasons to simplify this down to

- use PKCE
- you may or may not use state

First and foremost, not many people will understand why there are cases when 
the BCP/OAuth 2.1 mandate PKCE and some where they don't. However, 
understanding why you have to do something is key to compliance. The short 
version "PKCE protects the code; there is a specific case where it is not 
needed, but its better to use it all the time" is easy to understand. We will 
not see many implementations following the long version above correctly.

Second, we dramatically reduce technical complexity by reducing cases that need 
to be handled. We reduce correctness and compliance testing complexity in the 
same way. We reduce the cost of security analysis, which scales really badly to 
more cases.

And finally, using nonce to protect against code injection is less robust than 
PKCE. AS have a better track record than clients when it comes to correctly 
implementing security mechanisms.

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 has not been changed in a while is probably not one you would 
want to use anyway. We are setting a new goal for implementations to meet and 
eventually, maintained implementations will get there.

-Daniel


Am 

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

[Mike Jones]

> 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

From: Torsten Lodderstedt 
Sent: Sunday, May 10, 2020 3:17 AM
To: Mike Jones 
Cc: Aaron Parecki ; Dick Hardt ; OAuth 
WG 
Subject: Re: OAuth 2.1 - require PKCE?

Mike Jones mailto:michael.jo...@microsoft.com>> 
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 unnecessarily bifurcating the ecosystem into non-interoperable segments.  
OAuth 2.1 should facilitate the already secure OAuth 2.0 deployments remaining 
part of the interoperable OAuth 2.1 set of deployments – not intentionally 
doing the opposite.

If it ain’t broke, don’t fix it!
Did I got it right that nonce does not protect public clients from code 
theft/replay? I would consider this a security issue.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Friday, May 8, 2020 8:34 PM
To: OAuth WG mailto:oauth@ietf.org>>
Cc: Dick Hardt mailto:dick.ha...@gmail.com>>; Torsten 
Lodderstedt mailto:tors...@lodderstedt.net>>; Mike 
Jones mailto:michael.jo...@microsoft.com>>
Subject: Re: 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 hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

I appreciate the concern about optimizing for spec simplicity. I also agree 
that spec simplicity should not necessarily be the driving goal.

However, what you've described is the opposite of interoperability and 
minimizing the burden on developers. Requiring PKCE in OAuth 2.1, without any 
exceptions, will optimize for interoperability between OAuth 2.1 clients and 
servers. Without the requirement of PKCE, there will always be the question of 
"but does this OAuth 2.1 client work with this OAuth 2.1 server or not?", which 
will only be able to be answered by investigating the docs to look for PKCE 
support, or by checking the AS metadata document if it publishes one (which it 
is not required to do).

Optimizing for interoperability and minimizing the burden on developers is 
absolutely a good goal, and requiring PKCE is a great way to accomplish that. 
OAuth 2.0 and OpenID Connect implementations that don't support PKCE will 
continue to work as they currently do, they just won't be able to call 
themselves OAuth 2.1 compliant, just as is the case as if they don't follow the 
other recommendations that are in OAuth 2.1 and the Security BCP.

Aaron


On Thu, May 7, 2020 at 6:42 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
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 hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

As Brian Campbell wrote, “They are not equivalent and have very different 
ramifications on interoperability”.

Even if you’re optimizing for writing, taking a minimally invasive protocol 
change approach will optimize that, overall.  If we proceed as you’re 
suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
SlashDot, blogs, and other developer forums, where confused developers will ask 
“Why do I have to change my deployed code?” with the answers being “Despite 
what the 2.1 spec says, there’s no need to change your deployed code.”

I’d gladly write a few sentences in our new specs now to prevent ongoing 
confusion and interop problems that would otherwise result.  Let me know when 
you’re ready to incorporate them into the spec text.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Thursday, May 7, 2020 4:39 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: OAuth WG mailto:oauth@ietf.org>>; Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>>; Mike Jones 
mailto:michael.jo...@microsoft.com>>
Subject: Re: OAuth 2.1 - require PKCE?

Backing up a 

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

[Torsten Lodderstedt]

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 unnecessarily bifurcating the ecosystem into
> non-interoperable segments.  OAuth 2.1 should facilitate the already secure
> OAuth 2.0 deployments remaining part of the interoperable OAuth 2.1 set of
> deployments – not intentionally doing the opposite.
>
>
>
> If it ain’t broke, don’t fix it!
>
Did I got it right that nonce does not protect public clients from code
theft/replay? I would consider this a security issue.

>
>
>-- Mike
>
>
>
> *From:* Aaron Parecki 
> *Sent:* Friday, May 8, 2020 8:34 PM
> *To:* OAuth WG 
> *Cc:* Dick Hardt ; Torsten Lodderstedt <
> tors...@lodderstedt.net>; Mike Jones 
> *Subject:* Re: 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 hundreds or thousands of deployed OpenID Connect RPs won’t
> have to change their deployments.  That’s optimizing for interoperability
> and minimizing the burden on developers, which are far more important.
>
>
>
> I appreciate the concern about optimizing for spec simplicity. I also
> agree that spec simplicity should not necessarily be the driving goal.
>
>
>
> However, what you've described is the opposite of interoperability and
> minimizing the burden on developers. Requiring PKCE in OAuth 2.1, without
> any exceptions, will optimize for interoperability between OAuth 2.1
> clients and servers. Without the requirement of PKCE, there will always be
> the question of "but does this OAuth 2.1 client work with this OAuth 2.1
> server or not?", which will only be able to be answered by investigating
> the docs to look for PKCE support, or by checking the AS metadata document
> if it publishes one (which it is not required to do).
>
>
>
> Optimizing for interoperability and minimizing the burden on developers is
> absolutely a good goal, and requiring PKCE is a great way to accomplish
> that. OAuth 2.0 and OpenID Connect implementations that don't support PKCE
> will continue to work as they currently do, they just won't be able to call
> themselves OAuth 2.1 compliant, just as is the case as if they don't follow
> the other recommendations that are in OAuth 2.1 and the Security BCP.
>
>
>
> Aaron
>
>
>
>
>
> On Thu, May 7, 2020 at 6:42 PM Mike Jones 
> wrote:
>
> 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 hundreds or thousands of deployed OpenID Connect RPs won’t
> have to change their deployments.  That’s optimizing for interoperability
> and minimizing the burden on developers, which are far more important.
>
>
>
> As Brian Campbell wrote, “They are not equivalent and have very different
> ramifications on interoperability”.
>
>
>
> Even if you’re optimizing for writing, taking a minimally invasive
> protocol change approach will optimize that, overall.  If we proceed as
> you’re suggesting, a huge amount of writing will occur on StackOverflow,
> Medium, SlashDot, blogs, and other developer forums, where confused
> developers will ask “Why do I have to change my deployed code?” with the
> answers being “Despite what the 2.1 spec says, there’s no need to change
> your deployed code.”
>
>
>
> I’d gladly write a few sentences in our new specs now to prevent ongoing
> confusion and interop problems that would otherwise result.  Let me know
> when you’re ready to incorporate them into the spec text.
>
>
>
>-- Mike
>
>
>
> *From:* Aaron Parecki 
> *Sent:* Thursday, May 7, 2020 4:39 PM
> *To:* Dick Hardt 
> *Cc:* OAuth WG ; Torsten Lodderstedt <
> tors...@lodderstedt.net>; Mike Jones 
> *Subject:* Re: 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 so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
>
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public 

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

[Torsten Lodderstedt]

Hi Mike,

Mike Jones  schrieb am Fr. 8.
Mai 2020 um 18:55:

> OAuth 2.1 was supposed to not introduce breaking changes.
>
I cannot remember the WG met that decision. Can you please refer to the
respective thread?

Requiring exact redirect URI matching is already a breaking change. Do you
oppose against this as well?


If you want to do that, please do it in TxAuth instead.
>

Interesting statement. Does it mean you want to conserve OAuth 2.0 and
force any enhancements/improvements to go into TXAuth? This would cause
huge migration efforts for existing deployments wanting to benefit from
those enhancements.

I think existing deployments are better served by actively maintaining and
evolving the 2.x line. For example, PAR and RAR are attempts to improve
OAuth 2.x and make it usable for new use cases. That’s better protection of
existing investments than sending them of to TXAuth.

> 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?
>
>
>
> +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 nonce, then you don't need PKCE,
> except if you are a public client, then you still need PKCE.
>
> - use state, except if you use PKCE, then you don't need state.
>
>
>
> I think there are very good reasons to simplify this down to
>
>
>
> - use PKCE
>
> - you may or may not use state
>
>
>
> First and foremost, not many people will understand why there are cases
> when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
> understanding *why* you have to do something is key to compliance. The
> short version "PKCE protects the code; there is a specific case where it is
> not needed, but its better to use it all the time" is easy to understand.
> We will not see many implementations following the long version above
> correctly.
>
>
>
> Second, we dramatically reduce technical complexity by reducing cases that
> need to be handled. We reduce correctness and compliance testing complexity
> in the same way. We reduce the cost of security analysis, which scales
> really badly to more cases.
>
>
>
> And finally, using nonce to protect against code injection is less robust
> than PKCE. AS have a better track record than clients when it comes to
> correctly implementing security mechanisms.
>
>
>
> 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 has not been changed in a while is probably not
> one you would want to use anyway. We are setting a new goal for
> implementations to meet and eventually, maintained implementations will get
> there.
>
>
>
> -Daniel
>
>
>
>
>
> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>
> 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 so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
>
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE as
> well.
>
>
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
>
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
>
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP for
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>

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

[Mike Jones]

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-interoperable segments.  
OAuth 2.1 should facilitate the already secure OAuth 2.0 deployments remaining 
part of the interoperable OAuth 2.1 set of deployments – not intentionally 
doing the opposite.

If it ain’t broke, don’t fix it!

   -- Mike

From: Aaron Parecki 
Sent: Friday, May 8, 2020 8:34 PM
To: OAuth WG 
Cc: Dick Hardt ; Torsten Lodderstedt 
; Mike Jones 
Subject: Re: 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 hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

I appreciate the concern about optimizing for spec simplicity. I also agree 
that spec simplicity should not necessarily be the driving goal.

However, what you've described is the opposite of interoperability and 
minimizing the burden on developers. Requiring PKCE in OAuth 2.1, without any 
exceptions, will optimize for interoperability between OAuth 2.1 clients and 
servers. Without the requirement of PKCE, there will always be the question of 
"but does this OAuth 2.1 client work with this OAuth 2.1 server or not?", which 
will only be able to be answered by investigating the docs to look for PKCE 
support, or by checking the AS metadata document if it publishes one (which it 
is not required to do).

Optimizing for interoperability and minimizing the burden on developers is 
absolutely a good goal, and requiring PKCE is a great way to accomplish that. 
OAuth 2.0 and OpenID Connect implementations that don't support PKCE will 
continue to work as they currently do, they just won't be able to call 
themselves OAuth 2.1 compliant, just as is the case as if they don't follow the 
other recommendations that are in OAuth 2.1 and the Security BCP.

Aaron


On Thu, May 7, 2020 at 6:42 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
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 hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

As Brian Campbell wrote, “They are not equivalent and have very different 
ramifications on interoperability”.

Even if you’re optimizing for writing, taking a minimally invasive protocol 
change approach will optimize that, overall.  If we proceed as you’re 
suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
SlashDot, blogs, and other developer forums, where confused developers will ask 
“Why do I have to change my deployed code?” with the answers being “Despite 
what the 2.1 spec says, there’s no need to change your deployed code.”

I’d gladly write a few sentences in our new specs now to prevent ongoing 
confusion and interop problems that would otherwise result.  Let me know when 
you’re ready to incorporate them into the spec text.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Thursday, May 7, 2020 4:39 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: OAuth WG mailto:oauth@ietf.org>>; Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>>; Mike Jones 
mailto:michael.jo...@microsoft.com>>
Subject: Re: 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 so far. The quoted section of the 
security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client requests 
an ID token. Public clients using the nonce parameter are still susceptible to 
stolen authorization codes so they still need to do PKCE as well.

The only case where OpenID Connect clients don't benefit from PKCE is if they 
are also confidential clients. Public client OIDC clients 

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

[Aaron Parecki]

>
> 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 hundreds or thousands of deployed OpenID Connect RPs won’t
> have to change their deployments.  That’s optimizing for interoperability
> and minimizing the burden on developers, which are far more important.


I appreciate the concern about optimizing for spec simplicity. I also agree
that spec simplicity should not necessarily be the driving goal.

However, what you've described is the opposite of interoperability and
minimizing the burden on developers. Requiring PKCE in OAuth 2.1, without
any exceptions, will optimize for interoperability between OAuth 2.1
clients and servers. Without the requirement of PKCE, there will always be
the question of "but does this OAuth 2.1 client work with this OAuth 2.1
server or not?", which will only be able to be answered by investigating
the docs to look for PKCE support, or by checking the AS metadata document
if it publishes one (which it is not required to do).

Optimizing for interoperability and minimizing the burden on developers is
absolutely a good goal, and requiring PKCE is a great way to accomplish
that. OAuth 2.0 and OpenID Connect implementations that don't support PKCE
will continue to work as they currently do, they just won't be able to call
themselves OAuth 2.1 compliant, just as is the case as if they don't follow
the other recommendations that are in OAuth 2.1 and the Security BCP.

Aaron


On Thu, May 7, 2020 at 6:42 PM Mike Jones 
wrote:

> 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 hundreds or thousands of deployed OpenID Connect RPs won’t
> have to change their deployments.  That’s optimizing for interoperability
> and minimizing the burden on developers, which are far more important.
>
>
>
> As Brian Campbell wrote, “They are not equivalent and have very different
> ramifications on interoperability”.
>
>
>
> Even if you’re optimizing for writing, taking a minimally invasive
> protocol change approach will optimize that, overall.  If we proceed as
> you’re suggesting, a huge amount of writing will occur on StackOverflow,
> Medium, SlashDot, blogs, and other developer forums, where confused
> developers will ask “Why do I have to change my deployed code?” with the
> answers being “Despite what the 2.1 spec says, there’s no need to change
> your deployed code.”
>
>
>
> I’d gladly write a few sentences in our new specs now to prevent ongoing
> confusion and interop problems that would otherwise result.  Let me know
> when you’re ready to incorporate them into the spec text.
>
>
>
>-- Mike
>
>
>
> *From:* Aaron Parecki 
> *Sent:* Thursday, May 7, 2020 4:39 PM
> *To:* Dick Hardt 
> *Cc:* OAuth WG ; Torsten Lodderstedt <
> tors...@lodderstedt.net>; Mike Jones 
> *Subject:* Re: 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 so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
>
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE as
> well.
>
>
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
>
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
>
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP for
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>
>
>
> Aaron
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>
> 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 

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

[Mike Jones]

Actually, the first paragraph of the Security BCP section at 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1, 
which has gone through WGLC, includes the use of “nonce” to prevent 
authorization code injection as a best practice.  That’s already a pretty 
strong stamp 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 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 12:37 PM, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

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 
mailto:phili...@pragmaticwebsecurity.com>> 
wrote:
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 cause 
security vulnerabilities, which can easily be avoided.

Since OAuth 2.1 is a separate spec, I don’t really see a problem with existing 
code not being compliant. They support OAuth 2.0, and if they want to be OAuth 
2.1 compliant, they add PKCE. If I’m not mistaken, other requirements of OAuth 
2.1 would also clash with existing deployments (e.g., using non-exact redirect 
URIs).

I believe that optimizing for making OAuth 2.1 easier to understand will yield 
the highest return.

Philippe



On 8 May 2020, at 03:42, Mike Jones 
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>>
 wrote:

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 hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

As Brian Campbell wrote, “They are not equivalent and have very different 
ramifications on interoperability”.

Even if you’re optimizing for writing, taking a minimally invasive protocol 
change approach will optimize that, overall.  If we proceed as you’re 
suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
SlashDot, blogs, and other developer forums, where confused developers will ask 
“Why do I have to change my deployed code?” with the answers being “Despite 
what the 2.1 spec says, there’s no need to change your deployed code.”

I’d gladly write a few sentences in our new specs now to prevent ongoing 
confusion and interop problems that would otherwise result.  Let me know when 
you’re ready to incorporate them into the spec text.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Thursday, May 7, 2020 4:39 PM
To: Dick Hardt mailto:dick.ha...@gmail.com>>
Cc: OAuth WG mailto:oauth@ietf.org>>; Torsten Lodderstedt 
mailto:tors...@lodderstedt..net>>; Mike Jones 
mailto:michael.jo...@microsoft.com>>
Subject: Re: 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 so far. The quoted section of the 
security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client requests 
an ID token. Public clients using the nonce parameter are still susceptible to 
stolen authorization codes so they still need to do PKCE as well.

The only case where OpenID Connect clients don't benefit from PKCE is if they 
are also confidential clients. Public client OIDC clients still need to do PKCE 
even if they check the nonce.

OpenID Connect servers working with confidential clients still benefit from 
PKCE because they can then enforce the authorization code injection protection 
server-side rather than cross their fingers that clients implemented the nonce 
check properly.

I really don't think it's worth the amount of explanation this will take in the 
future to write an exception into OA

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

[Dick Hardt]

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 "breaking
> changes" from plain OAuth 2.0, because those things being removed were not
> best practices for example.
>

I was clarifying that OAuth 2.1 is not introducing new features, for eg.
the WebSocket support question.

I think we can say that:

An OAuth 2.0 compliant deployment following "best practices" is also an
OAuth 2.1 compliant deployment.

This thread is a discussion of what "best practices" is.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phillip Hunt]

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 12:37 PM, Dick Hardt  wrote:
> 
> 
> 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 
>>  wrote:
>> 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 cause 
>> security vulnerabilities, which can easily be avoided.
>> 
>> Since OAuth 2.1 is a separate spec, I don’t really see a problem with 
>> existing code not being compliant. They support OAuth 2.0, and if they want 
>> to be OAuth 2.1 compliant, they add PKCE. If I’m not mistaken, other 
>> requirements of OAuth 2.1 would also clash with existing deployments (e..g., 
>> using non-exact redirect URIs).
>> 
>> I believe that optimizing for making OAuth 2.1 easier to understand will 
>> yield the highest return.
>> 
>> Philippe
>> 
>> 
>>> On 8 May 2020, at 03:42, Mike Jones 
>>>  wrote:
>>> 
>>> 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 hundreds or thousands of deployed OpenID Connect RPs won’t 
>>> have to change their deployments.  That’s optimizing for interoperability 
>>> and minimizing the burden on developers, which are far more important.
>>>  
>>> As Brian Campbell wrote, “They are not equivalent and have very different 
>>> ramifications on interoperability”.
>>>  
>>> Even if you’re optimizing for writing, taking a minimally invasive protocol 
>>> change approach will optimize that, overall.  If we proceed as you’re 
>>> suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
>>> SlashDot, blogs, and other developer forums, where confused developers will 
>>> ask “Why do I have to change my deployed code?” with the answers being 
>>> “Despite what the 2.1 spec says, there’s no need to change your deployed 
>>> code.”
>>>  
>>> I’d gladly write a few sentences in our new specs now to prevent ongoing 
>>> confusion and interop problems that would otherwise result.  Let me know 
>>> when you’re ready to incorporate them into the spec text.
>>>  
>>>-- Mike
>>>  
>>> From: Aaron Parecki  
>>> Sent: Thursday, May 7, 2020 4:39 PM
>>> To: Dick Hardt 
>>> Cc: OAuth WG ; Torsten Lodderstedt 
>>> ; Mike Jones 
>>> Subject: Re: 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 so far. The quoted section 
>>> of the security BCP (4.5.3) which says clients can do PKCE or use the 
>>> nonce, is only talking about preventing authorization code injection.
>>>  
>>> The nonce parameter solves authorization code injection if the client 
>>> requests an ID token. Public clients using the nonce parameter are still 
>>> susceptible to stolen authorization codes so they still need to do PKCE as 
>>> well.
>>>  
>>> The only case where OpenID Connect clients don't benefit from PKCE is if 
>>> they are also confidential clients. Public client OIDC clients still need 
>>> to do PKCE even if they check the nonce.
>>>  
>>> OpenID Connect servers working with confidential clients still benefit from 
>>> PKCE because they can then enforce the authorization code injection 
>>> protection server-side rather than cross their fingers that clients 
>>> implemented the nonce check properly.
>>>  
>>> I really don't think it's worth the amount of explanation this will take in 
>>> the future to write an exception into OAuth 2.1 or the Security BCP for 
>>> only some types of OpenID Connect clients when all clients would benefit 
>>> from PKCE anyway.
>>>  
>>> Aaron
>>>  
>>>  
>>>  
>>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>>> 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 hence have 
>>> 

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

[Aaron Parecki]

> 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 being removed were not
best practices for example.

> 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 cause security vulnerabilities,
which can easily be avoided.

Thank you Philippe. And yes, many existing OAuth 2.0 deployments would
already need to change in order to be compliant with OAuth 2.1, just like
they would need to change to update to the latest recommendations of the
Security BCP.


On Fri, May 8, 2020 at 12:36 PM Dick Hardt  wrote:

> 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 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 cause security vulnerabilities, which can easily be avoided.
>>
>> Since OAuth 2.1 is a separate spec, I don’t really see a problem with
>> existing code not being compliant. They support OAuth 2.0, and if they want
>> to be OAuth 2.1 compliant, they add PKCE. If I’m not mistaken, other
>> requirements of OAuth 2.1 would also clash with existing deployments (e.g.,
>> using non-exact redirect URIs).
>>
>> I believe that optimizing for making OAuth 2.1 easier to understand will
>> yield the highest return.
>>
>> Philippe
>>
>>
>> On 8 May 2020, at 03:42, Mike Jones <
>> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>>
>> 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 hundreds or thousands of deployed OpenID Connect RPs won’t
>> have to change their deployments.  That’s optimizing for interoperability
>> and minimizing the burden on developers, which are far more important.
>>
>> As Brian Campbell wrote, “They are not equivalent and have very
>> different ramifications on interoperability”.
>>
>> Even if you’re optimizing for writing, taking a minimally invasive
>> protocol change approach will optimize that, overall.  If we proceed as
>> you’re suggesting, a huge amount of writing will occur on StackOverflow,
>> Medium, SlashDot, blogs, and other developer forums, where confused
>> developers will ask “Why do I have to change my deployed code?” with the
>> answers being “Despite what the 2.1 spec says, there’s no need to change
>> your deployed code.”
>>
>> I’d gladly write a few sentences in our new specs now to prevent ongoing
>> confusion and interop problems that would otherwise result.  Let me know
>> when you’re ready to incorporate them into the spec text.
>>
>>-- Mike
>>
>> *From:* Aaron Parecki 
>> *Sent:* Thursday, May 7, 2020 4:39 PM
>> *To:* Dick Hardt 
>> *Cc:* OAuth WG ; Torsten Lodderstedt <
>> tors...@lodderstedt.net>; Mike Jones 
>> *Subject:* Re: 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 so far. The quoted section
>> of the security BCP (4.5.3) which says clients can do PKCE or use the
>> nonce, is only talking about preventing authorization code injection.
>>
>> The nonce parameter solves authorization code injection if the client
>> requests an ID token. Public clients using the nonce parameter are still
>> susceptible to stolen authorization codes so they still need to do PKCE as
>> well.
>>
>> The only case where OpenID Connect clients don't benefit from PKCE is if
>> they are also confidential clients. Public client OIDC clients still need
>> to do PKCE even if they check the nonce.
>>
>> OpenID Connect servers working with confidential clients still benefit
>> from PKCE because they can then enforce the authorization code injection
>> protection server-side rather than cross their fingers that clients
>> implemented the nonce check properly.
>>
>> I really don't think it's worth the amount of explanation this will take
>> in the future to write an exception into OAuth 2.1 or the Security BCP for

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

[Dick Hardt]

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 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 cause
> security vulnerabilities, which can easily be avoided.
>
> Since OAuth 2.1 is a separate spec, I don’t really see a problem with
> existing code not being compliant. They support OAuth 2.0, and if they want
> to be OAuth 2.1 compliant, they add PKCE. If I’m not mistaken, other
> requirements of OAuth 2.1 would also clash with existing deployments (e.g..,
> using non-exact redirect URIs).
>
> I believe that optimizing for making OAuth 2.1 easier to understand will
> yield the highest return.
>
> Philippe
>
>
> On 8 May 2020, at 03:42, Mike Jones <
> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>
> 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 hundreds or thousands of deployed OpenID Connect RPs won’t
> have to change their deployments.  That’s optimizing for interoperability
> and minimizing the burden on developers, which are far more important.
>
> As Brian Campbell wrote, “They are not equivalent and have very different
> ramifications on interoperability”.
>
> Even if you’re optimizing for writing, taking a minimally invasive
> protocol change approach will optimize that, overall.  If we proceed as
> you’re suggesting, a huge amount of writing will occur on StackOverflow,
> Medium, SlashDot, blogs, and other developer forums, where confused
> developers will ask “Why do I have to change my deployed code?” with the
> answers being “Despite what the 2.1 spec says, there’s no need to change
> your deployed code.”
>
> I’d gladly write a few sentences in our new specs now to prevent ongoing
> confusion and interop problems that would otherwise result.  Let me know
> when you’re ready to incorporate them into the spec text.
>
>-- Mike
>
> *From:* Aaron Parecki 
> *Sent:* Thursday, May 7, 2020 4:39 PM
> *To:* Dick Hardt 
> *Cc:* OAuth WG ; Torsten Lodderstedt <
> tors...@lodderstedt.net>; Mike Jones 
> *Subject:* Re: 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 so far. The quoted section
> of the security BCP (4.5.3) which says clients can do PKCE or use the
> nonce, is only talking about preventing authorization code injection.
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are still
> susceptible to stolen authorization codes so they still need to do PKCE as
> well.
>
> The only case where OpenID Connect clients don't benefit from PKCE is if
> they are also confidential clients. Public client OIDC clients still need
> to do PKCE even if they check the nonce.
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code injection
> protection server-side rather than cross their fingers that clients
> implemented the nonce check properly.
>
> I really don't think it's worth the amount of explanation this will take
> in the future to write an exception into OAuth 2.1 or the Security BCP for
> only some types of OpenID Connect clients when all clients would benefit
> from PKCE anyway.
>
> Aaron
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>
> 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 hence have
> support for PKCE if following best practices.
>
> The advantages or requiring PKCE are:
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
> - reduced attack surface when using  S256 as a fingerprint of the verifier
> is sent through the browser instead of the clear text value
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
> What are disadvantages 

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

[Mike Jones]

Daniel, you wrote:
> We would then have:
> - use PKCE, except if you use OIDC with a nonce, then you don't need PKCE, 
> except if you are a public client, then you still need PKCE.
> - use state, except if you use PKCE, then you don't need state.

I believe that this is an accurate statement of the facts, balancing 
interoperability and simplicity.  That’s what we should therefore say in the 
spec (possibly rewording it to make it easier to parse and understand).

I would be OK going so far as also saying something along the lines of:
  - Alternatively, new implementations may choose to always use PKCE, provided 
that the client somehow can determine that the server it is communicating with 
also supports PKCE.
That seems like a viable compromise, giving developers accurate information 
that is actionable.

But mandating PKCE in all cases, even when unnecessary, would be an interop 
disaster and would cause many to simply ignore the new spec.

OAuth 2.1 was supposed to not introduce breaking changes.  If you want to do 
that, please do it in TxAuth instead.

   -- 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?

+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 nonce, then you don't need PKCE, 
except if you are a public client, then you still need PKCE.
- use state, except if you use PKCE, then you don't need state.

I think there are very good reasons to simplify this down to

- use PKCE
- you may or may not use state

First and foremost, not many people will understand why there are cases when 
the BCP/OAuth 2.1 mandate PKCE and some where they don't. However, 
understanding why you have to do something is key to compliance. The short 
version "PKCE protects the code; there is a specific case where it is not 
needed, but its better to use it all the time" is easy to understand. We will 
not see many implementations following the long version above correctly.

Second, we dramatically reduce technical complexity by reducing cases that need 
to be handled. We reduce correctness and compliance testing complexity in the 
same way. We reduce the cost of security analysis, which scales really badly to 
more cases.

And finally, using nonce to protect against code injection is less robust than 
PKCE. AS have a better track record than clients when it comes to correctly 
implementing security mechanisms.

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 has not been changed in a while is probably not one you would 
want to use anyway. We are setting a new goal for implementations to meet and 
eventually, maintained implementations will get there.

-Daniel


Am 08.05.20 um 01:38 schrieb Aaron Parecki:
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 so far. The quoted section of the 
security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client requests 
an ID token. Public clients using the nonce parameter are still susceptible to 
stolen authorization codes so they still need to do PKCE as well.

The only case where OpenID Connect clients don't benefit from PKCE is if they 
are also confidential clients. Public client OIDC clients still need to do PKCE 
even if they check the nonce.

OpenID Connect servers working with confidential clients still benefit from 
PKCE because they can then enforce the authorization code injection protection 
server-side rather than cross their fingers that clients implemented the nonce 
check properly.

I really don't think it's worth the amount of explanation this will take in the 
future to write an exception into OAuth 2.1 or the Security BCP for only some 
types of OpenID Connect clients when all clients would benefit from PKCE anyway.

Aaron



On Wed, May 6, 2020 at 10:48 AM Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:
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 hence have support

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

[Phillip Hunt]

+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 usage of nonce).
> 
> We would then have:
> 
> - use PKCE, except if you use OIDC with a nonce, then you don't need PKCE, 
> except if you are a public client, then you still need PKCE.
> - use state, except if you use PKCE, then you don't need state.
> 
> I think there are very good reasons to simplify this down to 
> 
> - use PKCE
> - you may or may not use state
> 
> First and foremost, not many people will understand why there are cases when 
> the BCP/OAuth 2.1 mandate PKCE and some where they don't. However, 
> understanding why you have to do something is key to compliance. The short 
> version "PKCE protects the code; there is a specific case where it is not 
> needed, but its better to use it all the time" is easy to understand. We will 
> not see many implementations following the long version above correctly.
> 
> Second, we dramatically reduce technical complexity by reducing cases that 
> need to be handled. We reduce correctness and compliance testing complexity 
> in the same way. We reduce the cost of security analysis, which scales really 
> badly to more cases.
> 
> And finally, using nonce to protect against code injection is less robust 
> than PKCE. AS have a better track record than clients when it comes to 
> correctly implementing security mechanisms. 
> 
> 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 has not been changed in a while is probably not one you 
> would want to use anyway. We are setting a new goal for implementations to 
> meet and eventually, maintained implementations will get there.
> 
> -Daniel
> 
> 
> Am 08.05.20 um 01:38 schrieb Aaron Parecki:
>> 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 so far. The quoted section of the 
>> security BCP (4.5.3) which says clients can do PKCE or use the nonce, is 
>> only talking about preventing authorization code injection.
>> 
>> The nonce parameter solves authorization code injection if the client 
>> requests an ID token. Public clients using the nonce parameter are still 
>> susceptible to stolen authorization codes so they still need to do PKCE as 
>> well.
>> 
>> The only case where OpenID Connect clients don't benefit from PKCE is if 
>> they are also confidential clients. Public client OIDC clients still need to 
>> do PKCE even if they check the nonce.
>> 
>> OpenID Connect servers working with confidential clients still benefit from 
>> PKCE because they can then enforce the authorization code injection 
>> protection server-side rather than cross their fingers that clients 
>> implemented the nonce check properly.
>> 
>> I really don't think it's worth the amount of explanation this will take in 
>> the future to write an exception into OAuth 2.1 or the Security BCP for only 
>> some types of OpenID Connect clients when all clients would benefit from 
>> PKCE anyway.
>> 
>> Aaron
>> 
>> 
>> 
>> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:
>>> 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 hence have 
>>> support for PKCE if following best practices.
>>> 
>>> The advantages or requiring PKCE are:
>>> 
>>> - a simpler programming model across all OAuth applications and profiles as 
>>> they all use PKCE
>>> 
>>> - reduced attack surface when using  S256 as a fingerprint of the verifier 
>>> is sent through the browser instead of the clear text value
>>> 
>>> - enforcement by AS not client - makes it easier to handle for client 
>>> developers and AS can ensure the check is conducted
>>> 
>>> What are disadvantages besides the potential impact to OpenID Connect 
>>> deployments? How significant is that impact?
>>> 
>>> Dick, Aaron, and Torsten
>>> 
>>> ᐧ
>> 
>> 
>> ___
>> 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Daniel Fett]

+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 nonce, then you don't need
PKCE, except if you are a public client, then you still need PKCE.
- use state, except if you use PKCE, then you don't need state.

I think there are very good reasons to simplify this down to

- use PKCE
- you may or may not use state

First and foremost, not many people will understand why there are cases
when the BCP/OAuth 2.1 mandate PKCE and some where they don't. However,
understanding /why/ you have to do something is key to compliance. The
short version "PKCE protects the code; there is a specific case where it
is not needed, but its better to use it all the time" is easy to
understand. We will not see many implementations following the long
version above correctly.

Second, we dramatically reduce technical complexity by reducing cases
that need to be handled. We reduce correctness and compliance testing
complexity in the same way. We reduce the cost of security analysis,
which scales really badly to more cases.

And finally, using nonce to protect against code injection is less
robust than PKCE. AS have a better track record than clients when it
comes to correctly implementing security mechanisms.

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 has not been changed in a while is probably
not one you would want to use anyway. We are setting a new goal for
implementations to meet and eventually, maintained implementations will
get there.

-Daniel


Am 08.05.20 um 01:38 schrieb Aaron Parecki:
> 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 so far.
> The quoted section of the security BCP (4.5.3) which says clients can
> do PKCE or use the nonce, is only talking about preventing
> authorization code injection.
>
> The nonce parameter solves authorization code injection if the client
> requests an ID token. Public clients using the nonce parameter are
> still susceptible to stolen authorization codes so they still need to
> do PKCE as well.
>
> The only case where OpenID Connect clients don't benefit from PKCE is
> if they are also confidential clients. Public client OIDC clients
> still need to do PKCE even if they check the nonce.
>
> OpenID Connect servers working with confidential clients still benefit
> from PKCE because they can then enforce the authorization code
> injection protection server-side rather than cross their fingers that
> clients implemented the nonce check properly.
>
> I really don't think it's worth the amount of explanation this will
> take in the future to write an exception into OAuth 2.1 or the
> Security BCP for only some types of OpenID Connect clients when all
> clients would benefit from PKCE anyway.
>
> Aaron
>
>
>
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  > wrote:
>
> 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 hence have support for PKCE if following
> best practices.
>
> The advantages or requiring PKCE are:
>
> - a simpler programming model across all OAuth applications and
> profiles as they all use PKCE
>
> - reduced attack surface when using  S256 as a fingerprint of the
> verifier is sent through the browser instead of the clear text value
>
> - enforcement by AS not client - makes it easier to handle for
> client developers and AS can ensure the check is conducted
>
> What are disadvantages besides the potential impact to OpenID
> Connect deployments? How significant is that impact?
>
> Dick, Aaron, and Torsten
>
> ᐧ
>
>
> ___
> 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

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

[Philippe De Ryck]

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 cause 
security vulnerabilities, which can easily be avoided.

Since OAuth 2.1 is a separate spec, I don’t really see a problem with existing 
code not being compliant. They support OAuth 2.0, and if they want to be OAuth 
2.1 compliant, they add PKCE. If I’m not mistaken, other requirements of OAuth 
2.1 would also clash with existing deployments (e.g., using non-exact redirect 
URIs).

I believe that optimizing for making OAuth 2.1 easier to understand will yield 
the highest return.

Philippe


> On 8 May 2020, at 03:42, Mike Jones 
>  wrote:
> 
> 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 hundreds or 
> thousands of deployed OpenID Connect RPs won’t have to change their 
> deployments.  That’s optimizing for interoperability and minimizing the 
> burden on developers, which are far more important.
>  
> As Brian Campbell wrote, “They are not equivalent and have very different 
> ramifications on interoperability”.
>  
> Even if you’re optimizing for writing, taking a minimally invasive protocol 
> change approach will optimize that, overall.  If we proceed as you’re 
> suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
> SlashDot, blogs, and other developer forums, where confused developers will 
> ask “Why do I have to change my deployed code?” with the answers being 
> “Despite what the 2.1 spec says, there’s no need to change your deployed 
> code.”
>  
> I’d gladly write a few sentences in our new specs now to prevent ongoing 
> confusion and interop problems that would otherwise result.  Let me know when 
> you’re ready to incorporate them into the spec text.
>  
>-- Mike
>  
> From: Aaron Parecki mailto:aa...@parecki.com>> 
> Sent: Thursday, May 7, 2020 4:39 PM
> To: Dick Hardt mailto:dick.ha...@gmail.com>>
> Cc: OAuth WG mailto:oauth@ietf.org>>; Torsten Lodderstedt 
> mailto:tors...@lodderstedt.net>>; Mike Jones 
> mailto:michael.jo...@microsoft.com>>
> Subject: Re: 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 so far. The quoted section of the 
> security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
> talking about preventing authorization code injection.
>  
> The nonce parameter solves authorization code injection if the client 
> requests an ID token. Public clients using the nonce parameter are still 
> susceptible to stolen authorization codes so they still need to do PKCE as 
> well.
>  
> The only case where OpenID Connect clients don't benefit from PKCE is if they 
> are also confidential clients. Public client OIDC clients still need to do 
> PKCE even if they check the nonce.
>  
> OpenID Connect servers working with confidential clients still benefit from 
> PKCE because they can then enforce the authorization code injection 
> protection server-side rather than cross their fingers that clients 
> implemented the nonce check properly.
>  
> I really don't think it's worth the amount of explanation this will take in 
> the future to write an exception into OAuth 2.1 or the Security BCP for only 
> some types of OpenID Connect clients when all clients would benefit from PKCE 
> anyway.
>  
> Aaron
>  
>  
>  
> On Wed, May 6, 2020 at 10:48 AM Dick Hardt  > wrote:
> 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 hence have 
> support for PKCE if following best practices.
>  
> The advantages or requiring PKCE are:
>  
> - a simpler programming model across all OAuth applications and profiles as 
> they all use PKCE
>  
> - reduced attack surface when using  S256 as a fingerprint of the verifier is 
> sent through the browser instead of the clear text value
>  
> - enforcement by AS not client - makes it easier to handle for client 
> developers and AS can ensure the check is conducted
>  
> What are disadvantages besides the potential impact to OpenID Connect 

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

[Mike Jones]

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 hundreds or 
thousands of deployed OpenID Connect RPs won’t have to change their 
deployments.  That’s optimizing for interoperability and minimizing the burden 
on developers, which are far more important.

As Brian Campbell wrote, “They are not equivalent and have very different 
ramifications on interoperability”.

Even if you’re optimizing for writing, taking a minimally invasive protocol 
change approach will optimize that, overall.  If we proceed as you’re 
suggesting, a huge amount of writing will occur on StackOverflow, Medium, 
SlashDot, blogs, and other developer forums, where confused developers will ask 
“Why do I have to change my deployed code?” with the answers being “Despite 
what the 2.1 spec says, there’s no need to change your deployed code.”

I’d gladly write a few sentences in our new specs now to prevent ongoing 
confusion and interop problems that would otherwise result.  Let me know when 
you’re ready to incorporate them into the spec text.

   -- Mike

From: Aaron Parecki 
Sent: Thursday, May 7, 2020 4:39 PM
To: Dick Hardt 
Cc: OAuth WG ; Torsten Lodderstedt ; 
Mike Jones 
Subject: Re: 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 so far. The quoted section of the 
security BCP (4.5.3) which says clients can do PKCE or use the nonce, is only 
talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client requests 
an ID token. Public clients using the nonce parameter are still susceptible to 
stolen authorization codes so they still need to do PKCE as well.

The only case where OpenID Connect clients don't benefit from PKCE is if they 
are also confidential clients. Public client OIDC clients still need to do PKCE 
even if they check the nonce.

OpenID Connect servers working with confidential clients still benefit from 
PKCE because they can then enforce the authorization code injection protection 
server-side rather than cross their fingers that clients implemented the nonce 
check properly.

I really don't think it's worth the amount of explanation this will take in the 
future to write an exception into OAuth 2.1 or the Security BCP for only some 
types of OpenID Connect clients when all clients would benefit from PKCE anyway.

Aaron



On Wed, May 6, 2020 at 10:48 AM Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:
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 hence have support for PKCE 
if following best practices.

The advantages or requiring PKCE are:

- a simpler programming model across all OAuth applications and profiles as 
they all use PKCE

- reduced attack surface when using  S256 as a fingerprint of the verifier is 
sent through the browser instead of the clear text value

- enforcement by AS not client - makes it easier to handle for client 
developers and AS can ensure the check is conducted

What are disadvantages besides the potential impact to OpenID Connect 
deployments? How significant is that impact?

Dick, Aaron, and Torsten

ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Aaron Parecki]

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 so far. The quoted section
of the security BCP (4.5.3) which says clients can do PKCE or use the
nonce, is only talking about preventing authorization code injection.

The nonce parameter solves authorization code injection if the client
requests an ID token. Public clients using the nonce parameter are still
susceptible to stolen authorization codes so they still need to do PKCE as
well.

The only case where OpenID Connect clients don't benefit from PKCE is if
they are also confidential clients. Public client OIDC clients still need
to do PKCE even if they check the nonce.

OpenID Connect servers working with confidential clients still benefit from
PKCE because they can then enforce the authorization code injection
protection server-side rather than cross their fingers that clients
implemented the nonce check properly.

I really don't think it's worth the amount of explanation this will take in
the future to write an exception into OAuth 2.1 or the Security BCP for
only some types of OpenID Connect clients when all clients would benefit
from PKCE anyway.

Aaron



On Wed, May 6, 2020 at 10:48 AM Dick Hardt  wrote:

> 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 hence have
> support for PKCE if following best practices.
>
> The advantages or requiring PKCE are:
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
> - reduced attack surface when using  S256 as a fingerprint of the verifier
> is sent through the browser instead of the clear text value
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
> Dick, Aaron, and Torsten
>
> ᐧ
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

I think the point is that the Security BCP in
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1..1
requires that the authz request has either the PKCE "code_challenge" or the
OIDC "nonce". Whereas 2.1 in
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-4.1.1.3
flat out requires PKCE "code_challenge" in the authz request. They are not
equivalent and have very different ramifications on interoperability etc..


On Wed, May 6, 2020 at 2:43 PM Aaron Parecki  wrote:

> Going back to this point about server vs client requirements, since both
> the Security BCP and OAuth 2.1 currently say that ASs MUST support PKCE,
> isn't that already imposing additional requirements on OpenID Connect
> providers that don't currently exist in OpenID Connect alone?
>
> OPs that want to be compliant with the Security BCP will need to add PKCE
> support if they don't already have it (many of them already support it so
> for many of them this will not be any change), so it seems like a very
> small leap to also require clients implement PKCE as well.
>
> On Wed, May 6, 2020 at 12:31 PM Mike Jones 
> wrote:
>
>> I realize what it says about servers.  My point is that OAuth 2.1’s
>> requirements on *clients* should match those in the security BCP and not
>> try to go beyond them.
>>
>>
>>
>>-- 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, 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 Wed, May 6, 2020 at 12:22 PM Mike Jones 
>> wrote:
>>
>> Aaron, the section you cited at
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1
>> makes it clear that clients can support EITHER PKCE or the OpenID Connect
>> nonce.   The text is:
>>
>>
>>
>>Clients MUST prevent injection (replay) of authorization codes into
>>
>>the authorization response by attackers.  The use of PKCE [RFC7636
>> <https://tools.ietf.org/html/rfc7636>]
>>
>>is RECOMMENDED to this end.  The OpenID Connect "nonce" parameter and
>>
>>ID Token Claim [OpenID
>> <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#ref-OpenID>]
>> MAY be used as well.  The PKCE challenge or
>>
>>OpenID Connect "nonce" MUST be transaction-specific and securely
>>
>>bound to the client and the user agent in which the transaction was
>>
>>started.
>>
>>
>>
>> We should not attempt to change that in OAuth 2.1, as doing so would
>> needlessly break already working and secure clients.
>>
>>
>>
>>-- Mike
>>
>>
>>
>> *From:* Aaron Parecki 
>> *Sent:* Wednesday, May 6, 2020 11:56 AM
>> *To:* Mike Jones 
>> *Cc:* Dick Hardt ; oauth@ietf.org
>> *Subject:* [EXTERNAL] 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.
>>
>>
>>
>> The Security BCP already requires that ASs support PKCE:
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1
>>  Are
>> you suggesting that the Security BCP change that requirement as well? If
>> so, that's a discussion that needs to be had ASAP. If not, then that's an
>> implicit statement that it's okay for OpenID Connect implementations to not
>> be best-practice OAuth implementations. And if that's the case, then I also
>> think it's acceptable that they are not complete OAuth 2.1 implementations
>> either.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, May 6, 2020 at 11:21 AM Mike Jones > 40microsoft@dmarc.ietf.org> wrote:
>>
>> The disadvantage of requiring PKCE for OpenID Connect implementations is
>> that you’re trying to add a normative requirement that’s not required of
>> OpenID Connect deployments today, which would bifurcate the ecosystem.
>> There are hundreds of implementations (including the 141 ce

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

[Mike Jones]

Requiring a change to every deployed RP is not “a very small leap”.  It’s an 
invasive big deal, introducing a breaking change and bifurcating a 
well-functioning ecosystem without sufficient cause.

What this actually points out to me is that we should modify the language in 
the Security BCP to say something like “OAuth Servers MUST support PKCE unless 
they are only used for OpenID Connect Authentication Requests”.  I’d thought 
that that was already the case, as that mirrors the client requirements and I 
apparently failed to read it closely enough.  I’ll submit a separate request 
for 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 point about server vs client requirements, since both the 
Security BCP and OAuth 2.1 currently say that ASs MUST support PKCE, isn't that 
already imposing additional requirements on OpenID Connect providers that don't 
currently exist in OpenID Connect alone?

OPs that want to be compliant with the Security BCP will need to add PKCE 
support if they don't already have it (many of them already support it so for 
many of them this will not be any change), so it seems like a very small leap 
to also require clients implement PKCE as well.

On Wed, May 6, 2020 at 12:31 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
I realize what it says about servers.  My point is that OAuth 2.1’s 
requirements on clients should match those in the security BCP and not try to 
go beyond them.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Wednesday, May 6, 2020 12:24 PM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Dick Hardt mailto:dick.ha...@gmail.com>>; 
oauth@ietf.org<mailto: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 Wed, May 6, 2020 at 12:22 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
Aaron, the section you cited at 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 
makes it clear that clients can support EITHER PKCE or the OpenID Connect 
nonce.   The text is:

   Clients MUST prevent injection (replay) of authorization codes into
   the authorization response by attackers.  The use of PKCE 
[RFC7636<https://tools.ietf.org/html/rfc7636>]
   is RECOMMENDED to this end.  The OpenID Connect "nonce" parameter and
   ID Token Claim 
[OpenID<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#ref-OpenID>]
 MAY be used as well.  The PKCE challenge or
   OpenID Connect "nonce" MUST be transaction-specific and securely
   bound to the client and the user agent in which the transaction was
   started.

We should not attempt to change that in OAuth 2.1, as doing so would needlessly 
break already working and secure clients.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Wednesday, May 6, 2020 11:56 AM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Dick Hardt mailto:dick.ha...@gmail.com>>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] 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.

The Security BCP already requires that ASs support PKCE: 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 
Are you suggesting that the Security BCP change that requirement as well? If 
so, that's a discussion that needs to be had ASAP. If not, then that's an 
implicit statement that it's okay for OpenID Connect implementations to not be 
best-practice OAuth implementations. And if that's the case, then I also think 
it's acceptable that they are not complete OAuth 2.1 implementations either.






On Wed, May 6, 2020 at 11:21 AM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
The disadvantage of requiring PKCE for OpenID Connect implementations is that 
you’re trying to add a normative requirement that’s not required of OpenID 
Connect deployments today, which would bifurcate the ecosystem.  There are 
hundreds of implementations (including the 141 certified ones at 
https://openid.net/certification/), none of which have ever been required to 
support PKCE.  Therefore, most don’t.

Per feedback already provided, I believe that OAuth 2.1 should align with the 
guidance already in the draft Security BCP, requiring EITHER the use of PKCE or 

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

[Dick Hardt]

I hear Mike's point on breaking existing RPs. There are alot of them out
there.

For discussion purposes, let's call the current version OIDC 1.0 and the
version running OAuth 2.1, OIDC 1.1

Is there a reason a server can't be running both versions at the same time,
and support clients running both versions at the same time? The AS could
then enforce new and migrated clients running OIDC 1.1 to use PKCE.









ᐧ

On Wed, May 6, 2020 at 1:43 PM Aaron Parecki  wrote:

> Going back to this point about server vs client requirements, since both
> the Security BCP and OAuth 2.1 currently say that ASs MUST support PKCE,
> isn't that already imposing additional requirements on OpenID Connect
> providers that don't currently exist in OpenID Connect alone?
>
> OPs that want to be compliant with the Security BCP will need to add PKCE
> support if they don't already have it (many of them already support it so
> for many of them this will not be any change), so it seems like a very
> small leap to also require clients implement PKCE as well.
>
> On Wed, May 6, 2020 at 12:31 PM Mike Jones 
> wrote:
>
>> I realize what it says about servers.  My point is that OAuth 2.1’s
>> requirements on *clients* should match those in the security BCP and not
>> try to go beyond them.
>>
>>
>>
>>-- 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, 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 Wed, May 6, 2020 at 12:22 PM Mike Jones 
>> wrote:
>>
>> Aaron, the section you cited at
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1
>> makes it clear that clients can support EITHER PKCE or the OpenID Connect
>> nonce.   The text is:
>>
>>
>>
>>Clients MUST prevent injection (replay) of authorization codes into
>>
>>the authorization response by attackers.  The use of PKCE [RFC7636
>> <https://tools.ietf.org/html/rfc7636>]
>>
>>is RECOMMENDED to this end.  The OpenID Connect "nonce" parameter and
>>
>>ID Token Claim [OpenID
>> <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#ref-OpenID>]
>> MAY be used as well.  The PKCE challenge or
>>
>>OpenID Connect "nonce" MUST be transaction-specific and securely
>>
>>bound to the client and the user agent in which the transaction was
>>
>>    started.
>>
>>
>>
>> We should not attempt to change that in OAuth 2.1, as doing so would
>> needlessly break already working and secure clients.
>>
>>
>>
>>-- Mike
>>
>>
>>
>> *From:* Aaron Parecki 
>> *Sent:* Wednesday, May 6, 2020 11:56 AM
>> *To:* Mike Jones 
>> *Cc:* Dick Hardt ; oauth@ietf.org
>> *Subject:* [EXTERNAL] 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.
>>
>>
>>
>> The Security BCP already requires that ASs support PKCE:
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1
>>  Are
>> you suggesting that the Security BCP change that requirement as well? If
>> so, that's a discussion that needs to be had ASAP. If not, then that's an
>> implicit statement that it's okay for OpenID Connect implementations to not
>> be best-practice OAuth implementations. And if that's the case, then I also
>> think it's acceptable that they are not complete OAuth 2.1 implementations
>> either.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, May 6, 2020 at 11:21 AM Mike Jones > 40microsoft@dmarc.ietf.org> wrote:
>>
>> The disadvantage of requiring PKCE for OpenID Connect implementations is
>> that you’re trying to add a normative requirement that’s not required of
>> OpenID Connect deployments today, which would bifurcate the ecosystem.
>> There are hundreds of implementations (including the 141 certified ones at
>> https://openid.net/certification/), no

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

[Aaron Parecki]

Going back to this point about server vs client requirements, since both
the Security BCP and OAuth 2.1 currently say that ASs MUST support PKCE,
isn't that already imposing additional requirements on OpenID Connect
providers that don't currently exist in OpenID Connect alone?

OPs that want to be compliant with the Security BCP will need to add PKCE
support if they don't already have it (many of them already support it so
for many of them this will not be any change), so it seems like a very
small leap to also require clients implement PKCE as well.

On Wed, May 6, 2020 at 12:31 PM Mike Jones 
wrote:

> I realize what it says about servers.  My point is that OAuth 2.1’s
> requirements on *clients* should match those in the security BCP and not
> try to go beyond them.
>
>
>
>-- 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, 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 Wed, May 6, 2020 at 12:22 PM Mike Jones 
> wrote:
>
> Aaron, the section you cited at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2..1.1
> makes it clear that clients can support EITHER PKCE or the OpenID Connect
> nonce.   The text is:
>
>
>
>Clients MUST prevent injection (replay) of authorization codes into
>
>the authorization response by attackers.  The use of PKCE [RFC7636
> <https://tools.ietf.org/html/rfc7636>]
>
>is RECOMMENDED to this end.  The OpenID Connect "nonce" parameter and
>
>ID Token Claim [OpenID
> <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#ref-OpenID>]
> MAY be used as well.  The PKCE challenge or
>
>OpenID Connect "nonce" MUST be transaction-specific and securely
>
>bound to the client and the user agent in which the transaction was
>
>started.
>
>
>
> We should not attempt to change that in OAuth 2.1, as doing so would
> needlessly break already working and secure clients.
>
>
>
>                -- Mike
>
>
>
> *From:* Aaron Parecki 
> *Sent:* Wednesday, May 6, 2020 11:56 AM
> *To:* Mike Jones 
> *Cc:* Dick Hardt ; oauth@ietf.org
> *Subject:* [EXTERNAL] 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.
>
>
>
> The Security BCP already requires that ASs support PKCE:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2..1.1
>  Are
> you suggesting that the Security BCP change that requirement as well? If
> so, that's a discussion that needs to be had ASAP. If not, then that's an
> implicit statement that it's okay for OpenID Connect implementations to not
> be best-practice OAuth implementations. And if that's the case, then I also
> think it's acceptable that they are not complete OAuth 2.1 implementations
> either.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, May 6, 2020 at 11:21 AM Mike Jones  40microsoft@dmarc.ietf.org> wrote:
>
> The disadvantage of requiring PKCE for OpenID Connect implementations is
> that you’re trying to add a normative requirement that’s not required of
> OpenID Connect deployments today, which would bifurcate the ecosystem.
> There are hundreds of implementations (including the 141 certified ones at
> https://openid.net/certification/), none of which have ever been required
> to support PKCE.  Therefore, most don’t.
>
>
>
> Per feedback already provided, I believe that OAuth 2.1 should align with
> the guidance already in the draft Security BCP, requiring EITHER the use of
> PKCE or 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 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
> the OpenID Connect nonce.  Doing so would unnecessarily break things and
> create confusion in the marketplace.
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth  *

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

[Mike Jones]

It could, but that would require an explicit decision by the OpenID Connect 
working group to make existing RPs incompatible with new OPs, breaking 
interoperability.  That’s not a decision we should make lightly or without a 
compelling reason to do so.

   -- 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 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

Yes, FAPI requires PKCE, which is great.  Many of its requirements come from 
OpenID Connect but some of them are intentionally incompatible – such as 
requiring that Basic authentication not be supported, whereas Connect requires 
that it be supported.  It’s a different ecosystem with different requirements.

Don’t get me wrong, I support PKCE where it makes sense, such as when you’re 
doing bare OAuth without OpenID Connect.  But trying to impose an unnecessary 
requirement on a working and secure ecosystem will just create grief for us and 
our customers and lessen our credibility as stewards of the OAuth ecosystem.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Wednesday, May 6, 2020 12:29 PM
To: Steinar Noem mailto:stei...@udelt.no>>
Cc: Phillip Hunt 
mailto:phil.h...@independentid.com>>; Mike Jones 
mailto:michael.jo...@microsoft.com>>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

I should add that even some OpenID Connect profiles require PKCE, such as FAPI:

https://openid.net/specs/openid-financial-api-part-1.html#authorization-server

So the precedent for requiring PKCE already exists within some OpenID Connect 
profiles.

On Wed, May 6, 2020 at 12:23 PM Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
Yes, and also, many of those providers very likely already support PKCE 
already. Skimming through that list of certified OPs, I recognize many names 
there from providers that I know support PKCE.

On Wed, May 6, 2020 at 12:18 PM Steinar Noem 
mailto:stei...@udelt.no>> wrote:
So, wouldn't a MUST just mean that we would have some OPs that are 2.1 
compliant and some that aren't?

ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt 
mailto:phil.h...@independentid.com>>:
Mike,

The point of 2.1 is to raise the security bar..

Yes it adds new MUST requirements.

But what about OIDC would break other than required implementation of PKCE to 
support 2.1?

Eg Would additional signaling be required to facilitate interoperability and 
migration between versions? Would that be an oauth issue or an OIDC one?

Phil



On May 6, 2020, at 11:56 AM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

> In particular, authorization servers shouldn’t be required to support PKCE 
> when they already support the OpenID Connect nonce.

The Security BCP already requires that ASs support PKCE: 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 
Are you suggesting that the Security BCP change that requirement as well? If 
so, that's a discussion that needs to be had ASAP. If not, then that's an 
implicit statement that it's okay for OpenID Connect implementations to not be 
best-practice OAuth implementations. And if that's the case, then I also think 
it's acceptable that they are not complete OAuth 2.1 implementations either.






On Wed, May 6, 2020 at 11:21 AM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
The disadvantage of requiring PKCE for OpenID Connect implementations is that 
you’re trying to add a normative requirement that’s not required of OpenID 
Connect deployments today, which would bifurcate the ecosystem.  There are 
hundreds of implementations (including the 141 certified ones at 
https://openid.net/certification/), none of which have ever been required to 
support PKCE.  Therefore, most don’t.

Per feedback already provided, I believe that OAuth 2.1 should align with the 
guidance already in the draft Security BCP, requiring EITHER the use of PKCE or 
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 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 the OpenID 
Connect nonce.  Doing so would unnecessarily break things and create confusion 
in the marketplace.

  -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Dick Hardt
Sent: Wed

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

[Phillip Hunt]

Why couldn’t OIDC evolve as a spec to conform and match FAPI and 2.1?  

Phil

> On May 6, 2020, at 12:34 PM, Mike Jones  wrote:
> 
> 
> Yes, FAPI requires PKCE, which is great.  Many of its requirements come from 
> OpenID Connect but some of them are intentionally incompatible – such as 
> requiring that Basic authentication not be supported, whereas Connect 
> requires that it be supported.  It’s a different ecosystem with different 
> requirements.
>  
> Don’t get me wrong, I support PKCE where it makes sense, such as when you’re 
> doing bare OAuth without OpenID Connect.  But trying to impose an unnecessary 
> requirement on a working and secure ecosystem will just create grief for us 
> and our customers and lessen our credibility as 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 OpenID Connect profiles require PKCE, such as 
> FAPI:
>  
> https://openid.net/specs/openid-financial-api-part-1.html#authorization-server
>  
> So the precedent for requiring PKCE already exists within some OpenID Connect 
> profiles.
>  
> On Wed, May 6, 2020 at 12:23 PM Aaron Parecki  wrote:
> Yes, and also, many of those providers very likely already support PKCE 
> already. Skimming through that list of certified OPs, I recognize many names 
> there from providers that I know support PKCE.
>  
> On Wed, May 6, 2020 at 12:18 PM Steinar Noem  wrote:
> So, wouldn't a MUST just mean that we would have some OPs that are 2.1 
> compliant and some that aren't?
>  
> ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt :
> Mike,
>  
> The point of 2.1 is to raise the security bar.. 
>  
> Yes it adds new MUST requirements. 
>  
> But what about OIDC would break other than required implementation of PKCE to 
> support 2.1?
>  
> Eg Would additional signaling be required to facilitate interoperability and 
> migration between versions? Would that be an oauth issue or an OIDC one?
>  
> Phil
> 
> 
> On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
> 
> 
> > In particular, authorization servers shouldn’t be required to support PKCE 
> > when they already support the OpenID Connect nonce.
>  
> The Security BCP already requires that ASs support PKCE: 
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 
> Are you suggesting that the Security BCP change that requirement as well? If 
> so, that's a discussion that needs to be had ASAP. If not, then that's an 
> implicit statement that it's okay for OpenID Connect implementations to not 
> be best-practice OAuth implementations. And if that's the case, then I also 
> think it's acceptable that they are not complete OAuth 2.1 implementations 
> either.
>  
>  
>  
>  
>  
>  
> On Wed, May 6, 2020 at 11:21 AM Mike Jones 
>  wrote:
> The disadvantage of requiring PKCE for OpenID Connect implementations is that 
> you’re trying to add a normative requirement that’s not required of OpenID 
> Connect deployments today, which would bifurcate the ecosystem.  There are 
> hundreds of implementations (including the 141 certified ones at 
> https://openid.net/certification/), none of which have ever been required to 
> support PKCE.  Therefore, most don’t.
>  
> Per feedback already provided, I believe that OAuth 2.1 should align with the 
> guidance already in the draft Security BCP, requiring EITHER the use of PKCE 
> or 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 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 
> the OpenID Connect nonce.  Doing so would unnecessarily break things and 
> create confusion in the marketplace.
>  
>   -- Mike
>  
> From: OAuth  On 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 some of the issues that PKCE protects against. We think that 
> most OpenID 

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

[Mike Jones]

Yes, FAPI requires PKCE, which is great.  Many of its requirements come from 
OpenID Connect but some of them are intentionally incompatible – such as 
requiring that Basic authentication not be supported, whereas Connect requires 
that it be supported.  It’s a different ecosystem with different requirements.

Don’t get me wrong, I support PKCE where it makes sense, such as when you’re 
doing bare OAuth without OpenID Connect.  But trying to impose an unnecessary 
requirement on a working and secure ecosystem will just create grief for us and 
our customers and lessen our credibility as 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 OpenID Connect profiles require PKCE, such as FAPI:

https://openid.net/specs/openid-financial-api-part-1.html#authorization-server

So the precedent for requiring PKCE already exists within some OpenID Connect 
profiles.

On Wed, May 6, 2020 at 12:23 PM Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
Yes, and also, many of those providers very likely already support PKCE 
already. Skimming through that list of certified OPs, I recognize many names 
there from providers that I know support PKCE.

On Wed, May 6, 2020 at 12:18 PM Steinar Noem 
mailto:stei...@udelt.no>> wrote:
So, wouldn't a MUST just mean that we would have some OPs that are 2.1 
compliant and some that aren't?

ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt 
mailto:phil.h...@independentid.com>>:
Mike,

The point of 2.1 is to raise the security bar..

Yes it adds new MUST requirements.

But what about OIDC would break other than required implementation of PKCE to 
support 2.1?

Eg Would additional signaling be required to facilitate interoperability and 
migration between versions? Would that be an oauth issue or an OIDC one?

Phil


On May 6, 2020, at 11:56 AM, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:

> In particular, authorization servers shouldn’t be required to support PKCE 
> when they already support the OpenID Connect nonce.

The Security BCP already requires that ASs support PKCE: 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 
Are you suggesting that the Security BCP change that requirement as well? If 
so, that's a discussion that needs to be had ASAP. If not, then that's an 
implicit statement that it's okay for OpenID Connect implementations to not be 
best-practice OAuth implementations. And if that's the case, then I also think 
it's acceptable that they are not complete OAuth 2.1 implementations either.






On Wed, May 6, 2020 at 11:21 AM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
The disadvantage of requiring PKCE for OpenID Connect implementations is that 
you’re trying to add a normative requirement that’s not required of OpenID 
Connect deployments today, which would bifurcate the ecosystem.  There are 
hundreds of implementations (including the 141 certified ones at 
https://openid.net/certification/), none of which have ever been required to 
support PKCE.  Therefore, most don’t.

Per feedback already provided, I believe that OAuth 2.1 should align with the 
guidance already in the draft Security BCP, requiring EITHER the use of PKCE or 
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 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 the OpenID 
Connect nonce.  Doing so would unnecessarily break things and create confusion 
in the marketplace.

  -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Dick Hardt
Sent: Wednesday, May 6, 2020 10:48 AM
To: oauth@ietf.org<mailto: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 some of the issues that PKCE protects against. We think that most OpenID 
Connect implementations also support OAuth 2.0, and hence have support for PKCE 
if following best practices.

The advantages or requiring PKCE are:

- a simpler programming model across all OAuth applications and profiles as 
they all use PKCE

- reduced attack surface when using  S256 as a fingerprint of the verifier is 
sent through the browser instead of the clear text value

- enforcement by AS not client - makes it easier to handle for client 
developer

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

[Mike Jones]

I realize what it says about servers.  My point is that OAuth 2.1’s 
requirements on clients should match those in the security BCP and not try to 
go beyond them.

   -- 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, 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 Wed, May 6, 2020 at 12:22 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
Aaron, the section you cited at 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 
makes it clear that clients can support EITHER PKCE or the OpenID Connect 
nonce.   The text is:

   Clients MUST prevent injection (replay) of authorization codes into
   the authorization response by attackers.  The use of PKCE 
[RFC7636<https://tools.ietf.org/html/rfc7636>]
   is RECOMMENDED to this end.  The OpenID Connect "nonce" parameter and
   ID Token Claim 
[OpenID<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#ref-OpenID>]
 MAY be used as well.  The PKCE challenge or
   OpenID Connect "nonce" MUST be transaction-specific and securely
   bound to the client and the user agent in which the transaction was
   started.

We should not attempt to change that in OAuth 2.1, as doing so would needlessly 
break already working and secure clients.

   -- Mike

From: Aaron Parecki mailto:aa...@parecki.com>>
Sent: Wednesday, May 6, 2020 11:56 AM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Dick Hardt mailto:dick.ha...@gmail.com>>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] 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.

The Security BCP already requires that ASs support PKCE: 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 
Are you suggesting that the Security BCP change that requirement as well? If 
so, that's a discussion that needs to be had ASAP. If not, then that's an 
implicit statement that it's okay for OpenID Connect implementations to not be 
best-practice OAuth implementations. And if that's the case, then I also think 
it's acceptable that they are not complete OAuth 2.1 implementations either.






On Wed, May 6, 2020 at 11:21 AM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
The disadvantage of requiring PKCE for OpenID Connect implementations is that 
you’re trying to add a normative requirement that’s not required of OpenID 
Connect deployments today, which would bifurcate the ecosystem.  There are 
hundreds of implementations (including the 141 certified ones at 
https://openid.net/certification/), none of which have ever been required to 
support PKCE.  Therefore, most don’t.

Per feedback already provided, I believe that OAuth 2.1 should align with the 
guidance already in the draft Security BCP, requiring EITHER the use of PKCE or 
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 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 the OpenID 
Connect nonce.  Doing so would unnecessarily break things and create confusion 
in the marketplace.

  -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Dick Hardt
Sent: Wednesday, May 6, 2020 10:48 AM
To: oauth@ietf.org<mailto: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 some of the issues that PKCE protects against. We think that most OpenID 
Connect implementations also support OAuth 2.0, and hence have support for PKCE 
if following best practices.

The advantages or requiring PKCE are:

- a simpler programming model across all OAuth applications and profiles as 
they all use PKCE

- reduced attack surface when using  S256 as a fingerprint of the verifier is 
sent through the browser instead of the clear text value

- enforcement by AS not client - makes it easier to handle for client 
developers and AS can ensure the check is conducted

What are disadvantages besides the potential impact to OpenID Connect 
deployments? How signifi

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

[Aaron Parecki]

I should add that even some OpenID Connect profiles require PKCE, such as
FAPI:

https://openid.net/specs/openid-financial-api-part-1.html#authorization-server

So the precedent for requiring PKCE already exists within some OpenID
Connect profiles.

On Wed, May 6, 2020 at 12:23 PM Aaron Parecki  wrote:

> Yes, and also, many of those providers very likely already support PKCE
> already. Skimming through that list of certified OPs, I recognize many
> names there from providers that I know support PKCE.
>
> On Wed, May 6, 2020 at 12:18 PM Steinar Noem  wrote:
>
>> So, wouldn't a MUST just mean that we would have some OPs that are 2.1
>> compliant and some that aren't?
>>
>> ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt <
>> phil.h...@independentid.com>:
>>
>>> Mike,
>>>
>>> The point of 2.1 is to raise the security bar.
>>>
>>> Yes it adds new MUST requirements.
>>>
>>> But what about OIDC would break other than required implementation of
>>> PKCE to support 2.1?
>>>
>>> Eg Would additional signaling be required to facilitate interoperability
>>> and migration between versions? Would that be an oauth issue or an OIDC one?
>>>
>>> Phil
>>>
>>> On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
>>>
>>> 
>>> > In particular, authorization servers shouldn’t be required to support
>>> PKCE when they already support the OpenID Connect nonce.
>>>
>>> The Security BCP already requires that ASs support PKCE:
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1
>>>  Are
>>> you suggesting that the Security BCP change that requirement as well? If
>>> so, that's a discussion that needs to be had ASAP. If not, then that's an
>>> implicit statement that it's okay for OpenID Connect implementations to not
>>> be best-practice OAuth implementations. And if that's the case, then I also
>>> think it's acceptable that they are not complete OAuth 2.1 implementations
>>> either.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 6, 2020 at 11:21 AM Mike Jones >> 40microsoft@dmarc.ietf.org> wrote:
>>>
 The disadvantage of requiring PKCE for OpenID Connect implementations
 is that you’re trying to add a normative requirement that’s not required of
 OpenID Connect deployments today, which would bifurcate the ecosystem.
 There are hundreds of implementations (including the 141 certified ones at
 https://openid.net/certification/), none of which have ever been
 required to support PKCE.  Therefore, most don’t.



 Per feedback already provided, I believe that OAuth 2.1 should align
 with the guidance already in the draft Security BCP, requiring EITHER the
 use of PKCE or 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 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 the OpenID Connect nonce.  Doing so would unnecessarily break
 things and create confusion in the marketplace.



   -- Mike



 *From:* OAuth  *On 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 some of the issues that PKCE protects against. We think
 that most OpenID Connect implementations also support OAuth 2.0, and
 hence have support for PKCE if following best practices.



 The advantages or requiring PKCE are:



 - a simpler programming model across all OAuth applications and
 profiles as they all use PKCE



 - reduced attack surface when using  S256 as a fingerprint of the
 verifier is sent through the browser instead of the clear text value



 - enforcement by AS not client - makes it easier to handle for client
 developers and AS can ensure the check is conducted



 What are disadvantages besides the potential impact to OpenID Connect
 deployments? How significant is that impact?



 Dick, Aaron, and Torsten



 ᐧ
 ___
 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
>>>
>>> ___
>>> OAuth mailing list
>>> 

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

[Aaron Parecki]

Yes, and also, many of those providers very likely already support PKCE
already. Skimming through that list of certified OPs, I recognize many
names there from providers that I know support PKCE.

On Wed, May 6, 2020 at 12:18 PM Steinar Noem  wrote:

> So, wouldn't a MUST just mean that we would have some OPs that are 2.1
> compliant and some that aren't?
>
> ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt  >:
>
>> Mike,
>>
>> The point of 2.1 is to raise the security bar.
>>
>> Yes it adds new MUST requirements.
>>
>> But what about OIDC would break other than required implementation of
>> PKCE to support 2.1?
>>
>> Eg Would additional signaling be required to facilitate interoperability
>> and migration between versions? Would that be an oauth issue or an OIDC one?
>>
>> Phil
>>
>> On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
>>
>> 
>> > In particular, authorization servers shouldn’t be required to support
>> PKCE when they already support the OpenID Connect nonce.
>>
>> The Security BCP already requires that ASs support PKCE:
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1
>>  Are
>> you suggesting that the Security BCP change that requirement as well? If
>> so, that's a discussion that needs to be had ASAP. If not, then that's an
>> implicit statement that it's okay for OpenID Connect implementations to not
>> be best-practice OAuth implementations. And if that's the case, then I also
>> think it's acceptable that they are not complete OAuth 2.1 implementations
>> either.
>>
>>
>>
>>
>>
>>
>> On Wed, May 6, 2020 at 11:21 AM Mike Jones > 40microsoft@dmarc.ietf.org> wrote:
>>
>>> The disadvantage of requiring PKCE for OpenID Connect implementations is
>>> that you’re trying to add a normative requirement that’s not required of
>>> OpenID Connect deployments today, which would bifurcate the ecosystem.
>>> There are hundreds of implementations (including the 141 certified ones at
>>> https://openid.net/certification/), none of which have ever been
>>> required to support PKCE.  Therefore, most don’t.
>>>
>>>
>>>
>>> Per feedback already provided, I believe that OAuth 2.1 should align
>>> with the guidance already in the draft Security BCP, requiring EITHER the
>>> use of PKCE or 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 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 the OpenID Connect nonce.  Doing so would unnecessarily break
>>> things and create confusion in the marketplace.
>>>
>>>
>>>
>>>   -- Mike
>>>
>>>
>>>
>>> *From:* OAuth  *On 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 some of the issues that PKCE protects against. We think
>>> that most OpenID Connect implementations also support OAuth 2.0, and
>>> hence have support for PKCE if following best practices.
>>>
>>>
>>>
>>> The advantages or requiring PKCE are:
>>>
>>>
>>>
>>> - a simpler programming model across all OAuth applications and profiles
>>> as they all use PKCE
>>>
>>>
>>>
>>> - reduced attack surface when using  S256 as a fingerprint of the
>>> verifier is sent through the browser instead of the clear text value
>>>
>>>
>>>
>>> - enforcement by AS not client - makes it easier to handle for client
>>> developers and AS can ensure the check is conducted
>>>
>>>
>>>
>>> What are disadvantages besides the potential impact to OpenID Connect
>>> deployments? How significant is that impact?
>>>
>>>
>>>
>>> Dick, Aaron, and Torsten
>>>
>>>
>>>
>>> ᐧ
>>> ___
>>> 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
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Vennlig hilsen
>
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
>
> | stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no |
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phillip Hunt]

Yes. Some would be 2.0 and some2.1. Not unlike TLS versioning.  

 Maybe i should not have said that. ;-)

Phil

> On May 6, 2020, at 12:18 PM, Steinar Noem  wrote:
> 
> 
> So, wouldn't a MUST just mean that we would have some OPs that are 2.1 
> compliant and some that aren't?
> 
>> ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt :
>> Mike,
>> 
>> The point of 2.1 is to raise the security bar. 
>> 
>> Yes it adds new MUST requirements. 
>> 
>> But what about OIDC would break other than required implementation of PKCE 
>> to support 2.1?
>> 
>> Eg Would additional signaling be required to facilitate interoperability and 
>> migration between versions? Would that be an oauth issue or an OIDC one?
>> 
>> Phil
>> 
 On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
 
>>> 
>>> > In particular, authorization servers shouldn’t be required to support 
>>> > PKCE when they already support the OpenID Connect nonce.
>>> 
>>> The Security BCP already requires that ASs support PKCE: 
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1
>>>  Are you suggesting that the Security BCP change that requirement as well? 
>>> If so, that's a discussion that needs to be had ASAP. If not, then that's 
>>> an implicit statement that it's okay for OpenID Connect implementations to 
>>> not be best-practice OAuth implementations. And if that's the case, then I 
>>> also think it's acceptable that they are not complete OAuth 2.1 
>>> implementations either.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 On Wed, May 6, 2020 at 11:21 AM Mike Jones 
  wrote:
 The disadvantage of requiring PKCE for OpenID Connect implementations is 
 that you’re trying to add a normative requirement that’s not required of 
 OpenID Connect deployments today, which would bifurcate the ecosystem.  
 There are hundreds of implementations (including the 141 certified ones at 
 https://openid.net/certification/), none of which have ever been required 
 to support PKCE.  Therefore, most don’t.
 
  
 
 Per feedback already provided, I believe that OAuth 2.1 should align with 
 the guidance already in the draft Security BCP, requiring EITHER the use 
 of PKCE or 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 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 
 the OpenID Connect nonce.  Doing so would unnecessarily break things and 
 create confusion in the marketplace.
 
  
 
   -- Mike
 
  
 
 From: OAuth  On 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 some of the issues that PKCE protects against. We think that 
 most OpenID Connect implementations also support OAuth 2.0, and hence have 
 support for PKCE if following best practices.
 
  
 
 The advantages or requiring PKCE are:
 
  
 
 - a simpler programming model across all OAuth applications and profiles 
 as they all use PKCE
 
  
 
 - reduced attack surface when using  S256 as a fingerprint of the verifier 
 is sent through the browser instead of the clear text value
 
  
 
 - enforcement by AS not client - makes it easier to handle for client 
 developers and AS can ensure the check is conducted
 
  
 
 What are disadvantages besides the potential impact to OpenID Connect 
 deployments? How significant is that impact?
 
  
 
 Dick, Aaron, and Torsten
 
  
 
 ᐧ
 
 ___
 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
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> Vennlig hilsen
> 
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
>  
> | stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no | 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Steinar Noem]

So, wouldn't a MUST just mean that we would have some OPs that are 2.1
compliant and some that aren't?

ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt :

> Mike,
>
> The point of 2.1 is to raise the security bar.
>
> Yes it adds new MUST requirements.
>
> But what about OIDC would break other than required implementation of PKCE
> to support 2.1?
>
> Eg Would additional signaling be required to facilitate interoperability
> and migration between versions? Would that be an oauth issue or an OIDC one?
>
> Phil
>
> On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
>
> 
> > In particular, authorization servers shouldn’t be required to support
> PKCE when they already support the OpenID Connect nonce.
>
> The Security BCP already requires that ASs support PKCE:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2..1.1
>  Are
> you suggesting that the Security BCP change that requirement as well? If
> so, that's a discussion that needs to be had ASAP. If not, then that's an
> implicit statement that it's okay for OpenID Connect implementations to not
> be best-practice OAuth implementations. And if that's the case, then I also
> think it's acceptable that they are not complete OAuth 2.1 implementations
> either.
>
>
>
>
>
>
> On Wed, May 6, 2020 at 11:21 AM Mike Jones  40microsoft@dmarc.ietf.org> wrote:
>
>> The disadvantage of requiring PKCE for OpenID Connect implementations is
>> that you’re trying to add a normative requirement that’s not required of
>> OpenID Connect deployments today, which would bifurcate the ecosystem.
>> There are hundreds of implementations (including the 141 certified ones at
>> https://openid.net/certification/), none of which have ever been
>> required to support PKCE.  Therefore, most don’t.
>>
>>
>>
>> Per feedback already provided, I believe that OAuth 2.1 should align with
>> the guidance already in the draft Security BCP, requiring EITHER the use of
>> PKCE or 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 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 the OpenID Connect nonce.  Doing so would unnecessarily break
>> things and create confusion in the marketplace.
>>
>>
>>
>>   -- Mike
>>
>>
>>
>> *From:* OAuth  *On 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 some of the issues that PKCE protects against. We think
>> that most OpenID Connect implementations also support OAuth 2.0, and
>> hence have support for PKCE if following best practices.
>>
>>
>>
>> The advantages or requiring PKCE are:
>>
>>
>>
>> - a simpler programming model across all OAuth applications and profiles
>> as they all use PKCE
>>
>>
>>
>> - reduced attack surface when using  S256 as a fingerprint of the
>> verifier is sent through the browser instead of the clear text value
>>
>>
>>
>> - enforcement by AS not client - makes it easier to handle for client
>> developers and AS can ensure the check is conducted
>>
>>
>>
>> What are disadvantages besides the potential impact to OpenID Connect
>> deployments? How significant is that impact?
>>
>>
>>
>> Dick, Aaron, and Torsten
>>
>>
>>
>> ᐧ
>> ___
>> 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
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no |
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phillip Hunt]

Mike,

The point of 2.1 is to raise the security bar. 

Yes it adds new MUST requirements. 

But what about OIDC would break other than required implementation of PKCE to 
support 2.1?

Eg Would additional signaling be required to facilitate interoperability and 
migration between versions? Would that be an oauth issue or an OIDC one?

Phil

> On May 6, 2020, at 11:56 AM, Aaron Parecki  wrote:
> 
> 
> > In particular, authorization servers shouldn’t be required to support PKCE 
> > when they already support the OpenID Connect nonce.
> 
> The Security BCP already requires that ASs support PKCE: 
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.1 
> Are you suggesting that the Security BCP change that requirement as well? If 
> so, that's a discussion that needs to be had ASAP. If not, then that's an 
> implicit statement that it's okay for OpenID Connect implementations to not 
> be best-practice OAuth implementations. And if that's the case, then I also 
> think it's acceptable that they are not complete OAuth 2.1 implementations 
> either.
> 
> 
> 
> 
> 
> 
>> On Wed, May 6, 2020 at 11:21 AM Mike Jones 
>>  wrote:
>> The disadvantage of requiring PKCE for OpenID Connect implementations is 
>> that you’re trying to add a normative requirement that’s not required of 
>> OpenID Connect deployments today, which would bifurcate the ecosystem.  
>> There are hundreds of implementations (including the 141 certified ones at 
>> https://openid.net/certification/), none of which have ever been required to 
>> support PKCE.  Therefore, most don’t.
>> 
>>  
>> 
>> Per feedback already provided, I believe that OAuth 2.1 should align with 
>> the guidance already in the draft Security BCP, requiring EITHER the use of 
>> PKCE or 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 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 
>> the OpenID Connect nonce.  Doing so would unnecessarily break things and 
>> create confusion in the marketplace.
>> 
>>  
>> 
>>   -- Mike
>> 
>>  
>> 
>> From: OAuth  On 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 some of the issues that PKCE protects against. We think that 
>> most OpenID Connect implementations also support OAuth 2.0, and hence have 
>> support for PKCE if following best practices.
>> 
>>  
>> 
>> The advantages or requiring PKCE are:
>> 
>>  
>> 
>> - a simpler programming model across all OAuth applications and profiles as 
>> they all use PKCE
>> 
>>  
>> 
>> - reduced attack surface when using  S256 as a fingerprint of the verifier 
>> is sent through the browser instead of the clear text value
>> 
>>  
>> 
>> - enforcement by AS not client - makes it easier to handle for client 
>> developers and AS can ensure the check is conducted
>> 
>>  
>> 
>> What are disadvantages besides the potential impact to OpenID Connect 
>> deployments? How significant is that impact?
>> 
>>  
>> 
>> Dick, Aaron, and Torsten
>> 
>>  
>> 
>> ᐧ
>> 
>> ___
>> 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Aaron Parecki]

> In particular, authorization servers shouldn’t be required to support
PKCE when they already support the OpenID Connect nonce.

The Security BCP already requires that ASs support PKCE:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1..1
Are
you suggesting that the Security BCP change that requirement as well? If
so, that's a discussion that needs to be had ASAP. If not, then that's an
implicit statement that it's okay for OpenID Connect implementations to not
be best-practice OAuth implementations. And if that's the case, then I also
think it's acceptable that they are not complete OAuth 2.1 implementations
either.






On Wed, May 6, 2020 at 11:21 AM Mike Jones  wrote:

> The disadvantage of requiring PKCE for OpenID Connect implementations is
> that you’re trying to add a normative requirement that’s not required of
> OpenID Connect deployments today, which would bifurcate the ecosystem.
> There are hundreds of implementations (including the 141 certified ones at
> https://openid.net/certification/), none of which have ever been required
> to support PKCE.  Therefore, most don’t.
>
>
>
> Per feedback already provided, I believe that OAuth 2.1 should align with
> the guidance already in the draft Security BCP, requiring EITHER the use of
> PKCE or 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 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
> the OpenID Connect nonce.  Doing so would unnecessarily break things and
> create confusion in the marketplace.
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth  *On 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 some of the issues that PKCE protects against. We think that
> most OpenID Connect implementations also support OAuth 2.0, and hence have
> support for PKCE if following best practices.
>
>
>
> The advantages or requiring PKCE are:
>
>
>
> - a simpler programming model across all OAuth applications and profiles
> as they all use PKCE
>
>
>
> - reduced attack surface when using  S256 as a fingerprint of the verifier
> is sent through the browser instead of the clear text value
>
>
>
> - enforcement by AS not client - makes it easier to handle for client
> developers and AS can ensure the check is conducted
>
>
>
> What are disadvantages besides the potential impact to OpenID Connect
> deployments? How significant is that impact?
>
>
>
> Dick, Aaron, and Torsten
>
>
>
> ᐧ
> ___
> 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

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

[Mike Jones]

The disadvantage of requiring PKCE for OpenID Connect implementations is that 
you’re trying to add a normative requirement that’s not required of OpenID 
Connect deployments today, which would bifurcate the ecosystem.  There are 
hundreds of implementations (including the 141 certified ones at 
https://openid.net/certification/), none of which have ever been required to 
support PKCE.  Therefore, most don’t.

Per feedback already provided, I believe that OAuth 2.1 should align with the 
guidance already in the draft Security BCP, requiring EITHER the use of PKCE or 
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 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 the OpenID 
Connect nonce.  Doing so would unnecessarily break things and create confusion 
in the marketplace.

  -- Mike

From: OAuth  On 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 some of the issues that PKCE protects against. We think that most OpenID 
Connect implementations also support OAuth 2.0, and hence have support for PKCE 
if following best practices.

The advantages or requiring PKCE are:

- a simpler programming model across all OAuth applications and profiles as 
they all use PKCE

- reduced attack surface when using  S256 as a fingerprint of the verifier is 
sent through the browser instead of the clear text value

- enforcement by AS not client - makes it easier to handle for client 
developers and AS can ensure the check is conducted

What are disadvantages besides the potential impact to OpenID Connect 
deployments? How significant is that impact?

Dick, Aaron, and Torsten

[https://mailfoogae..appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D=zerocontent=452438ba-d429-4656-ace9-b284744bc171]ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

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 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
> WhatsApp: +1 816.678.4152
>
>
> On Wed, Mar 18, 2020 at 7:55 AM Justin Richer  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
>>
>> ___
> 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

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

[Jared Jennings]

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
WhatsApp: +1 816.678.4152


On Wed, Mar 18, 2020 at 7:55 AM Justin Richer  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
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

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  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
> WhatsApp: +1 816.678.4152
> 
> 
> On Thu, Mar 12, 2020 at 1:15 PM Vittorio Bertocci 
> mailto:40auth0@dmarc.ietf.org>> 
> wrote:
> 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 
>  > 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  > wrote:
> 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 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 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 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 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 > > 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 > > 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 

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

[Jared Jennings]

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  wrote:

> 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  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  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  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 :
>>
>> 
>> 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 
>>> 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.*

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

[Vittorio Bertocci]

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  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  wrote:
>
>> 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
 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 :
>
> 
> 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 
>> 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 

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

[Brian Campbell]

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 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.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 :

 
 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 
> 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

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

[Dick Hardt]

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
>> 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 :
>>>
>>> 
>>> 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 
 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.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

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.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 :
>>
>> 
>> 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 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  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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

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 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 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 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  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
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

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 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 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  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 
  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

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

[Dick Hardt]

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 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  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

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

[Brian Campbell]

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  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 
> 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

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

[Justin Richer]

Again — isn’t this just the client credentials grant but with extra steps?

 — Justin

> On Mar 1, 2020, at 11:33 AM, Phillip Hunt  wrote:
> 
> Why not just require service accounts to use mutually acceptable http method 
> of authentication?  Eg instead id/password, service acnt client could use 
> mtls auth or http basic or some other method.  
> 
> AFAIK this is already widely done. 
> 
> Is there so much interop value that specifying only the weakest form of 
> authentication is warranted?
> 
> Phil
> 
>> On Mar 1, 2020, at 4:09 AM, Dominick Baier  wrote:
>> 
>> 
>> 2) write an OAuth 2.1 extension for service account grants. (the grant type 
>> could continue to be "password", but now clearly in the context of a service 
>> account in a different document)
>> 
>> IMHO - if such a thing gets defined, it should be a separate document. Keep 
>> 2.1 as simple as possible.
>> 
>> ———
>> Dominick Baier
>> 
>> On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com 
>> ) wrote:
>> 
>>> It looks like there is consensus to remove ROPC for a user -- but that the 
>>> password grant is not a bad practice for service accounts. That leads to 
>>> providing clarity on service accounts.
>>> 
>>> 1) add service account grant to the OAuth 2.1 document
>>> 
>>> 2) write an OAuth 2.1 extension for service account grants. (the grant type 
>>> could continue to be "password", but now clearly in the context of a 
>>> service account in a different document)
>>> 
>>> With the goal of OAuth 2..1 being a capture of all the best practices, (2) 
>>> makes more sense as it could discuss all aspects of service accounts 
>>> including mapping a client to a service account. 
>>> 
>>> What do others think?
>>> 
>>> 
>>> ᐧ
>>> 
>>> On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura >> > wrote:
>>> Let us do it then and deprecate ROPC. 
>>> There definitely are use-cases that need this pattern around me as well, 
>>> but we are using JWT bearer grant instead. Standardizing the behavior is 
>>> good. I am fine with new service_account grant type as well, btw. 
>>> 
>>> Nat
>>> 2020年2月25日 20:41 +0900、Neil Madden >> > のメール:
 I’d be open to defining a new service_account grant type and 
 removing/deprecating the ROPC grant. I’d also be happy if we just said 
 that service account flows should use the JWT bearer grant, and we 
 document the best practices around that and encourage client libs to 
 implement support for it.
 
 Should there be a dedicated draft for best practices for 
 service-to-service usage?
 
 — Neil
 
> On 25 Feb 2020, at 00:13, Aaron Parecki  > wrote:
> 
> I think we might be going about this discussion the wrong way.
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  > wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  > wrote:
> I’m not really sure the WG should be telling people what they “ought to 
> be doing” unless we have concrete security or interoperability reasons 
> for doing so.
> 
> I 100% agree that the job of a standard is not to tell people "what they 
> ought to be doing". Instead, a standard is more about documenting the 
> current state of the art as deployed in existing implementations.
> 
> With that in mind, I think that leaves us with two concrete problems with 
> the password grant:
> 
> 1) The actual problem with the password grant is end users entering 
> passwords in applications, which the group (mostly) agrees on
> 2) People are re-appropriating the password grant for things like service 
> accounts or backends that are inflexible, not actually using it for end 
> user credentials
> 
> So it seems like there's actually something missing from OAuth which is 
> leading people to find the password grant and use that because it's the 
> only thing that most closely fits their existing model. It seems like 
> we'd be better off defining a new extension that captures the use case 
> people are actually doing, instead of encouraging the continuing use of 
> the password grant for this purpose.
> 
> 
> Aaron Parecki
> aaronparecki.com 
> @aaronpk
> 
> 
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  > wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  > wrote:
> I’m not really sure the WG should be telling people what they “ought to 
> be doing” unless we have concrete security or interoperability reasons 
> for doing so.

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

[Dick Hardt]

That sounds like a good addition to a separate document Phil.
ᐧ

On Sun, Mar 1, 2020 at 8:33 AM Phillip Hunt 
wrote:

> Why not just require service accounts to use mutually acceptable http
> method of authentication?  Eg instead id/password, service acnt client
> could use mtls auth or http basic or some other method.
>
> AFAIK this is already widely done.
>
> Is there so much interop value that specifying only the weakest form of
> authentication is warranted?
>
> Phil
>
> On Mar 1, 2020, at 4:09 AM, Dominick Baier 
> wrote:
>
> 
> 2) write an OAuth 2.1 extension for service account grants. (the grant
> type could continue to be "password", but now clearly in the context of a
> service account in a different document)
>
> IMHO - if such a thing gets defined, it should be a separate document.
> Keep 2.1 as simple as possible.
>
> ———
> Dominick Baier
>
> On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com) wrote:
>
> It looks like there is consensus to remove ROPC for a user -- but that the
> password grant is not a bad practice for service accounts. That leads to
> providing clarity on service accounts.
>
> 1) add service account grant to the OAuth 2.1 document
>
> 2) write an OAuth 2.1 extension for service account grants. (the grant
> type could continue to be "password", but now clearly in the context of a
> service account in a different document)
>
> With the goal of OAuth 2..1 being a capture of all the best practices, (2)
> makes more sense as it could discuss all aspects of service accounts
> including mapping a client to a service account.
>
> What do others think?
>
>
> ᐧ
>
> On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura  wrote:
>
>> Let us do it then and deprecate ROPC.
>> There definitely are use-cases that need this pattern around me as well,
>> but we are using JWT bearer grant instead. Standardizing the behavior is
>> good. I am fine with new service_account grant type as well, btw.
>>
>> Nat
>> 2020年2月25日 20:41 +0900、Neil Madden  のメール:
>>
>> I’d be open to defining a new service_account grant type and
>> removing/deprecating the ROPC grant. I’d also be happy if we just said that
>> service account flows should use the JWT bearer grant, and we document the
>> best practices around that and encourage client libs to implement support
>> for it.
>>
>> Should there be a dedicated draft for best practices for
>> service-to-service usage?
>>
>> — Neil
>>
>> On 25 Feb 2020, at 00:13, Aaron Parecki  wrote:
>>
>> I think we might be going about this discussion the wrong way.
>>
>> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>> Concur with the sentiment expressed by Neil here.
>>
>> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
>> wrote:
>> I’m not really sure the WG should be telling people what they “ought to
>> be doing” unless we have concrete security or interoperability reasons for
>> doing so.
>>
>> I 100% agree that the job of a standard is not to tell people "what they
>> ought to be doing". Instead, a standard is more about documenting the
>> current state of the art as deployed in existing implementations.
>>
>> With that in mind, I think that leaves us with two concrete problems with
>> the password grant:
>>
>> 1) The actual problem with the password grant is end users entering
>> passwords in applications, which the group (mostly) agrees on
>> 2) People are re-appropriating the password grant for things like service
>> accounts or backends that are inflexible, not actually using it for end
>> user credentials
>>
>> So it seems like there's actually something missing from OAuth which is
>> leading people to find the password grant and use that because it's the
>> only thing that most closely fits their existing model. It seems like we'd
>> be better off defining a new extension that captures the use case people
>> are actually doing, instead of encouraging the continuing use of the
>> password grant for this purpose.
>>
>> 
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk
>>
>>
>>
>> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>> Concur with the sentiment expressed by Neil here.
>>
>> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
>> wrote:
>> I’m not really sure the WG should be telling people what they “ought to
>> be doing” unless we have concrete security or interoperability reasons for
>> doing so.
>>
>> I also don’t agree that people doing this are doing anything wrong. I
>> don’t always agree with what our customers do, but I’ve learnt over the
>> years not to second-guess their reasons for doing it.
>>
>> Are Google wrong for using the JWT bearer grant (not client credentials)
>> and service accounts? They even go so far as to say “scopes are not a
>> security mechanism” [1] and tell people to use service account roles
>> instead. (Precisely because they also support non-OAuth auth methods, which
>> bypass any scopes).
>>
>> Are we really going to tell them to rewrite 

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

[Phillip Hunt]

Why not just require service accounts to use mutually acceptable http method of 
authentication?  Eg instead id/password, service acnt client could use mtls 
auth or http basic or some other method.  

AFAIK this is already widely done. 

Is there so much interop value that specifying only the weakest form of 
authentication is warranted?

Phil

> On Mar 1, 2020, at 4:09 AM, Dominick Baier  wrote:
> 
> 
> 2) write an OAuth 2.1 extension for service account grants. (the grant type 
> could continue to be "password", but now clearly in the context of a service 
> account in a different document)
> 
> IMHO - if such a thing gets defined, it should be a separate document. Keep 
> 2.1 as simple as possible.
> 
> ———
> Dominick Baier
> 
>> On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com) wrote:
>> 
>> It looks like there is consensus to remove ROPC for a user -- but that the 
>> password grant is not a bad practice for service accounts. That leads to 
>> providing clarity on service accounts.
>> 
>> 1) add service account grant to the OAuth 2.1 document
>> 
>> 2) write an OAuth 2.1 extension for service account grants. (the grant type 
>> could continue to be "password", but now clearly in the context of a service 
>> account in a different document)
>> 
>> With the goal of OAuth 2..1 being a capture of all the best practices, (2) 
>> makes more sense as it could discuss all aspects of service accounts 
>> including mapping a client to a service account. 
>> 
>> What do others think?
>> 
>> 
>> ᐧ
>> 
>>> On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura  wrote:
>>> Let us do it then and deprecate ROPC. 
>>> There definitely are use-cases that need this pattern around me as well, 
>>> but we are using JWT bearer grant instead. Standardizing the behavior is 
>>> good. I am fine with new service_account grant type as well, btw. 
>>> 
>>> Nat
>>> 2020年2月25日 20:41 +0900、Neil Madden  のメール:
 I’d be open to defining a new service_account grant type and 
 removing/deprecating the ROPC grant. I’d also be happy if we just said 
 that service account flows should use the JWT bearer grant, and we 
 document the best practices around that and encourage client libs to 
 implement support for it.
 
 Should there be a dedicated draft for best practices for 
 service-to-service usage?
 
 — Neil
 
> On 25 Feb 2020, at 00:13, Aaron Parecki  wrote:
> 
> I think we might be going about this discussion the wrong way.
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  
> wrote:
> I’m not really sure the WG should be telling people what they “ought to 
> be doing” unless we have concrete security or interoperability reasons 
> for doing so.
> 
> I 100% agree that the job of a standard is not to tell people "what they 
> ought to be doing". Instead, a standard is more about documenting the 
> current state of the art as deployed in existing implementations.
> 
> With that in mind, I think that leaves us with two concrete problems with 
> the password grant:
> 
> 1) The actual problem with the password grant is end users entering 
> passwords in applications, which the group (mostly) agrees on
> 2) People are re-appropriating the password grant for things like service 
> accounts or backends that are inflexible, not actually using it for end 
> user credentials
> 
> So it seems like there's actually something missing from OAuth which is 
> leading people to find the password grant and use that because it's the 
> only thing that most closely fits their existing model. It seems like 
> we'd be better off defining a new extension that captures the use case 
> people are actually doing, instead of encouraging the continuing use of 
> the password grant for this purpose.
> 
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk
> 
> 
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  
> wrote:
> I’m not really sure the WG should be telling people what they “ought to 
> be doing” unless we have concrete security or interoperability reasons 
> for doing so.
> 
> I also don’t agree that people doing this are doing anything wrong. I 
> don’t always agree with what our customers do, but I’ve learnt over the 
> years not to second-guess their reasons for doing it.
> 
> Are Google wrong for using the JWT bearer grant (not client credentials) 
> and service accounts? They even go so far as to say “scopes are not a 
> security mechanism” [1] and tell people to use service account roles 
> instead. (Precisely because they also support 

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

[Dominick Baier]

2) write an OAuth 2.1 extension for service account grants. (the grant type
could continue to be "password", but now clearly in the context of a
service account in a different document)

IMHO - if such a thing gets defined, it should be a separate document. Keep
2.1 as simple as possible.

———
Dominick Baier

On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com) wrote:

It looks like there is consensus to remove ROPC for a user -- but that the
password grant is not a bad practice for service accounts. That leads to
providing clarity on service accounts.

1) add service account grant to the OAuth 2.1 document

2) write an OAuth 2.1 extension for service account grants. (the grant type
could continue to be "password", but now clearly in the context of a
service account in a different document)

With the goal of OAuth 2.1 being a capture of all the best practices, (2)
makes more sense as it could discuss all aspects of service accounts
including mapping a client to a service account.

What do others think?


ᐧ

On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura  wrote:

> Let us do it then and deprecate ROPC.
> There definitely are use-cases that need this pattern around me as well,
> but we are using JWT bearer grant instead. Standardizing the behavior is
> good. I am fine with new service_account grant type as well, btw.
>
> Nat
> 2020年2月25日 20:41 +0900、Neil Madden  のメール:
>
> I’d be open to defining a new service_account grant type and
> removing/deprecating the ROPC grant. I’d also be happy if we just said that
> service account flows should use the JWT bearer grant, and we document the
> best practices around that and encourage client libs to implement support
> for it.
>
> Should there be a dedicated draft for best practices for
> service-to-service usage?
>
> — Neil
>
> On 25 Feb 2020, at 00:13, Aaron Parecki  wrote:
>
> I think we might be going about this discussion the wrong way.
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> wrote:
> I’m not really sure the WG should be telling people what they “ought to be
> doing” unless we have concrete security or interoperability reasons for
> doing so.
>
> I 100% agree that the job of a standard is not to tell people "what they
> ought to be doing". Instead, a standard is more about documenting the
> current state of the art as deployed in existing implementations.
>
> With that in mind, I think that leaves us with two concrete problems with
> the password grant:
>
> 1) The actual problem with the password grant is end users entering
> passwords in applications, which the group (mostly) agrees on
> 2) People are re-appropriating the password grant for things like service
> accounts or backends that are inflexible, not actually using it for end
> user credentials
>
> So it seems like there's actually something missing from OAuth which is
> leading people to find the password grant and use that because it's the
> only thing that most closely fits their existing model. It seems like we'd
> be better off defining a new extension that captures the use case people
> are actually doing, instead of encouraging the continuing use of the
> password grant for this purpose.
>
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>
>
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> wrote:
> I’m not really sure the WG should be telling people what they “ought to be
> doing” unless we have concrete security or interoperability reasons for
> doing so.
>
> I also don’t agree that people doing this are doing anything wrong. I
> don’t always agree with what our customers do, but I’ve learnt over the
> years not to second-guess their reasons for doing it.
>
> Are Google wrong for using the JWT bearer grant (not client credentials)
> and service accounts? They even go so far as to say “scopes are not a
> security mechanism” [1] and tell people to use service account roles
> instead. (Precisely because they also support non-OAuth auth methods, which
> bypass any scopes).
>
> Are we really going to tell them to rewrite it all to use the client
> credentials grant?
>
> [1]:
> https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
>
> On 21 Feb 2020, at 21:04, Justin Richer  wrote:
>
> +1. I’ve seen this anti-pattern deployed all over the place, and it’s time
> to get rid of it and send people toward what they really ought to be doing.
>
> Another thing I’ve seen is using different service accounts to get
> different sets of access for one client — if you’re doing that, you’ve got
> a client pretending to do two different things, or your APIs should be
> using scopes to differentiate access instead of client/user identity.
>
> — Justin
>
> On Feb 21, 2020, at 

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

[Dick Hardt]

It looks like there is consensus to remove ROPC for a user -- but that the
password grant is not a bad practice for service accounts. That leads to
providing clarity on service accounts.

1) add service account grant to the OAuth 2.1 document

2) write an OAuth 2.1 extension for service account grants. (the grant type
could continue to be "password", but now clearly in the context of a
service account in a different document)

With the goal of OAuth 2.1 being a capture of all the best practices, (2)
makes more sense as it could discuss all aspects of service accounts
including mapping a client to a service account.

What do others think?


ᐧ

On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura  wrote:

> Let us do it then and deprecate ROPC.
> There definitely are use-cases that need this pattern around me as well,
> but we are using JWT bearer grant instead. Standardizing the behavior is
> good. I am fine with new service_account grant type as well, btw.
>
> Nat
> 2020年2月25日 20:41 +0900、Neil Madden  のメール:
>
> I’d be open to defining a new service_account grant type and
> removing/deprecating the ROPC grant. I’d also be happy if we just said that
> service account flows should use the JWT bearer grant, and we document the
> best practices around that and encourage client libs to implement support
> for it.
>
> Should there be a dedicated draft for best practices for
> service-to-service usage?
>
> — Neil
>
> On 25 Feb 2020, at 00:13, Aaron Parecki  wrote:
>
> I think we might be going about this discussion the wrong way.
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> wrote:
> I’m not really sure the WG should be telling people what they “ought to be
> doing” unless we have concrete security or interoperability reasons for
> doing so.
>
> I 100% agree that the job of a standard is not to tell people "what they
> ought to be doing". Instead, a standard is more about documenting the
> current state of the art as deployed in existing implementations.
>
> With that in mind, I think that leaves us with two concrete problems with
> the password grant:
>
> 1) The actual problem with the password grant is end users entering
> passwords in applications, which the group (mostly) agrees on
> 2) People are re-appropriating the password grant for things like service
> accounts or backends that are inflexible, not actually using it for end
> user credentials
>
> So it seems like there's actually something missing from OAuth which is
> leading people to find the password grant and use that because it's the
> only thing that most closely fits their existing model. It seems like we'd
> be better off defining a new extension that captures the use case people
> are actually doing, instead of encouraging the continuing use of the
> password grant for this purpose.
>
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>
>
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> wrote:
> I’m not really sure the WG should be telling people what they “ought to be
> doing” unless we have concrete security or interoperability reasons for
> doing so.
>
> I also don’t agree that people doing this are doing anything wrong. I
> don’t always agree with what our customers do, but I’ve learnt over the
> years not to second-guess their reasons for doing it.
>
> Are Google wrong for using the JWT bearer grant (not client credentials)
> and service accounts? They even go so far as to say “scopes are not a
> security mechanism” [1] and tell people to use service account roles
> instead. (Precisely because they also support non-OAuth auth methods, which
> bypass any scopes).
>
> Are we really going to tell them to rewrite it all to use the client
> credentials grant?
>
> [1]:
> https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
>
> On 21 Feb 2020, at 21:04, Justin Richer  wrote:
>
> +1. I’ve seen this anti-pattern deployed all over the place, and it’s time
> to get rid of it and send people toward what they really ought to be doing.
>
> Another thing I’ve seen is using different service accounts to get
> different sets of access for one client — if you’re doing that, you’ve got
> a client pretending to do two different things, or your APIs should be
> using scopes to differentiate access instead of client/user identity.
>
> — Justin
>
> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
>
> The client IDs can still be opaque identifiers provided by the AS, they
> just happen to be associated with specific service accounts. Or they could
> be the opaque IDs that the AS already issued for the service account.
> Either way, the AS could issue a token with the appropriate subject and
> other claims for 

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

[Dick Hardt]

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 
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
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Nat Sakimura]

Let us do it then and deprecate ROPC.
There definitely are use-cases that need this pattern around me as well, but we 
are using JWT bearer grant instead. Standardizing the behavior is good. I am 
fine with new service_account grant type as well, btw.

Nat
2020年2月25日 20:41 +0900、Neil Madden  のメール:
> I’d be open to defining a new service_account grant type and 
> removing/deprecating the ROPC grant. I’d also be happy if we just said that 
> service account flows should use the JWT bearer grant, and we document the 
> best practices around that and encourage client libs to implement support for 
> it.
>
> Should there be a dedicated draft for best practices for service-to-service 
> usage?
>
> — Neil
>
> > On 25 Feb 2020, at 00:13, Aaron Parecki  wrote:
> >
> > I think we might be going about this discussion the wrong way.
> >
> > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
> >  wrote:
> > Concur with the sentiment expressed by Neil here.
> >
> > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  
> > wrote:
> > I’m not really sure the WG should be telling people what they “ought to be 
> > doing” unless we have concrete security or interoperability reasons for 
> > doing so.
> >
> > I 100% agree that the job of a standard is not to tell people "what they 
> > ought to be doing". Instead, a standard is more about documenting the 
> > current state of the art as deployed in existing implementations.
> >
> > With that in mind, I think that leaves us with two concrete problems with 
> > the password grant:
> >
> > 1) The actual problem with the password grant is end users entering 
> > passwords in applications, which the group (mostly) agrees on
> > 2) People are re-appropriating the password grant for things like service 
> > accounts or backends that are inflexible, not actually using it for end 
> > user credentials
> >
> > So it seems like there's actually something missing from OAuth which is 
> > leading people to find the password grant and use that because it's the 
> > only thing that most closely fits their existing model. It seems like we'd 
> > be better off defining a new extension that captures the use case people 
> > are actually doing, instead of encouraging the continuing use of the 
> > password grant for this purpose.
> >
> > 
> > Aaron Parecki
> > aaronparecki.com
> > @aaronpk
> >
> >
> >
> > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
> >  wrote:
> > Concur with the sentiment expressed by Neil here.
> >
> > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  
> > wrote:
> > I’m not really sure the WG should be telling people what they “ought to be 
> > doing” unless we have concrete security or interoperability reasons for 
> > doing so.
> >
> > I also don’t agree that people doing this are doing anything wrong. I don’t 
> > always agree with what our customers do, but I’ve learnt over the years not 
> > to second-guess their reasons for doing it.
> >
> > Are Google wrong for using the JWT bearer grant (not client credentials) 
> > and service accounts? They even go so far as to say “scopes are not a 
> > security mechanism” [1] and tell people to use service account roles 
> > instead. (Precisely because they also support non-OAuth auth methods, which 
> > bypass any scopes).
> >
> > Are we really going to tell them to rewrite it all to use the client 
> > credentials grant?
> >
> > [1]: 
> > https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
> >
> > > On 21 Feb 2020, at 21:04, Justin Richer  wrote:
> > >
> > > +1. I’ve seen this anti-pattern deployed all over the place, and it’s 
> > > time to get rid of it and send people toward what they really ought to be 
> > > doing.
> > >
> > > Another thing I’ve seen is using different service accounts to get 
> > > different sets of access for one client — if you’re doing that, you’ve 
> > > got a client pretending to do two different things, or your APIs should 
> > > be using scopes to differentiate access instead of client/user identity.
> > >
> > > — Justin
> > >
> > > > On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 
> > > >  wrote:
> > > >
> > > > The client IDs can still be opaque identifiers provided by the AS, they 
> > > > just happen to be associated with specific service accounts. Or they 
> > > > could be the opaque IDs that the AS already issued for the service 
> > > > account. Either way, the AS could issue a token with the appropriate 
> > > > subject and other claims for the service account.
> > > >
> > > > If your client identity is bound to a specific service account identity 
> > > > (i.e., the resource owner), then ROPC reduces down to Client 
> > > > Credentials. What's the point in passing two identifiers and two 
> > > > credentials for the same identity?
> > > >
> > > > –
> > > > Annabelle Backman (she/her)
> > > > AWS Identity
> > > > https://aws.amazon.com/identity/
> > > >
> > > >
> > > > On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
> > > >  wrote:
> > > >
> > > > Sorry, I 

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

[Neil Madden]

I’d be open to defining a new service_account grant type and 
removing/deprecating the ROPC grant. I’d also be happy if we just said that 
service account flows should use the JWT bearer grant, and we document the best 
practices around that and encourage client libs to implement support for it.

Should there be a dedicated draft for best practices for service-to-service 
usage?

— Neil

> On 25 Feb 2020, at 00:13, Aaron Parecki  wrote:
> 
> I think we might be going about this discussion the wrong way.
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  wrote:
> Concur with the sentiment expressed by Neil here. 
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  wrote:
> I’m not really sure the WG should be telling people what they “ought to be 
> doing” unless we have concrete security or interoperability reasons for doing 
> so.
> 
> I 100% agree that the job of a standard is not to tell people "what they 
> ought to be doing". Instead, a standard is more about documenting the current 
> state of the art as deployed in existing implementations.
> 
> With that in mind, I think that leaves us with two concrete problems with the 
> password grant:
> 
> 1) The actual problem with the password grant is end users entering passwords 
> in applications, which the group (mostly) agrees on
> 2) People are re-appropriating the password grant for things like service 
> accounts or backends that are inflexible, not actually using it for end user 
> credentials
> 
> So it seems like there's actually something missing from OAuth which is 
> leading people to find the password grant and use that because it's the only 
> thing that most closely fits their existing model. It seems like we'd be 
> better off defining a new extension that captures the use case people are 
> actually doing, instead of encouraging the continuing use of the password 
> grant for this purpose.
> 
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk
> 
> 
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  wrote:
> Concur with the sentiment expressed by Neil here. 
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  wrote:
> I’m not really sure the WG should be telling people what they “ought to be 
> doing” unless we have concrete security or interoperability reasons for doing 
> so.
> 
> I also don’t agree that people doing this are doing anything wrong. I don’t 
> always agree with what our customers do, but I’ve learnt over the years not 
> to second-guess their reasons for doing it.
> 
> Are Google wrong for using the JWT bearer grant (not client credentials) and 
> service accounts? They even go so far as to say “scopes are not a security 
> mechanism” [1] and tell people to use service account roles instead. 
> (Precisely because they also support non-OAuth auth methods, which bypass any 
> scopes).
> 
> Are we really going to tell them to rewrite it all to use the client 
> credentials grant?
> 
> [1]: 
> https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
> 
> > On 21 Feb 2020, at 21:04, Justin Richer  wrote:
> > 
> > +1. I’ve seen this anti-pattern deployed all over the place, and it’s time 
> > to get rid of it and send people toward what they really ought to be doing.
> > 
> > Another thing I’ve seen is using different service accounts to get 
> > different sets of access for one client — if you’re doing that, you’ve got 
> > a client pretending to do two different things, or your APIs should be 
> > using scopes to differentiate access instead of client/user identity. 
> > 
> > — Justin
> > 
> >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 
> >>  wrote:
> >> 
> >> The client IDs can still be opaque identifiers provided by the AS, they 
> >> just happen to be associated with specific service accounts. Or they could 
> >> be the opaque IDs that the AS already issued for the service account. 
> >> Either way, the AS could issue a token with the appropriate subject and 
> >> other claims for the service account.
> >> 
> >> If your client identity is bound to a specific service account identity 
> >> (i.e., the resource owner), then ROPC reduces down to Client Credentials. 
> >> What's the point in passing two identifiers and two credentials for the 
> >> same identity?
> >> 
> >> –
> >> Annabelle Backman (she/her)
> >> AWS Identity
> >> https://aws.amazon.com/identity/
> >> 
> >> 
> >> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
> >>  wrote:
> >> 
> >>   Sorry, I missed that message. 
> >> 
> >>   While this may be a solution in specific circumstances, I don’t think 
> >> it’s a general solution. e.g. an AS may not allow manually choosing the 
> >> client_id to avoid things like 
> >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13
> >>  or may return different introspection results for client credentials 
> >> tokens (e.g. with no “sub”) and so on. In practice, this adds even more 
> >> steps for somebody to migrate from existing ROPC usage.
> >> 
> >> 

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

[lanerashaa...@gmail.com]

Sent from my LG Stylo 5+, an AT 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 sentiment expressed by Neil here. On Fri, Feb 21, 2020 at 3:32 PM Neil 
Madden  wrote:I’m not really sure the WG should be 
telling people what they “ought to be doing” unless we have concrete security 
or interoperability reasons for doing so.

I also don’t agree that people doing this are doing anything wrong. I don’t 
always agree with what our customers do, but I’ve learnt over the years not to 
second-guess their reasons for doing it.

Are Google wrong for using the JWT bearer grant (not client credentials) and 
service accounts? They even go so far as to say “scopes are not a security 
mechanism” [1] and tell people to use service account roles instead. (Precisely 
because they also support non-OAuth auth methods, which bypass any scopes).

Are we really going to tell them to rewrite it all to use the client 
credentials grant?

[1]: 
https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam

> On 21 Feb 2020, at 21:04, Justin Richer  wrote:
> 
> +1. I’ve seen this anti-pattern deployed all over the place, and it’s time to 
> get rid of it and send people toward what they really ought to be doing.
> 
> Another thing I’ve seen is using different service accounts to get different 
> sets of access for one client — if you’re doing that, you’ve got a client 
> pretending to do two different things, or your APIs should be using scopes to 
> differentiate access instead of client/user identity. 
> 
> — Justin
> 
>> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 
>> 40amazon@dmarc.ietf.org> wrote:
>> 
>> The client IDs can still be opaque identifiers provided by the AS, they just 
>> happen to be associated with specific service accounts. Or they could be the 
>> opaque IDs that the AS already issued for the service account. Either way, 
>> the AS could issue a token with the appropriate subject and other claims for 
>> the service account.
>> 
>> If your client identity is bound to a specific service account identity 
>> (i.e., the resource owner), then ROPC reduces down to Client Credentials. 
>> What's the point in passing two identifiers and two credentials for the same 
>> identity?
>> 
>> –
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>> 
>> 
>> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>>  wrote:
>> 
>>   Sorry, I missed that message. 
>> 
>>   While this may be a solution in specific circumstances, I don’t think it’s 
>>a general solution. e.g. an AS may not allow manually choosing the client_id 
>>to avoid things like 
>>https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 
>>or may return different introspection results for client credentials tokens 
>>(e.g. with no “sub”) and so on. In practice, this adds even more steps for 
>>somebody to migrate from existing ROPC usage.
>> 
>>   This is asking people to make fundamental changes to their identity 
>>architecture rather than simply switching to a new grant type..
>> 
>>   — Neil
>> 
>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> I see - we have gone full cycle :-) 
>>> 
>>> Annabelle’s proposal would solve that. Relate a client id to a service 
>>> account and obtain the token data from there. 
>>> 
 On 21. Feb 2020, at 15:31, Neil Madden  wrote:
 
 Yes, that is great. But mTLS doesn’t support service accounts (!= 
 clients). Maybe it should? Should there be a mTLS *grant type*?
 
 — Neil
 
> On 21 Feb 2020, at 14:20, Torsten Lodderstedt  
> wrote:
> 
> Have you ever tried the client credentials grant with mTLS? After reading 
> your description it seems to be simpler than JWT Bearer..
> 
> * work out if the AS even supports mTLS
> * work out how to configure the AS to trust my cert(s)
> * Create key pair and cert using openssl
> * Register your (self-signed) cert along with your client_id
> * Configure the HTTP client to use your key pair for TLS Client 
> Authentication
> 
> Works very well for us. 
> 
>> On 21. Feb 2020, at 15:12, Neil Madden  wrote:
>> 
>> No failures, but it is a much more complex grant type to set up, when 
>> you consider everything you have to do:
>> 
>> * work out if the AS even supports JWT bearer and how to turn it on
>> * work out how to configure the AS to trust my public key(s)
>> - do I have to create a new HTTPS endpoint to publish a JWK Set?
>> * determine the correct settings for issuer, audience, subject, etc. 
>> Does the AS impose non-standard requirements? e.g. RFC 7523 says that 
>> the JWT MUST contain a “sub” claim, but Google only allows this to be 
>> 

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

[Aaron Parecki]

I think we might be going about this discussion the wrong way.

On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  wrote:

> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> wrote:
>
>> I’m not really sure the WG should be telling people what they “ought to
>> be doing” unless we have concrete security or interoperability reasons for
>> doing so.
>
>
I 100% agree that the job of a standard is not to tell people "what they
ought to be doing". Instead, a standard is more about documenting the
current state of the art as deployed in existing implementations.

With that in mind, I think that leaves us with two concrete problems with
the password grant:

1) The actual problem with the password grant is end users entering
passwords in applications, which the group (mostly) agrees on
2) People are re-appropriating the password grant for things like service
accounts or backends that are inflexible, not actually using it for end
user credentials

So it seems like there's actually something missing from OAuth which is
leading people to find the password grant and use that because it's the
only thing that most closely fits their existing model. It seems like we'd
be better off defining a new extension that captures the use case people
are actually doing, instead of encouraging the continuing use of the
password grant for this purpose.


Aaron Parecki
aaronparecki.com
@aaronpk 



On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  wrote:

> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> wrote:
>
>> I’m not really sure the WG should be telling people what they “ought to
>> be doing” unless we have concrete security or interoperability reasons for
>> doing so.
>>
>> I also don’t agree that people doing this are doing anything wrong. I
>> don’t always agree with what our customers do, but I’ve learnt over the
>> years not to second-guess their reasons for doing it.
>>
>> Are Google wrong for using the JWT bearer grant (not client credentials)
>> and service accounts? They even go so far as to say “scopes are not a
>> security mechanism” [1] and tell people to use service account roles
>> instead. (Precisely because they also support non-OAuth auth methods, which
>> bypass any scopes).
>>
>> Are we really going to tell them to rewrite it all to use the client
>> credentials grant?
>>
>> [1]:
>> https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
>>
>> > On 21 Feb 2020, at 21:04, Justin Richer  wrote:
>> >
>> > +1. I’ve seen this anti-pattern deployed all over the place, and it’s
>> time to get rid of it and send people toward what they really ought to be
>> doing.
>> >
>> > Another thing I’ve seen is using different service accounts to get
>> different sets of access for one client — if you’re doing that, you’ve got
>> a client pretending to do two different things, or your APIs should be
>> using scopes to differentiate access instead of client/user identity.
>> >
>> > — Justin
>> >
>> >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle > 40amazon@dmarc.ietf.org> wrote:
>> >>
>> >> The client IDs can still be opaque identifiers provided by the AS,
>> they just happen to be associated with specific service accounts. Or they
>> could be the opaque IDs that the AS already issued for the service account.
>> Either way, the AS could issue a token with the appropriate subject and
>> other claims for the service account.
>> >>
>> >> If your client identity is bound to a specific service account
>> identity (i.e., the resource owner), then ROPC reduces down to Client
>> Credentials. What's the point in passing two identifiers and two
>> credentials for the same identity?
>> >>
>> >> –
>> >> Annabelle Backman (she/her)
>> >> AWS Identity
>> >> https://aws.amazon.com/identity/
>> >>
>> >>
>> >> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" <
>> oauth-boun...@ietf.org on behalf of neil.mad...@forgerock.com
>> > wrote:
>> >>
>> >>   Sorry, I missed that message.
>> >>
>> >>   While this may be a solution in specific circumstances, I don’t
>> think it’s a general solution. e.g. an AS may not allow manually choosing
>> the client_id to avoid things like
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13
>> or may return different introspection results for client credentials tokens
>> (e.g. with no “sub”) and so on. In practice, this adds even more steps for
>> somebody to migrate from existing ROPC usage.
>> >>
>> >>   This is asking people to make fundamental changes to their identity
>> architecture rather than simply switching to a new grant type..
>> >>
>> >>   — Neil
>> >>
>> >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>> >>>
>> >>> I see - we have gone full cycle :-)
>> >>>
>> >>> Annabelle’s proposal would solve that. Relate a client id to a
>> service account and obtain the token 

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

[William Denniss]

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 a
> new version of OAuth (“obsoletes” the old RFC), then is not just another
> BCP? If it is a new version and it removes grant types (OAuth 3.0?)


then that effectively has the same impact as removing them from OAuth 2.0,
> unless we’re envisioning some way for a client to negotiate version 2.0
> support from an AS?
>

Many implementations don't support the "password" grant today (and in fact,
never supported it), so it's not like you can rely on its presence for
interop.

If the client needs to negotiate which grant types it can use, then RFC
8414 provides this today with the "grant_types_supported" key.

William



>
> — Neil
>
> > On 22 Feb 2020, at 01:41, Dick Hardt  wrote:
> >
> > I'm a little confused on where this thread is going. If we take ROPC out
> of OAuth 2.1 then:
> >
> > 1) Existing deployments can keep using ROPC - why break it if it is
> working.
> >
> > 2) New deployments can use ROPC and be OAuth 2.0 compliant.
> >
> > 3) New deployments that don't need ROPC can be OAuth 2.1 compliant
>
> ___
> 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

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

[Brian Campbell]

Concur with the sentiment expressed by Neil here.

On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
wrote:

> I’m not really sure the WG should be telling people what they “ought to be
> doing” unless we have concrete security or interoperability reasons for
> doing so.
>
> I also don’t agree that people doing this are doing anything wrong. I
> don’t always agree with what our customers do, but I’ve learnt over the
> years not to second-guess their reasons for doing it.
>
> Are Google wrong for using the JWT bearer grant (not client credentials)
> and service accounts? They even go so far as to say “scopes are not a
> security mechanism” [1] and tell people to use service account roles
> instead. (Precisely because they also support non-OAuth auth methods, which
> bypass any scopes).
>
> Are we really going to tell them to rewrite it all to use the client
> credentials grant?
>
> [1]:
> https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
>
> > On 21 Feb 2020, at 21:04, Justin Richer  wrote:
> >
> > +1. I’ve seen this anti-pattern deployed all over the place, and it’s
> time to get rid of it and send people toward what they really ought to be
> doing.
> >
> > Another thing I’ve seen is using different service accounts to get
> different sets of access for one client — if you’re doing that, you’ve got
> a client pretending to do two different things, or your APIs should be
> using scopes to differentiate access instead of client/user identity.
> >
> > — Justin
> >
> >> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle  40amazon@dmarc.ietf.org> wrote:
> >>
> >> The client IDs can still be opaque identifiers provided by the AS, they
> just happen to be associated with specific service accounts. Or they could
> be the opaque IDs that the AS already issued for the service account.
> Either way, the AS could issue a token with the appropriate subject and
> other claims for the service account.
> >>
> >> If your client identity is bound to a specific service account identity
> (i.e., the resource owner), then ROPC reduces down to Client Credentials.
> What's the point in passing two identifiers and two credentials for the
> same identity?
> >>
> >> –
> >> Annabelle Backman (she/her)
> >> AWS Identity
> >> https://aws.amazon.com/identity/
> >>
> >>
> >> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" <
> oauth-boun...@ietf.org on behalf of neil.mad...@forgerock.com> wrote:
> >>
> >>   Sorry, I missed that message.
> >>
> >>   While this may be a solution in specific circumstances, I don’t think
> it’s a general solution. e.g. an AS may not allow manually choosing the
> client_id to avoid things like
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4..13
> or may return different introspection results for client credentials tokens
> (e.g. with no “sub”) and so on. In practice, this adds even more steps for
> somebody to migrate from existing ROPC usage.
> >>
> >>   This is asking people to make fundamental changes to their identity
> architecture rather than simply switching to a new grant type.
> >>
> >>   — Neil
> >>
> >>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt 
> wrote:
> >>>
> >>> I see - we have gone full cycle :-)
> >>>
> >>> Annabelle’s proposal would solve that. Relate a client id to a service
> account and obtain the token data from there.
> >>>
>  On 21. Feb 2020, at 15:31, Neil Madden 
> wrote:
> 
>  Yes, that is great. But mTLS doesn’t support service accounts (!=
> clients). Maybe it should? Should there be a mTLS *grant type*?
> 
>  — Neil
> 
> > On 21 Feb 2020, at 14:20, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
> >
> > Have you ever tried the client credentials grant with mTLS? After
> reading your description it seems to be simpler than JWT Bearer.
> >
> > * work out if the AS even supports mTLS
> > * work out how to configure the AS to trust my cert(s)
> > * Create key pair and cert using openssl
> > * Register your (self-signed) cert along with your client_id
> > * Configure the HTTP client to use your key pair for TLS Client
> Authentication
> >
> > Works very well for us.
> >
> >> On 21. Feb 2020, at 15:12, Neil Madden 
> wrote:
> >>
> >> No failures, but it is a much more complex grant type to set up,
> when you consider everything you have to do:
> >>
> >> * work out if the AS even supports JWT bearer and how to turn it on
> >> * work out how to configure the AS to trust my public key(s)
> >> - do I have to create a new HTTPS endpoint to publish a JWK Set?
> >> * determine the correct settings for issuer, audience, subject,
> etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says that
> the JWT MUST contain a “sub” claim, but Google only allows this to be
> present if your client is doing impersonation of an end-user (which
> requires additional permissions).
> >> * do I need a unique 

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

[Neil Madden]

But again, I’m talking about existing deployments. If you have an existing 
deployment using ROPC with service accounts and you have tens or hundreds of 
thousands of such accounts, this really sounds like a lot of work to change 
over. 

I forgot one of the other reasons for preferring a service account over an 
OAuth 2 client - some features of OAuth/OIDC require client secrets to be 
recoverable on the AS. For example, if you request an ID token signed with HMAC 
in an implicit/hybrid OIDC flow then this is signed using the client secret as 
the HMAC key. This prevents the AS from hashing the client secret, so 
client_credentials grant introduces security weaknesses compared to an ROPC 
service account flow. So you’d really want to move both to client_credentials 
flow and a more secure authentication mechanism - e.g. mTLS, and public key 
signed/encrypted ID tokens.

(NB: this is not just due to the implicit grant - e.g., CIBA backchannel auth 
in push mode has the same issue if you use HMAC-signed ID tokens).

— Neil


> On 22 Feb 2020, at 01:05, Richard Backman, Annabelle  
> wrote:
> 
> ROPC without a client ID or authentication is functionally equivalent to 
> Client Credentials grant with client secret authentication in the request 
> body. You've just renamed "client_id" to "username" and "client_secret" to 
> "password".
> 
> The AS simply needs to be able to resolve the client ID to the service 
> account. You could use any of the following strategies, depending on the 
> environment:
> * Use service account identifiers as client IDs
> * Use encrypted blobs containing service account identifiers as client IDs, 
> so someone can't choose a client ID by creating a service account with a 
> specific identifier
> * Use opaque values that the AS can resolve to service account identifiers, 
> e.g., via a database lookup
> 
> If the AS needs the service account's password because it's authenticating 
> against a legacy system, then use the service account password as the client 
> secret. Stack mTLS on top, if you want. If the AS just needs to resolve the 
> account so it can put it in tokens that RSes will look at, then you can use 
> whatever client authentication mechanism you want.
> 
> Is there a scenario I'm missing here?
> 
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
> 
> 
> On 2/21/20, 1:53 PM, "Neil Madden"  wrote:
> 
>The AS doesn’t issue the service account IDs, that’s the whole point - 
> integration with existing systems. Lot’s of people don’t have the luxury of 
> rebuilding systems from scratch to fit in with the preferences of the OAuth 
> WG.
> 
>ROPC doesn’t require client authentication, or even a client identifier. 
> If you’re using a service account you indeed don’t need to bother issuing 
> client credentials. The same is true when using the JWT bearer grant. If you 
> want to increase security you can use cert-bound access tokens.
> 
>> On 21 Feb 2020, at 20:28, Richard Backman, Annabelle  
>> wrote:
>> 
>> The client IDs can still be opaque identifiers provided by the AS, they just 
>> happen to be associated with specific service accounts. Or they could be the 
>> opaque IDs that the AS already issued for the service account. Either way, 
>> the AS could issue a token with the appropriate subject and other claims for 
>> the service account.
>> 
>> If your client identity is bound to a specific service account identity 
>> (i.e., the resource owner), then ROPC reduces down to Client Credentials. 
>> What's the point in passing two identifiers and two credentials for the same 
>> identity?
>> 
>> –
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>> 
>> 
>> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>>  wrote:
>> 
>>   Sorry, I missed that message. 
>> 
>>   While this may be a solution in specific circumstances, I don’t think it’s 
>> a general solution. e.g. an AS may not allow manually choosing the client_id 
>> to avoid things like 
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 
>> or may return different introspection results for client credentials tokens 
>> (e.g. with no “sub”) and so on. In practice, this adds even more steps for 
>> somebody to migrate from existing ROPC usage.
>> 
>>   This is asking people to make fundamental changes to their identity 
>> architecture rather than simply switching to a new grant type.
>> 
>>   — Neil
>> 
>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> I see - we have gone full cycle :-) 
>>> 
>>> Annabelle’s proposal would solve that. Relate a client id to a service 
>>> account and obtain the token data from there. 
>>> 
 On 21. Feb 2020, at 15:31, Neil Madden  wrote:
 
 Yes, that is great. But mTLS doesn’t support service accounts (!= 
 clients). Maybe it should? Should there be a mTLS *grant type*?
 
 — Neil
 
> On 21 Feb 2020, at 14:20, Torsten 

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

[Neil Madden]

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 not just another BCP? If it 
is a new version and it removes grant types (OAuth 3.0?) then that effectively 
has the same impact as removing them from OAuth 2.0, unless we’re envisioning 
some way for a client to negotiate version 2.0 support from an AS?

— Neil

> On 22 Feb 2020, at 01:41, Dick Hardt  wrote:
> 
> I'm a little confused on where this thread is going. If we take ROPC out of 
> OAuth 2.1 then:
> 
> 1) Existing deployments can keep using ROPC - why break it if it is working.
> 
> 2) New deployments can use ROPC and be OAuth 2.0 compliant.
> 
> 3) New deployments that don't need ROPC can be OAuth 2.1 compliant

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phillip Hunt]

It may be programmatically equiv but from a trust perspective very different. 

Usually client cred flows are from trusted entities and fixed endpoints. 

Phil

> On Feb 21, 2020, at 5:05 PM, Richard Backman, Annabelle 
>  wrote:
> 
> ROPC without a client ID or authentication is functionally equivalent to 
> Client Credentials grant with client secret authentication in the request 
> body. You've just renamed "client_id" to "username" and "client_secret" to 
> "password".
> 
> The AS simply needs to be able to resolve the client ID to the service 
> account. You could use any of the following strategies, depending on the 
> environment:
> * Use service account identifiers as client IDs
> * Use encrypted blobs containing service account identifiers as client IDs, 
> so someone can't choose a client ID by creating a service account with a 
> specific identifier
> * Use opaque values that the AS can resolve to service account identifiers, 
> e.g., via a database lookup
> 
> If the AS needs the service account's password because it's authenticating 
> against a legacy system, then use the service account password as the client 
> secret. Stack mTLS on top, if you want. If the AS just needs to resolve the 
> account so it can put it in tokens that RSes will look at, then you can use 
> whatever client authentication mechanism you want.
> 
> Is there a scenario I'm missing here?
> 
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
> 
> 
> On 2/21/20, 1:53 PM, "Neil Madden"  wrote:
> 
>The AS doesn’t issue the service account IDs, that’s the whole point - 
> integration with existing systems. Lot’s of people don’t have the luxury of 
> rebuilding systems from scratch to fit in with the preferences of the OAuth 
> WG.
> 
>ROPC doesn’t require client authentication, or even a client identifier. 
> If you’re using a service account you indeed don’t need to bother issuing 
> client credentials. The same is true when using the JWT bearer grant. If you 
> want to increase security you can use cert-bound access tokens.
> 
>> On 21 Feb 2020, at 20:28, Richard Backman, Annabelle  
>> wrote:
>> 
>> The client IDs can still be opaque identifiers provided by the AS, they just 
>> happen to be associated with specific service accounts. Or they could be the 
>> opaque IDs that the AS already issued for the service account. Either way, 
>> the AS could issue a token with the appropriate subject and other claims for 
>> the service account.
>> 
>> If your client identity is bound to a specific service account identity 
>> (i.e., the resource owner), then ROPC reduces down to Client Credentials. 
>> What's the point in passing two identifiers and two credentials for the same 
>> identity?
>> 
>> –
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>> 
>> 
>> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>>  wrote:
>> 
>>   Sorry, I missed that message. 
>> 
>>   While this may be a solution in specific circumstances, I don’t think it’s 
>> a general solution. e.g. an AS may not allow manually choosing the client_id 
>> to avoid things like 
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 
>> or may return different introspection results for client credentials tokens 
>> (e.g. with no “sub”) and so on. In practice, this adds even more steps for 
>> somebody to migrate from existing ROPC usage.
>> 
>>   This is asking people to make fundamental changes to their identity 
>> architecture rather than simply switching to a new grant type.
>> 
>>   — Neil
>> 
 On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
 wrote:
>>> 
>>> I see - we have gone full cycle :-)
>>> 
>>> Annabelle’s proposal would solve that. Relate a client id to a service 
>>> account and obtain the token data from there. 
>>> 
 On 21. Feb 2020, at 15:31, Neil Madden  wrote:
 
 Yes, that is great. But mTLS doesn’t support service accounts (!= 
 clients). Maybe it should? Should there be a mTLS *grant type*?
 
 — Neil
 
> On 21 Feb 2020, at 14:20, Torsten Lodderstedt  
> wrote:
> 
> Have you ever tried the client credentials grant with mTLS? After reading 
> your description it seems to be simpler than JWT Bearer.
> 
> * work out if the AS even supports mTLS
> * work out how to configure the AS to trust my cert(s)
> * Create key pair and cert using openssl
> * Register your (self-signed) cert along with your client_id
> * Configure the HTTP client to use your key pair for TLS Client 
> Authentication
> 
> Works very well for us. 
> 
>> On 21. Feb 2020, at 15:12, Neil Madden  wrote:
>> 
>> No failures, but it is a much more complex grant type to set up, when 
>> you consider everything you have to do:
>> 
>> * work out if the AS even supports JWT bearer and how to turn it on
>> * work out how to configure the AS to trust my public 

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

[Dick Hardt]

I'm a little confused on where this thread is going. If we take ROPC out of
OAuth 2.1 then:

1) Existing deployments can keep using ROPC - why break it if it is working..

2) New deployments can use ROPC and be OAuth 2.0 compliant.

3) New deployments that don't need ROPC can be OAuth 2.1 compliant

ᐧ

On Fri, Feb 21, 2020 at 5:05 PM Richard Backman, Annabelle  wrote:

> ROPC without a client ID or authentication is functionally equivalent to
> Client Credentials grant with client secret authentication in the request
> body. You've just renamed "client_id" to "username" and "client_secret" to
> "password".
>
> The AS simply needs to be able to resolve the client ID to the service
> account. You could use any of the following strategies, depending on the
> environment:
> * Use service account identifiers as client IDs
> * Use encrypted blobs containing service account identifiers as client
> IDs, so someone can't choose a client ID by creating a service account with
> a specific identifier
> * Use opaque values that the AS can resolve to service account
> identifiers, e.g., via a database lookup
>
> If the AS needs the service account's password because it's authenticating
> against a legacy system, then use the service account password as the
> client secret. Stack mTLS on top, if you want. If the AS just needs to
> resolve the account so it can put it in tokens that RSes will look at, then
> you can use whatever client authentication mechanism you want.
>
> Is there a scenario I'm missing here?
>
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
>
>
> On 2/21/20, 1:53 PM, "Neil Madden"  wrote:
>
> The AS doesn’t issue the service account IDs, that’s the whole point -
> integration with existing systems. Lot’s of people don’t have the luxury of
> rebuilding systems from scratch to fit in with the preferences of the OAuth
> WG.
>
> ROPC doesn’t require client authentication, or even a client
> identifier. If you’re using a service account you indeed don’t need to
> bother issuing client credentials. The same is true when using the JWT
> bearer grant. If you want to increase security you can use cert-bound
> access tokens.
>
> > On 21 Feb 2020, at 20:28, Richard Backman, Annabelle <
> richa...@amazon.com> wrote:
> >
> > The client IDs can still be opaque identifiers provided by the AS,
> they just happen to be associated with specific service accounts. Or they
> could be the opaque IDs that the AS already issued for the service account.
> Either way, the AS could issue a token with the appropriate subject and
> other claims for the service account.
> >
> > If your client identity is bound to a specific service account
> identity (i.e., the resource owner), then ROPC reduces down to Client
> Credentials. What's the point in passing two identifiers and two
> credentials for the same identity?
> >
> > –
> > Annabelle Backman (she/her)
> > AWS Identity
> > https://aws.amazon.com/identity/
> >
> >
> > On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" <
> oauth-boun...@ietf.org on behalf of neil.mad...@forgerock.com> wrote:
> >
> >Sorry, I missed that message.
> >
> >While this may be a solution in specific circumstances, I don’t
> think it’s a general solution. e.g. an AS may not allow manually choosing
> the client_id to avoid things like
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4..13
> or may return different introspection results for client credentials tokens
> (e.g. with no “sub”) and so on. In practice, this adds even more steps for
> somebody to migrate from existing ROPC usage.
> >
> >This is asking people to make fundamental changes to their
> identity architecture rather than simply switching to a new grant type.
> >
> >— Neil
> >
> >> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
> >>
> >> I see - we have gone full cycle :-)
> >>
> >> Annabelle’s proposal would solve that. Relate a client id to a
> service account and obtain the token data from there.
> >>
> >>> On 21. Feb 2020, at 15:31, Neil Madden 
> wrote:
> >>>
> >>> Yes, that is great. But mTLS doesn’t support service accounts (!=
> clients). Maybe it should? Should there be a mTLS *grant type*?
> >>>
> >>> — Neil
> >>>
>  On 21 Feb 2020, at 14:20, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
> 
>  Have you ever tried the client credentials grant with mTLS? After
> reading your description it seems to be simpler than JWT Bearer.
> 
>  * work out if the AS even supports mTLS
>  * work out how to configure the AS to trust my cert(s)
>  * Create key pair and cert using openssl
>  * Register your (self-signed) cert along with your client_id
>  * Configure the HTTP client to use your key pair for TLS Client

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

[Richard Backman, Annabelle]

ROPC without a client ID or authentication is functionally equivalent to Client 
Credentials grant with client secret authentication in the request body. You've 
just renamed "client_id" to "username" and "client_secret" to "password".

The AS simply needs to be able to resolve the client ID to the service account. 
You could use any of the following strategies, depending on the environment:
* Use service account identifiers as client IDs
* Use encrypted blobs containing service account identifiers as client IDs, so 
someone can't choose a client ID by creating a service account with a specific 
identifier
* Use opaque values that the AS can resolve to service account identifiers, 
e.g., via a database lookup

If the AS needs the service account's password because it's authenticating 
against a legacy system, then use the service account password as the client 
secret. Stack mTLS on top, if you want. If the AS just needs to resolve the 
account so it can put it in tokens that RSes will look at, then you can use 
whatever client authentication mechanism you want.

Is there a scenario I'm missing here?

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 

On 2/21/20, 1:53 PM, "Neil Madden"  wrote:

The AS doesn’t issue the service account IDs, that’s the whole point - 
integration with existing systems. Lot’s of people don’t have the luxury of 
rebuilding systems from scratch to fit in with the preferences of the OAuth WG.

ROPC doesn’t require client authentication, or even a client identifier. If 
you’re using a service account you indeed don’t need to bother issuing client 
credentials. The same is true when using the JWT bearer grant. If you want to 
increase security you can use cert-bound access tokens.

> On 21 Feb 2020, at 20:28, Richard Backman, Annabelle 
 wrote:
> 
> The client IDs can still be opaque identifiers provided by the AS, they 
just happen to be associated with specific service accounts. Or they could be 
the opaque IDs that the AS already issued for the service account. Either way, 
the AS could issue a token with the appropriate subject and other claims for 
the service account.
> 
> If your client identity is bound to a specific service account identity 
(i.e., the resource owner), then ROPC reduces down to Client Credentials. 
What's the point in passing two identifiers and two credentials for the same 
identity?
> 
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
> 
> 
> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
 wrote:
> 
>Sorry, I missed that message. 
> 
>While this may be a solution in specific circumstances, I don’t think 
it’s a general solution. e.g. an AS may not allow manually choosing the 
client_id to avoid things like 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 or 
may return different introspection results for client credentials tokens (e.g. 
with no “sub”) and so on. In practice, this adds even more steps for somebody 
to migrate from existing ROPC usage.
> 
>This is asking people to make fundamental changes to their identity 
architecture rather than simply switching to a new grant type.
> 
>— Neil
> 
>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
wrote:
>> 
>> I see - we have gone full cycle :-) 
>> 
>> Annabelle’s proposal would solve that. Relate a client id to a service 
account and obtain the token data from there. 
>> 
>>> On 21. Feb 2020, at 15:31, Neil Madden  
wrote:
>>> 
>>> Yes, that is great. But mTLS doesn’t support service accounts (!= 
clients). Maybe it should? Should there be a mTLS *grant type*?
>>> 
>>> — Neil
>>> 
 On 21 Feb 2020, at 14:20, Torsten Lodderstedt 
 wrote:
 
 Have you ever tried the client credentials grant with mTLS? After 
reading your description it seems to be simpler than JWT Bearer.
 
 * work out if the AS even supports mTLS
 * work out how to configure the AS to trust my cert(s)
 * Create key pair and cert using openssl
 * Register your (self-signed) cert along with your client_id
 * Configure the HTTP client to use your key pair for TLS Client 
Authentication
 
 Works very well for us. 
 
> On 21. Feb 2020, at 15:12, Neil Madden  
wrote:
> 
> No failures, but it is a much more complex grant type to set up, when 
you consider everything you have to do:
> 
> * work out if the AS even supports JWT bearer and how to turn it on
> * work out how to configure the AS to trust my public key(s)
> - do I have to create a new HTTPS endpoint to publish a JWK Set?
> * determine the correct settings for issuer, audience, subject, etc. 
Does the AS impose non-standard requirements? e.g. RFC 7523 says that the 

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

[Neil Madden]

I’m not really sure the WG should be telling people what they “ought to be 
doing” unless we have concrete security or interoperability reasons for doing 
so.

I also don’t agree that people doing this are doing anything wrong. I don’t 
always agree with what our customers do, but I’ve learnt over the years not to 
second-guess their reasons for doing it.

Are Google wrong for using the JWT bearer grant (not client credentials) and 
service accounts? They even go so far as to say “scopes are not a security 
mechanism” [1] and tell people to use service account roles instead. (Precisely 
because they also support non-OAuth auth methods, which bypass any scopes).

Are we really going to tell them to rewrite it all to use the client 
credentials grant?

[1]: 
https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam

> On 21 Feb 2020, at 21:04, Justin Richer  wrote:
> 
> +1. I’ve seen this anti-pattern deployed all over the place, and it’s time to 
> get rid of it and send people toward what they really ought to be doing.
> 
> Another thing I’ve seen is using different service accounts to get different 
> sets of access for one client — if you’re doing that, you’ve got a client 
> pretending to do two different things, or your APIs should be using scopes to 
> differentiate access instead of client/user identity. 
> 
> — Justin
> 
>> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 
>>  wrote:
>> 
>> The client IDs can still be opaque identifiers provided by the AS, they just 
>> happen to be associated with specific service accounts. Or they could be the 
>> opaque IDs that the AS already issued for the service account. Either way, 
>> the AS could issue a token with the appropriate subject and other claims for 
>> the service account.
>> 
>> If your client identity is bound to a specific service account identity 
>> (i.e., the resource owner), then ROPC reduces down to Client Credentials. 
>> What's the point in passing two identifiers and two credentials for the same 
>> identity?
>> 
>> –
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>> 
>> 
>> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>>  wrote:
>> 
>>   Sorry, I missed that message. 
>> 
>>   While this may be a solution in specific circumstances, I don’t think it’s 
>> a general solution. e.g. an AS may not allow manually choosing the client_id 
>> to avoid things like 
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 
>> or may return different introspection results for client credentials tokens 
>> (e.g. with no “sub”) and so on. In practice, this adds even more steps for 
>> somebody to migrate from existing ROPC usage.
>> 
>>   This is asking people to make fundamental changes to their identity 
>> architecture rather than simply switching to a new grant type.
>> 
>>   — Neil
>> 
>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> I see - we have gone full cycle :-) 
>>> 
>>> Annabelle’s proposal would solve that. Relate a client id to a service 
>>> account and obtain the token data from there. 
>>> 
 On 21. Feb 2020, at 15:31, Neil Madden  wrote:
 
 Yes, that is great. But mTLS doesn’t support service accounts (!= 
 clients). Maybe it should? Should there be a mTLS *grant type*?
 
 — Neil
 
> On 21 Feb 2020, at 14:20, Torsten Lodderstedt  
> wrote:
> 
> Have you ever tried the client credentials grant with mTLS? After reading 
> your description it seems to be simpler than JWT Bearer.
> 
> * work out if the AS even supports mTLS
> * work out how to configure the AS to trust my cert(s)
> * Create key pair and cert using openssl
> * Register your (self-signed) cert along with your client_id
> * Configure the HTTP client to use your key pair for TLS Client 
> Authentication
> 
> Works very well for us. 
> 
>> On 21. Feb 2020, at 15:12, Neil Madden  wrote:
>> 
>> No failures, but it is a much more complex grant type to set up, when 
>> you consider everything you have to do:
>> 
>> * work out if the AS even supports JWT bearer and how to turn it on
>> * work out how to configure the AS to trust my public key(s)
>> - do I have to create a new HTTPS endpoint to publish a JWK Set?
>> * determine the correct settings for issuer, audience, subject, etc. 
>> Does the AS impose non-standard requirements? e.g. RFC 7523 says that 
>> the JWT MUST contain a “sub” claim, but Google only allows this to be 
>> present if your client is doing impersonation of an end-user (which 
>> requires additional permissions).
>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones 
>> might not) If I do, can I reuse the JWT or must it be freshly signed for 
>> every call?
>> * locate and evaluate a JWT library for my language of choice. Monitor 
>> that new dependency for 

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

[Neil Madden]

The AS doesn’t issue the service account IDs, that’s the whole point - 
integration with existing systems. Lot’s of people don’t have the luxury of 
rebuilding systems from scratch to fit in with the preferences of the OAuth WG.

ROPC doesn’t require client authentication, or even a client identifier. If 
you’re using a service account you indeed don’t need to bother issuing client 
credentials. The same is true when using the JWT bearer grant. If you want to 
increase security you can use cert-bound access tokens.

> On 21 Feb 2020, at 20:28, Richard Backman, Annabelle  
> wrote:
> 
> The client IDs can still be opaque identifiers provided by the AS, they just 
> happen to be associated with specific service accounts. Or they could be the 
> opaque IDs that the AS already issued for the service account. Either way, 
> the AS could issue a token with the appropriate subject and other claims for 
> the service account.
> 
> If your client identity is bound to a specific service account identity 
> (i.e., the resource owner), then ROPC reduces down to Client Credentials. 
> What's the point in passing two identifiers and two credentials for the same 
> identity?
> 
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
> 
> 
> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>  wrote:
> 
>Sorry, I missed that message. 
> 
>While this may be a solution in specific circumstances, I don’t think it’s 
> a general solution. e.g. an AS may not allow manually choosing the client_id 
> to avoid things like 
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 
> or may return different introspection results for client credentials tokens 
> (e.g. with no “sub”) and so on. In practice, this adds even more steps for 
> somebody to migrate from existing ROPC usage.
> 
>This is asking people to make fundamental changes to their identity 
> architecture rather than simply switching to a new grant type.
> 
>— Neil
> 
>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
>> wrote:
>> 
>> I see - we have gone full cycle :-) 
>> 
>> Annabelle’s proposal would solve that. Relate a client id to a service 
>> account and obtain the token data from there. 
>> 
>>> On 21. Feb 2020, at 15:31, Neil Madden  wrote:
>>> 
>>> Yes, that is great. But mTLS doesn’t support service accounts (!= clients). 
>>> Maybe it should? Should there be a mTLS *grant type*?
>>> 
>>> — Neil
>>> 
 On 21 Feb 2020, at 14:20, Torsten Lodderstedt  
 wrote:
 
 Have you ever tried the client credentials grant with mTLS? After reading 
 your description it seems to be simpler than JWT Bearer.
 
 * work out if the AS even supports mTLS
 * work out how to configure the AS to trust my cert(s)
 * Create key pair and cert using openssl
 * Register your (self-signed) cert along with your client_id
 * Configure the HTTP client to use your key pair for TLS Client 
 Authentication
 
 Works very well for us. 
 
> On 21. Feb 2020, at 15:12, Neil Madden  wrote:
> 
> No failures, but it is a much more complex grant type to set up, when you 
> consider everything you have to do:
> 
> * work out if the AS even supports JWT bearer and how to turn it on
> * work out how to configure the AS to trust my public key(s)
> - do I have to create a new HTTPS endpoint to publish a JWK Set?
> * determine the correct settings for issuer, audience, subject, etc. Does 
> the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT 
> MUST contain a “sub” claim, but Google only allows this to be present if 
> your client is doing impersonation of an end-user (which requires 
> additional permissions).
> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones 
> might not) If I do, can I reuse the JWT or must it be freshly signed for 
> every call?
> * locate and evaluate a JWT library for my language of choice. Monitor 
> that new dependency for security advisories.
> * choose a suitable signature algorithm (‘ere be dragons)
> * figure out how to distribute the private key to my service
> 
> Compared to “create a service account and POST the username and password 
> to the token endpoint” it adds a little friction. (It also adds a lot of 
> advantages, but it is undeniably more complex).
> 
> — Neil
> 
> 
>> On 21 Feb 2020, at 13:41, Matthew De Haast 
>>  wrote:
>> 
>> I have a feeling that if we had more concise JWT libraries and command 
>> line tools, where using the JWT Bearer grant became a one-liner again 
>> then we wouldn’t be having this conversation. So perhaps removing it is 
>> an incentive to make that happen.
>> 
>> Neil could you elaborate more on this please. What failures are you 
>> currently experiencing/seeing with the JWT Bearer grant? 
>> 
>> Matt
>> 

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

[Justin Richer]

+1. I’ve seen this anti-pattern deployed all over the place, and it’s time to 
get rid of it and send people toward what they really ought to be doing.

Another thing I’ve seen is using different service accounts to get different 
sets of access for one client — if you’re doing that, you’ve got a client 
pretending to do two different things, or your APIs should be using scopes to 
differentiate access instead of client/user identity. 

 — Justin

> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle 
>  wrote:
> 
> The client IDs can still be opaque identifiers provided by the AS, they just 
> happen to be associated with specific service accounts. Or they could be the 
> opaque IDs that the AS already issued for the service account. Either way, 
> the AS could issue a token with the appropriate subject and other claims for 
> the service account.
> 
> If your client identity is bound to a specific service account identity 
> (i.e., the resource owner), then ROPC reduces down to Client Credentials. 
> What's the point in passing two identifiers and two credentials for the same 
> identity?
> 
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
> 
> 
> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>  wrote:
> 
>Sorry, I missed that message. 
> 
>While this may be a solution in specific circumstances, I don’t think it’s 
> a general solution. e.g. an AS may not allow manually choosing the client_id 
> to avoid things like 
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 
> or may return different introspection results for client credentials tokens 
> (e.g. with no “sub”) and so on. In practice, this adds even more steps for 
> somebody to migrate from existing ROPC usage.
> 
>This is asking people to make fundamental changes to their identity 
> architecture rather than simply switching to a new grant type.
> 
>— Neil
> 
>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
>> wrote:
>> 
>> I see - we have gone full cycle :-) 
>> 
>> Annabelle’s proposal would solve that. Relate a client id to a service 
>> account and obtain the token data from there. 
>> 
>>> On 21. Feb 2020, at 15:31, Neil Madden  wrote:
>>> 
>>> Yes, that is great. But mTLS doesn’t support service accounts (!= clients). 
>>> Maybe it should? Should there be a mTLS *grant type*?
>>> 
>>> — Neil
>>> 
 On 21 Feb 2020, at 14:20, Torsten Lodderstedt  
 wrote:
 
 Have you ever tried the client credentials grant with mTLS? After reading 
 your description it seems to be simpler than JWT Bearer.
 
 * work out if the AS even supports mTLS
 * work out how to configure the AS to trust my cert(s)
 * Create key pair and cert using openssl
 * Register your (self-signed) cert along with your client_id
 * Configure the HTTP client to use your key pair for TLS Client 
 Authentication
 
 Works very well for us. 
 
> On 21. Feb 2020, at 15:12, Neil Madden  wrote:
> 
> No failures, but it is a much more complex grant type to set up, when you 
> consider everything you have to do:
> 
> * work out if the AS even supports JWT bearer and how to turn it on
> * work out how to configure the AS to trust my public key(s)
> - do I have to create a new HTTPS endpoint to publish a JWK Set?
> * determine the correct settings for issuer, audience, subject, etc. Does 
> the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT 
> MUST contain a “sub” claim, but Google only allows this to be present if 
> your client is doing impersonation of an end-user (which requires 
> additional permissions).
> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones 
> might not) If I do, can I reuse the JWT or must it be freshly signed for 
> every call?
> * locate and evaluate a JWT library for my language of choice. Monitor 
> that new dependency for security advisories.
> * choose a suitable signature algorithm (‘ere be dragons)
> * figure out how to distribute the private key to my service
> 
> Compared to “create a service account and POST the username and password 
> to the token endpoint” it adds a little friction. (It also adds a lot of 
> advantages, but it is undeniably more complex).
> 
> — Neil
> 
> 
>> On 21 Feb 2020, at 13:41, Matthew De Haast 
>>  wrote:
>> 
>> I have a feeling that if we had more concise JWT libraries and command 
>> line tools, where using the JWT Bearer grant became a one-liner again 
>> then we wouldn’t be having this conversation. So perhaps removing it is 
>> an incentive to make that happen.
>> 
>> Neil could you elaborate more on this please. What failures are you 
>> currently experiencing/seeing with the JWT Bearer grant? 
>> 
>> Matt
>> 
>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden  
>> 

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

[Richard Backman, Annabelle]

The client IDs can still be opaque identifiers provided by the AS, they just 
happen to be associated with specific service accounts. Or they could be the 
opaque IDs that the AS already issued for the service account. Either way, the 
AS could issue a token with the appropriate subject and other claims for the 
service account.

If your client identity is bound to a specific service account identity (i.e., 
the resource owner), then ROPC reduces down to Client Credentials. What's the 
point in passing two identifiers and two credentials for the same identity?

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 

On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden"  wrote:

Sorry, I missed that message. 

While this may be a solution in specific circumstances, I don’t think it’s 
a general solution. e.g. an AS may not allow manually choosing the client_id to 
avoid things like 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 or 
may return different introspection results for client credentials tokens (e.g. 
with no “sub”) and so on. In practice, this adds even more steps for somebody 
to migrate from existing ROPC usage.

This is asking people to make fundamental changes to their identity 
architecture rather than simply switching to a new grant type.

— Neil

> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
wrote:
> 
> I see - we have gone full cycle :-) 
> 
> Annabelle’s proposal would solve that. Relate a client id to a service 
account and obtain the token data from there. 
> 
>> On 21. Feb 2020, at 15:31, Neil Madden  wrote:
>> 
>> Yes, that is great. But mTLS doesn’t support service accounts (!= 
clients). Maybe it should? Should there be a mTLS *grant type*?
>> 
>> — Neil
>> 
>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt  
wrote:
>>> 
>>> Have you ever tried the client credentials grant with mTLS? After 
reading your description it seems to be simpler than JWT Bearer.
>>> 
>>> * work out if the AS even supports mTLS
>>> * work out how to configure the AS to trust my cert(s)
>>> * Create key pair and cert using openssl
>>> * Register your (self-signed) cert along with your client_id
>>> * Configure the HTTP client to use your key pair for TLS Client 
Authentication
>>> 
>>> Works very well for us. 
>>> 
 On 21. Feb 2020, at 15:12, Neil Madden  
wrote:
 
 No failures, but it is a much more complex grant type to set up, when 
you consider everything you have to do:
 
 * work out if the AS even supports JWT bearer and how to turn it on
 * work out how to configure the AS to trust my public key(s)
 - do I have to create a new HTTPS endpoint to publish a JWK Set?
 * determine the correct settings for issuer, audience, subject, etc. 
Does the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT 
MUST contain a “sub” claim, but Google only allows this to be present if your 
client is doing impersonation of an end-user (which requires additional 
permissions).
 * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones 
might not) If I do, can I reuse the JWT or must it be freshly signed for every 
call?
 * locate and evaluate a JWT library for my language of choice. Monitor 
that new dependency for security advisories.
 * choose a suitable signature algorithm (‘ere be dragons)
 * figure out how to distribute the private key to my service
 
 Compared to “create a service account and POST the username and 
password to the token endpoint” it adds a little friction. (It also adds a lot 
of advantages, but it is undeniably more complex).
 
 — Neil
 
 
> On 21 Feb 2020, at 13:41, Matthew De Haast 
 wrote:
> 
> I have a feeling that if we had more concise JWT libraries and 
command line tools, where using the JWT Bearer grant became a one-liner again 
then we wouldn’t be having this conversation. So perhaps removing it is an 
incentive to make that happen.
> 
> Neil could you elaborate more on this please. What failures are you 
currently experiencing/seeing with the JWT Bearer grant? 
> 
> Matt
> 
> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden 
 wrote:
> I have a feeling that if we had more concise JWT libraries and 
command line tools, where using the JWT Bearer grant became a one-liner again 
then we wouldn’t be having this conversation. So perhaps removing it is an 
incentive to make that happen.
> 
> 
>> On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
>> 
>> Neil: are you advocating that password grant be preserved in 2.1? Or 
do you think that service account developers know enough about what they are 
doing to follow what is in 6749?

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

[Torsten Lodderstedt]

It’s difficult to give advise without lot of detailed information. I 
nevertheless give it a try.

Mechanically, the application would need to use a different grant, credential 
instead of ROPC. If such an application today already uses a distinct 
client_id, the AS must be set up to relate this client_id and the service 
account the same app used before directly. With that the respective deployment 
is able to leverage all client authentication methods, including mTLS.

> On 21. Feb 2020, at 16:02, Neil Madden  wrote:
> 
> But we’re talking about existing deployments. Are you suggesting that people 
> should bulk rename all of their clients to match the service accounts (or 
> vice-versa)? 
> 
> — Neil
> 
>> On 21 Feb 2020, at 14:54, Torsten Lodderstedt  
>> wrote:
>> 
>> 
>> 
>>> On 21. Feb 2020, at 15:47, Neil Madden  wrote:
>>> 
>>> Sorry, I missed that message. 
>>> 
>>> While this may be a solution in specific circumstances, I don’t think it’s 
>>> a general solution. e.g. an AS may not allow manually choosing the 
>>> client_id to avoid things like 
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13
>>>  or may return different introspection results for client credentials 
>>> tokens (e.g. with no “sub”) and so on. In practice, this adds even more 
>>> steps for somebody to migrate from existing ROPC usage.
>>> 
>>> This is asking people to make fundamental changes to their identity 
>>> architecture rather than simply switching to a new grant type.
>> 
>> I don’t see this as a fundamental change, it adds another claim/permission 
>> source to a client id.
>> 
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13
>> 
>> This can be solved by either using the id of the service account as sub or 
>> even put the service identity into a dedicated realm. We implemented the 
>> later strategy at Deutsche Telekom couple of yrs ago.
>> 
>>> 
>>> — Neil
>>> 
 On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
 wrote:
 
 I see - we have gone full cycle :-) 
 
 Annabelle’s proposal would solve that. Relate a client id to a service 
 account and obtain the token data from there. 
 
> On 21. Feb 2020, at 15:31, Neil Madden  wrote:
> 
> Yes, that is great. But mTLS doesn’t support service accounts (!= 
> clients). Maybe it should? Should there be a mTLS *grant type*?
> 
> — Neil
> 
>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt  
>> wrote:
>> 
>> Have you ever tried the client credentials grant with mTLS? After 
>> reading your description it seems to be simpler than JWT Bearer.
>> 
>> * work out if the AS even supports mTLS
>> * work out how to configure the AS to trust my cert(s)
>> * Create key pair and cert using openssl
>> * Register your (self-signed) cert along with your client_id
>> * Configure the HTTP client to use your key pair for TLS Client 
>> Authentication
>> 
>> Works very well for us. 
>> 
>>> On 21. Feb 2020, at 15:12, Neil Madden  
>>> wrote:
>>> 
>>> No failures, but it is a much more complex grant type to set up, when 
>>> you consider everything you have to do:
>>> 
>>> * work out if the AS even supports JWT bearer and how to turn it on
>>> * work out how to configure the AS to trust my public key(s)
>>> - do I have to create a new HTTPS endpoint to publish a JWK Set?
>>> * determine the correct settings for issuer, audience, subject, etc. 
>>> Does the AS impose non-standard requirements? e.g. RFC 7523 says that 
>>> the JWT MUST contain a “sub” claim, but Google only allows this to be 
>>> present if your client is doing impersonation of an end-user (which 
>>> requires additional permissions).
>>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones 
>>> might not) If I do, can I reuse the JWT or must it be freshly signed 
>>> for every call?
>>> * locate and evaluate a JWT library for my language of choice. Monitor 
>>> that new dependency for security advisories.
>>> * choose a suitable signature algorithm (‘ere be dragons)
>>> * figure out how to distribute the private key to my service
>>> 
>>> Compared to “create a service account and POST the username and 
>>> password to the token endpoint” it adds a little friction. (It also 
>>> adds a lot of advantages, but it is undeniably more complex).
>>> 
>>> — Neil
>>> 
>>> 
 On 21 Feb 2020, at 13:41, Matthew De Haast 
  wrote:
 
 I have a feeling that if we had more concise JWT libraries and command 
 line tools, where using the JWT Bearer grant became a one-liner again 
 then we wouldn’t be having this conversation. So perhaps removing it 
 is an incentive to make that happen.
 
 Neil could you elaborate more on this please. What failures are you 
 

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

[Neil Madden]

But we’re talking about existing deployments. Are you suggesting that people 
should bulk rename all of their clients to match the service accounts (or 
vice-versa)? 

— Neil

> On 21 Feb 2020, at 14:54, Torsten Lodderstedt  wrote:
> 
> 
> 
>> On 21. Feb 2020, at 15:47, Neil Madden  wrote:
>> 
>> Sorry, I missed that message. 
>> 
>> While this may be a solution in specific circumstances, I don’t think it’s a 
>> general solution. e.g. an AS may not allow manually choosing the client_id 
>> to avoid things like 
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 
>> or may return different introspection results for client credentials tokens 
>> (e.g. with no “sub”) and so on. In practice, this adds even more steps for 
>> somebody to migrate from existing ROPC usage.
>> 
>> This is asking people to make fundamental changes to their identity 
>> architecture rather than simply switching to a new grant type.
> 
> I don’t see this as a fundamental change, it adds another claim/permission 
> source to a client id.
> 
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13
> 
> This can be solved by either using the id of the service account as sub or 
> even put the service identity into a dedicated realm. We implemented the 
> later strategy at Deutsche Telekom couple of yrs ago.
> 
>> 
>> — Neil
>> 
>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> I see - we have gone full cycle :-) 
>>> 
>>> Annabelle’s proposal would solve that. Relate a client id to a service 
>>> account and obtain the token data from there. 
>>> 
 On 21. Feb 2020, at 15:31, Neil Madden  wrote:
 
 Yes, that is great. But mTLS doesn’t support service accounts (!= 
 clients). Maybe it should? Should there be a mTLS *grant type*?
 
 — Neil
 
> On 21 Feb 2020, at 14:20, Torsten Lodderstedt  
> wrote:
> 
> Have you ever tried the client credentials grant with mTLS? After reading 
> your description it seems to be simpler than JWT Bearer.
> 
> * work out if the AS even supports mTLS
> * work out how to configure the AS to trust my cert(s)
> * Create key pair and cert using openssl
> * Register your (self-signed) cert along with your client_id
> * Configure the HTTP client to use your key pair for TLS Client 
> Authentication
> 
> Works very well for us. 
> 
>> On 21. Feb 2020, at 15:12, Neil Madden  wrote:
>> 
>> No failures, but it is a much more complex grant type to set up, when 
>> you consider everything you have to do:
>> 
>> * work out if the AS even supports JWT bearer and how to turn it on
>> * work out how to configure the AS to trust my public key(s)
>> - do I have to create a new HTTPS endpoint to publish a JWK Set?
>> * determine the correct settings for issuer, audience, subject, etc. 
>> Does the AS impose non-standard requirements? e.g. RFC 7523 says that 
>> the JWT MUST contain a “sub” claim, but Google only allows this to be 
>> present if your client is doing impersonation of an end-user (which 
>> requires additional permissions).
>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones 
>> might not) If I do, can I reuse the JWT or must it be freshly signed for 
>> every call?
>> * locate and evaluate a JWT library for my language of choice. Monitor 
>> that new dependency for security advisories.
>> * choose a suitable signature algorithm (‘ere be dragons)
>> * figure out how to distribute the private key to my service
>> 
>> Compared to “create a service account and POST the username and password 
>> to the token endpoint” it adds a little friction. (It also adds a lot of 
>> advantages, but it is undeniably more complex).
>> 
>> — Neil
>> 
>> 
>>> On 21 Feb 2020, at 13:41, Matthew De Haast 
>>>  wrote:
>>> 
>>> I have a feeling that if we had more concise JWT libraries and command 
>>> line tools, where using the JWT Bearer grant became a one-liner again 
>>> then we wouldn’t be having this conversation. So perhaps removing it is 
>>> an incentive to make that happen.
>>> 
>>> Neil could you elaborate more on this please. What failures are you 
>>> currently experiencing/seeing with the JWT Bearer grant? 
>>> 
>>> Matt
>>> 
>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden 
>>>  wrote:
>>> I have a feeling that if we had more concise JWT libraries and command 
>>> line tools, where using the JWT Bearer grant became a one-liner again 
>>> then we wouldn’t be having this conversation. So perhaps removing it is 
>>> an incentive to make that happen.
>>> 
>>> 
 On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
 
 Neil: are you advocating that password grant be preserved in 2.1? Or 
 do you think that service account developers 

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

[Torsten Lodderstedt]

> On 21. Feb 2020, at 15:47, Neil Madden  wrote:
> 
> Sorry, I missed that message. 
> 
> While this may be a solution in specific circumstances, I don’t think it’s a 
> general solution. e.g. an AS may not allow manually choosing the client_id to 
> avoid things like 
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 
> or may return different introspection results for client credentials tokens 
> (e.g. with no “sub”) and so on. In practice, this adds even more steps for 
> somebody to migrate from existing ROPC usage.
> 
> This is asking people to make fundamental changes to their identity 
> architecture rather than simply switching to a new grant type.

I don’t see this as a fundamental change, it adds another claim/permission 
source to a client id.

>  https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13

This can be solved by either using the id of the service account as sub or even 
put the service identity into a dedicated realm. We implemented the later 
strategy at Deutsche Telekom couple of yrs ago.

> 
> — Neil
> 
>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
>> wrote:
>> 
>> I see - we have gone full cycle :-) 
>> 
>> Annabelle’s proposal would solve that. Relate a client id to a service 
>> account and obtain the token data from there. 
>> 
>>> On 21. Feb 2020, at 15:31, Neil Madden  wrote:
>>> 
>>> Yes, that is great. But mTLS doesn’t support service accounts (!= clients). 
>>> Maybe it should? Should there be a mTLS *grant type*?
>>> 
>>> — Neil
>>> 
 On 21 Feb 2020, at 14:20, Torsten Lodderstedt  
 wrote:
 
 Have you ever tried the client credentials grant with mTLS? After reading 
 your description it seems to be simpler than JWT Bearer.
 
 * work out if the AS even supports mTLS
 * work out how to configure the AS to trust my cert(s)
 * Create key pair and cert using openssl
 * Register your (self-signed) cert along with your client_id
 * Configure the HTTP client to use your key pair for TLS Client 
 Authentication
 
 Works very well for us. 
 
> On 21. Feb 2020, at 15:12, Neil Madden  wrote:
> 
> No failures, but it is a much more complex grant type to set up, when you 
> consider everything you have to do:
> 
> * work out if the AS even supports JWT bearer and how to turn it on
> * work out how to configure the AS to trust my public key(s)
> - do I have to create a new HTTPS endpoint to publish a JWK Set?
> * determine the correct settings for issuer, audience, subject, etc. Does 
> the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT 
> MUST contain a “sub” claim, but Google only allows this to be present if 
> your client is doing impersonation of an end-user (which requires 
> additional permissions).
> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones 
> might not) If I do, can I reuse the JWT or must it be freshly signed for 
> every call?
> * locate and evaluate a JWT library for my language of choice. Monitor 
> that new dependency for security advisories.
> * choose a suitable signature algorithm (‘ere be dragons)
> * figure out how to distribute the private key to my service
> 
> Compared to “create a service account and POST the username and password 
> to the token endpoint” it adds a little friction. (It also adds a lot of 
> advantages, but it is undeniably more complex).
> 
> — Neil
> 
> 
>> On 21 Feb 2020, at 13:41, Matthew De Haast 
>>  wrote:
>> 
>> I have a feeling that if we had more concise JWT libraries and command 
>> line tools, where using the JWT Bearer grant became a one-liner again 
>> then we wouldn’t be having this conversation. So perhaps removing it is 
>> an incentive to make that happen.
>> 
>> Neil could you elaborate more on this please. What failures are you 
>> currently experiencing/seeing with the JWT Bearer grant? 
>> 
>> Matt
>> 
>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden  
>> wrote:
>> I have a feeling that if we had more concise JWT libraries and command 
>> line tools, where using the JWT Bearer grant became a one-liner again 
>> then we wouldn’t be having this conversation. So perhaps removing it is 
>> an incentive to make that happen.
>> 
>> 
>>> On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
>>> 
>>> Neil: are you advocating that password grant be preserved in 2.1? Or do 
>>> you think that service account developers know enough about what they 
>>> are doing to follow what is in 6749?
>>> ᐧ
>>> 
>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden  
>>> wrote:
>>> OAuth2 clients are often private to the AS - they live in a database 
>>> that only the AS can access, have attributes specific to their use in 
>>> OAuth2, and so on. Many 

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

[Levi Schuck]

Hello,

I am new to the mailing list.
I support a mTLS grant type.

Client certificate and additional credentials in the request seems
redundant.

While using GCP, the flow seems to be signing a JWT with a private key
known to google, which is then exchanged for a google signed JWT. Beyond
the service account name being included in the JWT, there are no other
credentials exchanged. This flow matches what I read in 7523.

However, the GCP service account JWT exchange also carries the declared
scopes the service account may use. The AS seems to validate these scopes
before issuing a google signed JWT.

Perhaps a mTLS grant exchange can use alg: none as a JWT for a client
assertion, as JWTs already have conventions to include scopes. Or have
another assertion type altogether.

-Levi

On Fri, Feb 21, 2020 at 8:47 AM Neil Madden 
wrote:

> Sorry, I missed that message.
>
> While this may be a solution in specific circumstances, I don’t think it’s
> a general solution. e.g. an AS may not allow manually choosing the
> client_id to avoid things like
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4..13
> or may return different introspection results for client credentials tokens
> (e.g. with no “sub”) and so on. In practice, this adds even more steps for
> somebody to migrate from existing ROPC usage.
>
> This is asking people to make fundamental changes to their identity
> architecture rather than simply switching to a new grant type.
>
> — Neil
>
> > On 21 Feb 2020, at 14:34, Torsten Lodderstedt 
> wrote:
> >
> > I see - we have gone full cycle :-)
> >
> > Annabelle’s proposal would solve that. Relate a client id to a service
> account and obtain the token data from there.
> >
> >> On 21. Feb 2020, at 15:31, Neil Madden 
> wrote:
> >>
> >> Yes, that is great. But mTLS doesn’t support service accounts (!=
> clients). Maybe it should? Should there be a mTLS *grant type*?
> >>
> >> — Neil
> >>
> >>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt 
> wrote:
> >>>
> >>> Have you ever tried the client credentials grant with mTLS? After
> reading your description it seems to be simpler than JWT Bearer.
> >>>
> >>> * work out if the AS even supports mTLS
> >>> * work out how to configure the AS to trust my cert(s)
> >>> * Create key pair and cert using openssl
> >>> * Register your (self-signed) cert along with your client_id
> >>> * Configure the HTTP client to use your key pair for TLS Client
> Authentication
> >>>
> >>> Works very well for us.
> >>>
>  On 21. Feb 2020, at 15:12, Neil Madden 
> wrote:
> 
>  No failures, but it is a much more complex grant type to set up, when
> you consider everything you have to do:
> 
>  * work out if the AS even supports JWT bearer and how to turn it on
>  * work out how to configure the AS to trust my public key(s)
>  - do I have to create a new HTTPS endpoint to publish a JWK Set?
>  * determine the correct settings for issuer, audience, subject, etc.
> Does the AS impose non-standard requirements? e.g. RFC 7523 says that the
> JWT MUST contain a “sub” claim, but Google only allows this to be present
> if your client is doing impersonation of an end-user (which requires
> additional permissions).
>  * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones
> might not) If I do, can I reuse the JWT or must it be freshly signed for
> every call?
>  * locate and evaluate a JWT library for my language of choice.
> Monitor that new dependency for security advisories.
>  * choose a suitable signature algorithm (‘ere be dragons)
>  * figure out how to distribute the private key to my service
> 
>  Compared to “create a service account and POST the username and
> password to the token endpoint” it adds a little friction. (It also adds a
> lot of advantages, but it is undeniably more complex).
> 
>  — Neil
> 
> 
> > On 21 Feb 2020, at 13:41, Matthew De Haast  40coil@dmarc.ietf.org> wrote:
> >
> > I have a feeling that if we had more concise JWT libraries and
> command line tools, where using the JWT Bearer grant became a one-liner
> again then we wouldn’t be having this conversation. So perhaps removing it
> is an incentive to make that happen.
> >
> > Neil could you elaborate more on this please. What failures are you
> currently experiencing/seeing with the JWT Bearer grant?
> >
> > Matt
> >
> > On Thu, Feb 20, 2020 at 12:42 AM Neil Madden <
> neil.mad...@forgerock.com> wrote:
> > I have a feeling that if we had more concise JWT libraries and
> command line tools, where using the JWT Bearer grant became a one-liner
> again then we wouldn’t be having this conversation. So perhaps removing it
> is an incentive to make that happen.
> >
> >
> >> On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
> >>
> >> Neil: are you advocating that password grant be preserved in 2.1?
> Or do you think that service account developers know 

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

[Neil Madden]

Sorry, I missed that message. 

While this may be a solution in specific circumstances, I don’t think it’s a 
general solution. e.g. an AS may not allow manually choosing the client_id to 
avoid things like 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 or 
may return different introspection results for client credentials tokens (e.g. 
with no “sub”) and so on. In practice, this adds even more steps for somebody 
to migrate from existing ROPC usage.

This is asking people to make fundamental changes to their identity 
architecture rather than simply switching to a new grant type.

— Neil

> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  wrote:
> 
> I see - we have gone full cycle :-) 
> 
> Annabelle’s proposal would solve that. Relate a client id to a service 
> account and obtain the token data from there. 
> 
>> On 21. Feb 2020, at 15:31, Neil Madden  wrote:
>> 
>> Yes, that is great. But mTLS doesn’t support service accounts (!= clients). 
>> Maybe it should? Should there be a mTLS *grant type*?
>> 
>> — Neil
>> 
>>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> Have you ever tried the client credentials grant with mTLS? After reading 
>>> your description it seems to be simpler than JWT Bearer.
>>> 
>>> * work out if the AS even supports mTLS
>>> * work out how to configure the AS to trust my cert(s)
>>> * Create key pair and cert using openssl
>>> * Register your (self-signed) cert along with your client_id
>>> * Configure the HTTP client to use your key pair for TLS Client 
>>> Authentication
>>> 
>>> Works very well for us. 
>>> 
 On 21. Feb 2020, at 15:12, Neil Madden  wrote:
 
 No failures, but it is a much more complex grant type to set up, when you 
 consider everything you have to do:
 
 * work out if the AS even supports JWT bearer and how to turn it on
 * work out how to configure the AS to trust my public key(s)
 - do I have to create a new HTTPS endpoint to publish a JWK Set?
 * determine the correct settings for issuer, audience, subject, etc. Does 
 the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT 
 MUST contain a “sub” claim, but Google only allows this to be present if 
 your client is doing impersonation of an end-user (which requires 
 additional permissions).
 * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones might 
 not) If I do, can I reuse the JWT or must it be freshly signed for every 
 call?
 * locate and evaluate a JWT library for my language of choice. Monitor 
 that new dependency for security advisories.
 * choose a suitable signature algorithm (‘ere be dragons)
 * figure out how to distribute the private key to my service
 
 Compared to “create a service account and POST the username and password 
 to the token endpoint” it adds a little friction. (It also adds a lot of 
 advantages, but it is undeniably more complex).
 
 — Neil
 
 
> On 21 Feb 2020, at 13:41, Matthew De Haast 
>  wrote:
> 
> I have a feeling that if we had more concise JWT libraries and command 
> line tools, where using the JWT Bearer grant became a one-liner again 
> then we wouldn’t be having this conversation. So perhaps removing it is 
> an incentive to make that happen.
> 
> Neil could you elaborate more on this please. What failures are you 
> currently experiencing/seeing with the JWT Bearer grant? 
> 
> Matt
> 
> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden  
> wrote:
> I have a feeling that if we had more concise JWT libraries and command 
> line tools, where using the JWT Bearer grant became a one-liner again 
> then we wouldn’t be having this conversation. So perhaps removing it is 
> an incentive to make that happen.
> 
> 
>> On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
>> 
>> Neil: are you advocating that password grant be preserved in 2.1? Or do 
>> you think that service account developers know enough about what they 
>> are doing to follow what is in 6749?
>> ᐧ
>> 
>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden  
>> wrote:
>> OAuth2 clients are often private to the AS - they live in a database 
>> that only the 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 all users accessing the 
>> system to exist in some user repository, e.g. LDAP, where they can be 
>> looked up and appropriate permissions determined. A service account can 
>> be created inside such a system as if it was a regular user, managed 
>> through the normal account provisioning tools, assigned permissions, 
>> roles, etc.
>> 
>> Another reason is that sometimes OAuth is just one authentication option 
>> out of many, and 

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

[Torsten Lodderstedt]

I see - we have gone full cycle :-) 

Annabelle’s proposal would solve that. Relate a client id to a service account 
and obtain the token data from there. 

> On 21. Feb 2020, at 15:31, Neil Madden  wrote:
> 
> Yes, that is great. But mTLS doesn’t support service accounts (!= clients). 
> Maybe it should? Should there be a mTLS *grant type*?
> 
> — Neil
> 
>> On 21 Feb 2020, at 14:20, Torsten Lodderstedt  
>> wrote:
>> 
>> Have you ever tried the client credentials grant with mTLS? After reading 
>> your description it seems to be simpler than JWT Bearer.
>> 
>> * work out if the AS even supports mTLS
>> * work out how to configure the AS to trust my cert(s)
>> * Create key pair and cert using openssl
>> * Register your (self-signed) cert along with your client_id
>> * Configure the HTTP client to use your key pair for TLS Client 
>> Authentication
>> 
>> Works very well for us. 
>> 
>>> On 21. Feb 2020, at 15:12, Neil Madden  wrote:
>>> 
>>> No failures, but it is a much more complex grant type to set up, when you 
>>> consider everything you have to do:
>>> 
>>> * work out if the AS even supports JWT bearer and how to turn it on
>>> * work out how to configure the AS to trust my public key(s)
>>> - do I have to create a new HTTPS endpoint to publish a JWK Set?
>>> * determine the correct settings for issuer, audience, subject, etc. Does 
>>> the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT 
>>> MUST contain a “sub” claim, but Google only allows this to be present if 
>>> your client is doing impersonation of an end-user (which requires 
>>> additional permissions).
>>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones might 
>>> not) If I do, can I reuse the JWT or must it be freshly signed for every 
>>> call?
>>> * locate and evaluate a JWT library for my language of choice. Monitor that 
>>> new dependency for security advisories.
>>> * choose a suitable signature algorithm (‘ere be dragons)
>>> * figure out how to distribute the private key to my service
>>> 
>>> Compared to “create a service account and POST the username and password to 
>>> the token endpoint” it adds a little friction. (It also adds a lot of 
>>> advantages, but it is undeniably more complex).
>>> 
>>> — Neil
>>> 
>>> 
 On 21 Feb 2020, at 13:41, Matthew De Haast 
  wrote:
 
 I have a feeling that if we had more concise JWT libraries and command 
 line tools, where using the JWT Bearer grant became a one-liner again then 
 we wouldn’t be having this conversation. So perhaps removing it is an 
 incentive to make that happen.
 
 Neil could you elaborate more on this please. What failures are you 
 currently experiencing/seeing with the JWT Bearer grant? 
 
 Matt
 
 On Thu, Feb 20, 2020 at 12:42 AM Neil Madden  
 wrote:
 I have a feeling that if we had more concise JWT libraries and command 
 line tools, where using the JWT Bearer grant became a one-liner again then 
 we wouldn’t be having this conversation. So perhaps removing it is an 
 incentive to make that happen.
 
 
> On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
> 
> Neil: are you advocating that password grant be preserved in 2.1? Or do 
> you think that service account developers know enough about what they are 
> doing to follow what is in 6749?
> ᐧ
> 
> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden  
> wrote:
> OAuth2 clients are often private to the AS - they live in a database that 
> only the 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 all users accessing the system to 
> exist in some user repository, e.g. LDAP, where they can be looked up and 
> appropriate permissions determined. A service account can be created 
> inside such a system as if it was a regular user, managed through the 
> normal account provisioning tools, assigned permissions, roles, etc.
> 
> Another reason is that sometimes OAuth is just one authentication option 
> out of many, and so permissions assigned to service accounts are 
> preferred over scopes because they are consistently applied no matter how 
> a request is authenticated. This is often the case when OAuth has been 
> retrofitted to an existing system and they need to preserve compatibility 
> with already deployed clients.
> 
> See e.g. Google cloud platform (GCP): 
> https://developers.google.com/identity/protocols/OAuth2ServiceAccount
> They use the JWT bearer grant type for service account authentication and 
> assign permissions to those service accounts and typically have very 
> broad scopes. For service-to-service API calls you typically get an 
> access token with a single scope that is effectively “all of GCP” and 
> everything is managed at 

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

[Neil Madden]

Yes, that is great. But mTLS doesn’t support service accounts (!= clients). 
Maybe it should? Should there be a mTLS *grant type*?

— Neil

> On 21 Feb 2020, at 14:20, Torsten Lodderstedt  wrote:
> 
> Have you ever tried the client credentials grant with mTLS? After reading 
> your description it seems to be simpler than JWT Bearer.
> 
> * work out if the AS even supports mTLS
> * work out how to configure the AS to trust my cert(s)
> * Create key pair and cert using openssl
> * Register your (self-signed) cert along with your client_id
> * Configure the HTTP client to use your key pair for TLS Client Authentication
> 
> Works very well for us. 
> 
>> On 21. Feb 2020, at 15:12, Neil Madden  wrote:
>> 
>> No failures, but it is a much more complex grant type to set up, when you 
>> consider everything you have to do:
>> 
>> * work out if the AS even supports JWT bearer and how to turn it on
>> * work out how to configure the AS to trust my public key(s)
>> - do I have to create a new HTTPS endpoint to publish a JWK Set?
>> * determine the correct settings for issuer, audience, subject, etc. Does 
>> the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT 
>> MUST contain a “sub” claim, but Google only allows this to be present if 
>> your client is doing impersonation of an end-user (which requires additional 
>> permissions).
>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones might 
>> not) If I do, can I reuse the JWT or must it be freshly signed for every 
>> call?
>> * locate and evaluate a JWT library for my language of choice. Monitor that 
>> new dependency for security advisories.
>> * choose a suitable signature algorithm (‘ere be dragons)
>> * figure out how to distribute the private key to my service
>> 
>> Compared to “create a service account and POST the username and password to 
>> the token endpoint” it adds a little friction. (It also adds a lot of 
>> advantages, but it is undeniably more complex).
>> 
>> — Neil
>> 
>> 
>>> On 21 Feb 2020, at 13:41, Matthew De Haast  
>>> wrote:
>>> 
>>> I have a feeling that if we had more concise JWT libraries and command line 
>>> tools, where using the JWT Bearer grant became a one-liner again then we 
>>> wouldn’t be having this conversation. So perhaps removing it is an 
>>> incentive to make that happen.
>>> 
>>> Neil could you elaborate more on this please. What failures are you 
>>> currently experiencing/seeing with the JWT Bearer grant? 
>>> 
>>> Matt
>>> 
>>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden  
>>> wrote:
>>> I have a feeling that if we had more concise JWT libraries and command line 
>>> tools, where using the JWT Bearer grant became a one-liner again then we 
>>> wouldn’t be having this conversation. So perhaps removing it is an 
>>> incentive to make that happen.
>>> 
>>> 
 On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
 
 Neil: are you advocating that password grant be preserved in 2.1? Or do 
 you think that service account developers know enough about what they are 
 doing to follow what is in 6749?
 ᐧ
 
 On Wed, Feb 19, 2020 at 1:52 PM Neil Madden  
 wrote:
 OAuth2 clients are often private to the AS - they live in a database that 
 only the 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 all users accessing the system to 
 exist in some user repository, e.g. LDAP, where they can be looked up and 
 appropriate permissions determined. A service account can be created 
 inside such a system as if it was a regular user, managed through the 
 normal account provisioning tools, assigned permissions, roles, etc.
 
 Another reason is that sometimes OAuth is just one authentication option 
 out of many, and so permissions assigned to service accounts are preferred 
 over scopes because they are consistently applied no matter how a request 
 is authenticated. This is often the case when OAuth has been retrofitted 
 to an existing system and they need to preserve compatibility with already 
 deployed clients.
 
 See e.g. Google cloud platform (GCP): 
 https://developers.google.com/identity/protocols/OAuth2ServiceAccount
 They use the JWT bearer grant type for service account authentication and 
 assign permissions to those service accounts and typically have very broad 
 scopes. For service-to-service API calls you typically get an access token 
 with a single scope that is effectively “all of GCP” and everything is 
 managed at the level of permissions on the RO service account itself. They 
 only break down fine-grained scopes when you are dealing with user data 
 and will be getting an access token approved by a real user (through a 
 normal auth code flow).
 
 — Neil
 
> On 19 Feb 2020, at 21:35, Torsten Lodderstedt 

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

[Torsten Lodderstedt]

Have you ever tried the client credentials grant with mTLS? After reading your 
description it seems to be simpler than JWT Bearer.

* work out if the AS even supports mTLS
* work out how to configure the AS to trust my cert(s)
* Create key pair and cert using openssl
* Register your (self-signed) cert along with your client_id
* Configure the HTTP client to use your key pair for TLS Client Authentication

Works very well for us. 

> On 21. Feb 2020, at 15:12, Neil Madden  wrote:
> 
> No failures, but it is a much more complex grant type to set up, when you 
> consider everything you have to do:
> 
> * work out if the AS even supports JWT bearer and how to turn it on
> * work out how to configure the AS to trust my public key(s)
>  - do I have to create a new HTTPS endpoint to publish a JWK Set?
> * determine the correct settings for issuer, audience, subject, etc. Does the 
> AS impose non-standard requirements? e.g. RFC 7523 says that the JWT MUST 
> contain a “sub” claim, but Google only allows this to be present if your 
> client is doing impersonation of an end-user (which requires additional 
> permissions).
> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones might 
> not) If I do, can I reuse the JWT or must it be freshly signed for every call?
> * locate and evaluate a JWT library for my language of choice. Monitor that 
> new dependency for security advisories.
> * choose a suitable signature algorithm (‘ere be dragons)
> * figure out how to distribute the private key to my service
> 
> Compared to “create a service account and POST the username and password to 
> the token endpoint” it adds a little friction. (It also adds a lot of 
> advantages, but it is undeniably more complex).
> 
> — Neil
> 
> 
>> On 21 Feb 2020, at 13:41, Matthew De Haast  
>> wrote:
>> 
>> I have a feeling that if we had more concise JWT libraries and command line 
>> tools, where using the JWT Bearer grant became a one-liner again then we 
>> wouldn’t be having this conversation. So perhaps removing it is an incentive 
>> to make that happen.
>> 
>> Neil could you elaborate more on this please. What failures are you 
>> currently experiencing/seeing with the JWT Bearer grant? 
>> 
>> Matt
>> 
>> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden  
>> wrote:
>> I have a feeling that if we had more concise JWT libraries and command line 
>> tools, where using the JWT Bearer grant became a one-liner again then we 
>> wouldn’t be having this conversation. So perhaps removing it is an incentive 
>> to make that happen.
>> 
>> 
>>> On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
>>> 
>>> Neil: are you advocating that password grant be preserved in 2.1? Or do you 
>>> think that service account developers know enough about what they are doing 
>>> to follow what is in 6749?
>>> ᐧ
>>> 
>>> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden  
>>> wrote:
>>> OAuth2 clients are often private to the AS - they live in a database that 
>>> only the 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 all users accessing the system to 
>>> exist in some user repository, e.g. LDAP, where they can be looked up and 
>>> appropriate permissions determined. A service account can be created inside 
>>> such a system as if it was a regular user, managed through the normal 
>>> account provisioning tools, assigned permissions, roles, etc.
>>> 
>>> Another reason is that sometimes OAuth is just one authentication option 
>>> out of many, and so permissions assigned to service accounts are preferred 
>>> over scopes because they are consistently applied no matter how a request 
>>> is authenticated. This is often the case when OAuth has been retrofitted to 
>>> an existing system and they need to preserve compatibility with already 
>>> deployed clients.
>>> 
>>> See e.g. Google cloud platform (GCP): 
>>> https://developers.google.com/identity/protocols/OAuth2ServiceAccount
>>> They use the JWT bearer grant type for service account authentication and 
>>> assign permissions to those service accounts and typically have very broad 
>>> scopes. For service-to-service API calls you typically get an access token 
>>> with a single scope that is effectively “all of GCP” and everything is 
>>> managed at the level of permissions on the RO service account itself. They 
>>> only break down fine-grained scopes when you are dealing with user data and 
>>> will be getting an access token approved by a real user (through a normal 
>>> auth code flow).
>>> 
>>> — Neil
>>> 
 On 19 Feb 2020, at 21:35, Torsten Lodderstedt  
 wrote:
 
 Can you explain more in detail why the client credentials grant type isn’t 
 applicable for the kind of use cases you mentioned?
 
> Am 19.02.2020 um 22:03 schrieb Neil Madden :
> 
> I very much agree with this with regards to real users. 
> 
> The one 

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

[Neil Madden]

No failures, but it is a much more complex grant type to set up, when you 
consider everything you have to do:

* work out if the AS even supports JWT bearer and how to turn it on
* work out how to configure the AS to trust my public key(s)
  - do I have to create a new HTTPS endpoint to publish a JWK Set?
* determine the correct settings for issuer, audience, subject, etc. Does the 
AS impose non-standard requirements? e.g. RFC 7523 says that the JWT MUST 
contain a “sub” claim, but Google only allows this to be present if your client 
is doing impersonation of an end-user (which requires additional permissions).
* do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones might not) 
If I do, can I reuse the JWT or must it be freshly signed for every call?
* locate and evaluate a JWT library for my language of choice. Monitor that new 
dependency for security advisories.
* choose a suitable signature algorithm (‘ere be dragons)
* figure out how to distribute the private key to my service

Compared to “create a service account and POST the username and password to the 
token endpoint” it adds a little friction. (It also adds a lot of advantages, 
but it is undeniably more complex).

— Neil


> On 21 Feb 2020, at 13:41, Matthew De Haast  
> wrote:
> 
> I have a feeling that if we had more concise JWT libraries and command line 
> tools, where using the JWT Bearer grant became a one-liner again then we 
> wouldn’t be having this conversation. So perhaps removing it is an incentive 
> to make that happen.
> 
> Neil could you elaborate more on this please. What failures are you currently 
> experiencing/seeing with the JWT Bearer grant? 
> 
> Matt
> 
> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden  
> wrote:
> I have a feeling that if we had more concise JWT libraries and command line 
> tools, where using the JWT Bearer grant became a one-liner again then we 
> wouldn’t be having this conversation. So perhaps removing it is an incentive 
> to make that happen.
> 
> 
> > On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
> > 
> > Neil: are you advocating that password grant be preserved in 2.1? Or do you 
> > think that service account developers know enough about what they are doing 
> > to follow what is in 6749?
> > ᐧ
> > 
> > On Wed, Feb 19, 2020 at 1:52 PM Neil Madden  
> > wrote:
> > OAuth2 clients are often private to the AS - they live in a database that 
> > only the 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 all users accessing the system to 
> > exist in some user repository, e.g. LDAP, where they can be looked up and 
> > appropriate permissions determined. A service account can be created inside 
> > such a system as if it was a regular user, managed through the normal 
> > account provisioning tools, assigned permissions, roles, etc.
> > 
> > Another reason is that sometimes OAuth is just one authentication option 
> > out of many, and so permissions assigned to service accounts are preferred 
> > over scopes because they are consistently applied no matter how a request 
> > is authenticated. This is often the case when OAuth has been retrofitted to 
> > an existing system and they need to preserve compatibility with already 
> > deployed clients.
> > 
> > See e.g. Google cloud platform (GCP): 
> > https://developers.google.com/identity/protocols/OAuth2ServiceAccount
> > They use the JWT bearer grant type for service account authentication and 
> > assign permissions to those service accounts and typically have very broad 
> > scopes. For service-to-service API calls you typically get an access token 
> > with a single scope that is effectively “all of GCP” and everything is 
> > managed at the level of permissions on the RO service account itself. They 
> > only break down fine-grained scopes when you are dealing with user data and 
> > will be getting an access token approved by a real user (through a normal 
> > auth code flow).
> > 
> > — Neil
> > 
> > > On 19 Feb 2020, at 21:35, Torsten Lodderstedt  
> > > wrote:
> > > 
> > > Can you explain more in detail why the client credentials grant type 
> > > isn’t applicable for the kind of use cases you mentioned?
> > > 
> > >> Am 19.02.2020 um 22:03 schrieb Neil Madden :
> > >> 
> > >> 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 something like client_credentials but for 
> > >> whatever reason you need the RO to be a service user rather than an 
> > >> 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 harder to implement. Having recently converted some code from ROPC 
> > >> to JWT bearer for exactly 

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

[Matthew De Haast]

>
> I have a feeling that if we had more concise JWT libraries and command
> line tools, where using the JWT Bearer grant became a one-liner again then
> we wouldn’t be having this conversation. So perhaps removing it is an
> incentive to make that happen.
>

Neil could you elaborate more on this please. What failures are you
currently experiencing/seeing with the JWT Bearer grant?

Matt

On Thu, Feb 20, 2020 at 12:42 AM Neil Madden 
wrote:

> I have a feeling that if we had more concise JWT libraries and command
> line tools, where using the JWT Bearer grant became a one-liner again then
> we wouldn’t be having this conversation. So perhaps removing it is an
> incentive to make that happen.
>
>
> > On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
> >
> > Neil: are you advocating that password grant be preserved in 2.1? Or do
> you think that service account developers know enough about what they are
> doing to follow what is in 6749?
> > ᐧ
> >
> > On Wed, Feb 19, 2020 at 1:52 PM Neil Madden 
> wrote:
> > OAuth2 clients are often private to the AS - they live in a database
> that only the 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 all users accessing the
> system to exist in some user repository, e.g. LDAP, where they can be
> looked up and appropriate permissions determined. A service account can be
> created inside such a system as if it was a regular user, managed through
> the normal account provisioning tools, assigned permissions, roles, etc.
> >
> > Another reason is that sometimes OAuth is just one authentication option
> out of many, and so permissions assigned to service accounts are preferred
> over scopes because they are consistently applied no matter how a request
> is authenticated. This is often the case when OAuth has been retrofitted to
> an existing system and they need to preserve compatibility with already
> deployed clients.
> >
> > See e.g. Google cloud platform (GCP):
> https://developers.google.com/identity/protocols/OAuth2ServiceAccount
> > They use the JWT bearer grant type for service account authentication
> and assign permissions to those service accounts and typically have very
> broad scopes. For service-to-service API calls you typically get an access
> token with a single scope that is effectively “all of GCP” and everything
> is managed at the level of permissions on the RO service account itself.
> They only break down fine-grained scopes when you are dealing with user
> data and will be getting an access token approved by a real user (through a
> normal auth code flow).
> >
> > — Neil
> >
> > > On 19 Feb 2020, at 21:35, Torsten Lodderstedt 
> wrote:
> > >
> > > Can you explain more in detail why the client credentials grant type
> isn’t applicable for the kind of use cases you mentioned?
> > >
> > >> Am 19.02.2020 um 22:03 schrieb Neil Madden  >:
> > >>
> > >> 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 something like client_credentials but
> for whatever reason you need the RO to be a service user rather than an
> 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 harder to implement. 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 added complexity.
> > >>
> > >> — Neil
> > >>
> > >>> On 18 Feb 2020, at 21:57, Hans 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 it is used for migration
> purposes and the migration is actually executed (I know that is
> statistically not a very strong argument but I challenge others to 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 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 world that's already a pretty strong signal.
> > >>>
> > >>> Aaron
> > >>>
> > >>>
> > >>>
> > >>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer 
> wrote:
> > >>> There is no need for a grace period. People using OAuth 2.0 can
> 

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

[Neil Madden]

I have a feeling that if we had more concise JWT libraries and command line 
tools, where using the JWT Bearer grant became a one-liner again then we 
wouldn’t be having this conversation. So perhaps removing it is an incentive to 
make that happen.


> On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
> 
> Neil: are you advocating that password grant be preserved in 2.1? Or do you 
> think that service account developers know enough about what they are doing 
> to follow what is in 6749?
> ᐧ
> 
> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden  wrote:
> OAuth2 clients are often private to the AS - they live in a database that 
> only the 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 all users accessing the system to exist in 
> some user repository, e.g. LDAP, where they can be looked up and appropriate 
> permissions determined. A service account can be created inside such a system 
> as if it was a regular user, managed through the normal account provisioning 
> tools, assigned permissions, roles, etc.
> 
> Another reason is that sometimes OAuth is just one authentication option out 
> of many, and so permissions assigned to service accounts are preferred over 
> scopes because they are consistently applied no matter how a request is 
> authenticated. This is often the case when OAuth has been retrofitted to an 
> existing system and they need to preserve compatibility with already deployed 
> clients.
> 
> See e.g. Google cloud platform (GCP): 
> https://developers.google.com/identity/protocols/OAuth2ServiceAccount
> They use the JWT bearer grant type for service account authentication and 
> assign permissions to those service accounts and typically have very broad 
> scopes. For service-to-service API calls you typically get an access token 
> with a single scope that is effectively “all of GCP” and everything is 
> managed at the level of permissions on the RO service account itself. They 
> only break down fine-grained scopes when you are dealing with user data and 
> will be getting an access token approved by a real user (through a normal 
> auth code flow).
> 
> — Neil
> 
> > On 19 Feb 2020, at 21:35, Torsten Lodderstedt  
> > wrote:
> > 
> > Can you explain more in detail why the client credentials grant type isn’t 
> > applicable for the kind of use cases you mentioned?
> > 
> >> Am 19.02.2020 um 22:03 schrieb Neil Madden :
> >> 
> >> 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 something like client_credentials but for 
> >> whatever reason you need the RO to be a service user rather than an 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 harder to implement. 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 added complexity.
> >> 
> >> — Neil
> >> 
> >>> On 18 Feb 2020, at 21:57, Hans 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 it is used for migration 
> >>> purposes and the migration is actually executed (I know that is 
> >>> statistically not a very strong argument but I challenge others to 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 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 world that's already a pretty strong signal.
> >>> 
> >>> Aaron
> >>> 
> >>> 
> >>> 
> >>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer  wrote:
> >>> There is no need for a grace period. People using OAuth 2.0 can still do 
> >>> OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. 
> >>> 
> >>> — Justin
> >>> 
> > On Feb 18, 2020, at 3:54 PM, Anthony Nadalin 
> >  wrote:
>  
>  I would suggest a SHOULD NOT instead of MUST, there are still sites 
>  using this and a grace period should be provided before a MUST is pushed 
>  out as there are valid use cases out there still.
>  
>  From: OAuth  On