Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt

Hi All, In section *4.1.3. Countermeasures * related to *4.1. Insufficient Redirect URI Validation* it states The complexity of implementing and managing pattern matching correctly obviously causes security

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

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

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

That text is a worse suggestion. It hopelessly confuses "end-user" and "client". The idea behind the text is only relevant to a client that is written to call a resource server and is registered with an authorization server, but thinks that the details those two exchange (via access tokens) at

Re: [OAUTH-WG] Incorporate or Reference RFC8628 Device Authorization Grant?

Works for me From: OAuth On Behalf Of Aaron Parecki Sent: Tuesday, May 12, 2020 2:44 PM To: Phillip Hunt Cc: OAuth WG Subject: Re: [OAUTH-WG] Incorporate or Reference RFC8628 Device Authorization Grant? I have a draft I'm about to publish after our recent discussions. One of the changes is

Re: [OAUTH-WG] Incorporate or Reference RFC8628 Device Authorization Grant?

I have a draft I'm about to publish after our recent discussions. One of the changes is adding an appendix that lists out a bunch of existing OAuth extensions, and the device grant is in there. I also replaced the "Extension Grants" example in section 4.3 (

[OAUTH-WG] Incorporate or Reference RFC8628 Device Authorization Grant?

One of the use cases brought up in the ROPC thread mentioned that redirect was hard to do in some cases (like IoT). This reminded me of RFC8628, the OAuth Device Authorization Grant. I mention it because for *some* of the cases who say redirection is hard may be able to use the Device Authz

Re: [OAUTH-WG] OAuth 2.1 - recalling 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. As RFC 6749 clearly targets third-party applications, ROPC never has been a good fit. It always

[OAUTH-WG] May 11th Interim Meeting Minutes

All, The minuets for the May 11th interim meeting can be found here: https://datatracker.ietf.org/meeting/interim-2020-oauth-08/materials/minutes-interim-2020-oauth-08-202005111200 Again, thanks to Jarred Jennings for taking these minutes. Regards, Rifaat

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

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

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

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

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

[OAUTH-WG] Example of financial aggregator authorization

Hey all, As mentioned on the call yesterday, here's an example of Capital One's financial data sharing flow for aggregators. Intuit's Mint is used in this example but others like Simplifi (Quicken) also use this flow. Chase and Capital One are the only two of my personal financial providers

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

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

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hi James, You wrote: "Because your client has violated a MUST in the best practices". It seems that you are already taking your wish as granted. However, this is exactly the point we are discussing. You wrote: "The end-user has to trust the Authorization Server (they sign-in there)". The

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

That text is an poor suggestion, Denis. > end-user will usually have no knowledge of the attributes which correspond to > the scope The OAuth model is that the Authorization Server is responsible for informing the end-user about what is going on. That's why they display consent pages showing

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hi Vittorio, draft-ietf-oauth-access-token-jwt states in section 2.2.2: This profile does not introduce any mechanism for a client to directly request the presence of specific claims in JWT access tokens,   as the authorization server can determine what additional claims are required by a

Re: [OAUTH-WG] Redirect URIs in draft-ietf-oauth-security-topics

Indeed, we shall fix that. Am 11.05.20 um 20:43 schrieb Brian Campbell: > I suspect it was an unintentional oversight in the Security BCP and > that it should be updated to allow for it. > > On Mon, May 11, 2020 at 10:03 AM Aaron Parecki > wrote: > > The Security

Re: [OAUTH-WG] PAR - Can AS/client require request object?

Hello, I'm currently implementing a new OIDC server ( https://github.com/Zenithar/go-solid) with restricted features such as PAR, enforce PKCE, etc. For other clients, that don't have the support of PAR it would be great to be able to detect that PAR is enforced by default. Also, I have a

Re: [OAUTH-WG] Usage of Password Grant

Hi Aaron, What we are planning to build is a Public first party client. As per the spec the client secret is optional for Password Grant. Hence we choose to use a common client_id across all the devices. The first party client on every device will get the common client_id through our

Re: [OAUTH-WG] PAR - Can AS/client require request object?

I think require_request_objects has its place, that place should be JAR, PAR as a backup. I believe doing only the "PAR-specific" name / meaning of it would be a missed opportunity. S pozdravem, *Filip Skokan* On Tue, 12 May 2020 at 08:27, Torsten Lodderstedt wrote: > Hi all, > > I initially

Re: [OAUTH-WG] PAR - Can AS/client require request object?

Hi all, I initially raised the question whether the AS should be able to require request objects for all clients (in the same way as we decided to let the AS required PAR for all clients) but this topic was never discussed later on. I suggest to add a server metadata parameter