[OAUTH-WG] Re: coding agents don't follow the spec for parsing Authorization header

On 6 Jul 2025, at 13:22, Dick Hardt wrote: > > Hey > > I was working with Claude on an MCP server which requires authorization, and > it generated this code, > const authHeader = request.headers.authorization > if (authHeader && authHeader.startsWith('Bearer ')) { >

[OAUTH-WG] Re: Last minute request: Specifying key derivation for HMAC signatures on key binding JWT in SD JWT

> On 13 May 2025, at 12:52, Stefan Santesson wrote: > > Hi, > > We just submitted the following issue on JD JWT GitHub page detailing this > request. > > https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/574 > > Providing the final stage of this document, we would only do th

[OAUTH-WG] Re: Call for adoption - First Party Apps

security of those deployments over them making up their own protocol, won't we?/DickOn Tue, Sep 10, 2024 at 10:20 AM Neil Madden <neil.e.mad...@gmail.com> wrote:The draft is motivated by allowing native apps to provide a login journey for OAuth rather than using the browser. This encourage

[OAUTH-WG] Re: Call for adoption - First Party Apps

at 2:15 AM Neil Madden <neil.e.mad...@gmail.com> wrote:On 5 Sep 2024, at 05:45, David Waite <da...@alkaline-solutions.com> wrote: > >  > >> On Sep 4, 2024, at 4:27 PM, Neil Madden <neil.e.mad...@gmail.com> wrote: >> >>> On 4 Sep 2024, at 22:48,

[OAUTH-WG] Re: Call for adoption - First Party Apps

On 5 Sep 2024, at 05:45, David Waite wrote: > >  > >> On Sep 4, 2024, at 4:27 PM, Neil Madden wrote: >> >>> On 4 Sep 2024, at 22:48, Watson Ladd wrote: >>> >>> I can always grab the cookie jar off the user browser if I have that >>>

[OAUTH-WG] Re: Call for adoption - First Party Apps

On 4 Sep 2024, at 22:48, Watson Ladd wrote: > > On Wed, Sep 4, 2024 at 2:46 PM Neil Madden wrote: >> >> >> >> On 4 Sep 2024, at 21:31, Tim Cappalli wrote: >> >>  >>> >>> Thanks, that’s good to know. Does it preserv

[OAUTH-WG] Re: WGLC for SD-JWT

I haven’t read the latest draft in a lot of detail, but I did check over the cryptographic details again and everything seems reasonable to me. One error I noticed in section 5.2.4.1: "For example, using the digest of the object property Disclosure created above, the Issuer could create the fol

[OAUTH-WG] Re: Call for adoption - First Party Apps

I am a bit skeptical about this one. I’m not convinced we should be recommending native UI until/unless we have a really good story around authenticating first-party apps. Without such a story, I don’t think this should be adopted. Unless I’m mistaken, a native UI also rules out WebAuthn/FIDO-b

[OAUTH-WG] Re: Call for adoption - PIKA

I support adoption. > On 3 Sep 2024, at 11:47, Rifaat Shekh-Yusef wrote: > > All, > > As per the discussion in Vancouver, this is a call for adoption for the Proof > of Issuer Key Authority (PIKA) draft: > https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/ >

[OAUTH-WG] Re: Security Bug | Unintended usage of "state" parameter can lead to Header Injection Attacks

On 1 Jul 2024, at 14:31, Chaitanya Reddy wrote: > > Hi Neil and Filip, > > Thank you so much for the quick revert. > > Neil, in the last statement you mentioned "I would say in this case the onus > falls on the client to validate the state value before blindly copying it > into the Location h

[OAUTH-WG] Re: Security Bug | Unintended usage of "state" parameter can lead to Header Injection Attacks

Section 3.1.2.2 of RFC 6749 says: The authorization server SHOULD require the client to provide the complete redirection URI (the client MAY use the "state" request parameter to achieve per-request customization) So I’d say it is allowed to use the state parameter to hold a URI to redir

[OAUTH-WG] Re: One-time confirmation tokens

On 14 Jun 2024, at 02:48, Dmitry Telegin wrote: > > Let's take the following (very common) scenario: > * A user logs into the system; > * They request an operation that might require additional confirmation from > the user, at the system's discretion. The most common example would be > payment

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

> On 10 May 2024, at 17:07, Sam Goto wrote: > > On Fri, May 10, 2024 at 2:41 AM Neil Madden <mailto:neil.e.mad...@gmail.com>> wrote: > On 9 May 2024, at 21:58, Watson Ladd <mailto:watsonbl...@gmail.com>> wrote: > > > > On Thu, May 9, 2024 at

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

On 9 May 2024, at 21:58, Watson Ladd wrote: > > On Thu, May 9, 2024 at 7:24 AM Neil Madden wrote: >> >> On 9 May 2024, at 00:06, Sam Goto wrote: >> >> [...] >>> >>> >>> I guess, flipping this around, we might ask what is the legi

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

On 9 May 2024, at 00:06, Sam Goto wrote: > [...] > > I guess, flipping this around, we might ask what is the legitimate purpose > for which browsers need to access the user’s name, email address (both > requires) and other identifying information? I’d have thought an identifier > (possibly ran

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

On 8 May 2024, at 22:01, Joseph Heenan wrote:On 8 May 2024, at 21:43, Sam Goto wrote:On Wed, May 8, 2024 at 1:34 PM Joseph Heenan <jos...@authlete.com> wrote:Hi NeilOn 8 May 2024, at 18:45, Neil Madden <neil.e.mad...@gmail.com> wrote:On 8 May 2024, at 17:52, Sam Goto <g...@googl

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

On 8 May 2024, at 21:39, Sam Goto wrote:On Wed, May 8, 2024 at 1:26 PM Neil Madden <neil.e.mad...@gmail.com> wrote:Looking at these slides again, and at the spec, does this even work to defeat tracking? The browser makes two requests to the IdP prior to getting consent from the user:1. To

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

Looking at these slides again, and at the spec, does this even work to defeat tracking? The browser makes two requests to the IdP prior to getting consent from the user:1. To lookup the accounts of the user (identifying the user)2. To lookup the metadata of the client (identifying the RP). Isn’t it

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

On 8 May 2024, at 17:52, Sam Goto wrote:On Wed, May 8, 2024 at 7:23 AM Neil Madden <neil.e.mad...@gmail.com> wrote:Thanks for these slides and recording. This is a fascinating proposal. I have plenty of potential thoughts and comments to digest, but I guess the most fundamental is that thi

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

Thanks for these slides and recording. This is a fascinating proposal. I have plenty of potential thoughts and comments to digest, but I guess the most fundamental is that this spec assumes that users and IdPs will be happy for their browser to be a trusted party involved in login flows. In part

Re: [OAUTH-WG] Signed JWK Sets

I’m not sure this is an official call for adoption, but I support this draft. Regardless of the discussion in the other thread, I think this draft has clear value and is well designed. A couple of thoughts:Presumably it is infeasible for a client to construct a TLS transcript that looks like a vali

Re: [OAUTH-WG] Signed JWK Sets

> On 12 Apr 2024, at 03:16, Ethan Heilman wrote: > >  > Hi Neil, > > I agree that PIKA would not protect against an attacker compromising a JWKS > URI via a mis-issued TLS cert. > > I was thinking of a simpler attack where the attacker compromises the server > where a JWKS URI is hosted or

Re: [OAUTH-WG] Signed JWK Sets

On 11 Apr 2024, at 01:12, Ethan Heilman wrote: > > I want to voice my support for this draft: Proof of Issuer Key Authority > (PIKA). The ability to reason about the past validity of JWKS is extremely > useful for using OIDC in signing CI artifacts and e2e encrypted > messaging.This includes w

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

n instead only the > access token will get narrowed down. > > So Warren and Neil, if possible can you pinpoint to me the exact place in the > spec where it does explicitly say that the refresh token should not be > narrowed down based on the given scopes? > > Thanks &

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

On 21 Feb 2024, at 08:06, Sachin Mamoru wrote: > > Hi Warren and Neil, > > Thanks for the valuable input and sorry for mentioning other products, I just > wanted to provide an example. > So Warren according to you following is the behaviour that spec suggested. > > When we request an access t

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

refresh-tokens/#changing-scope-of-access-token-on-refresh> > > Thanks & Regards, > Sachin > > On Tue, 20 Feb 2024 at 21:59, Neil Madden <mailto:neil.e.mad...@gmail.com>> wrote: > > >> On 20 Feb 2024, at 11:02, Sachin Mamoru > <mailto:sachi

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

<sachinmam...@gmail.com> wrote:On Tue, 20 Feb 2024 at 12:23, Neil Madden <neil.e.mad...@gmail.com> wrote:On 20 Feb 2024, at 06:44, Sachin Mamoru <sachinmam...@gmail.com> wrote:Hi All,When we request an access token using 3 scopes (scope1, scope2, scope3).Then will recei

Re: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

> On 20 Feb 2024, at 06:44, Sachin Mamoru wrote: > >  > Hi All, > > When we request an access token using 3 scopes (scope1, scope2, scope3). > Then will receive a refresh token (refresh_token1) with the access token. > > After that will request another access token with refresh_token1 and pro

Re: [OAUTH-WG] client_id in CWT Claims

RFC8693 didn't register anything for CWT at all. Some other document has registered scope for CWT and pointed at that RFC as the reference for some reason. -- Neil > On 24 Jan 2024, at 18:37, Orie Steele wrote: > > I'm working on a document that has some similarity to EAT from RATS, in that

Re: [OAUTH-WG] Query on correct approach of calculating the "x5t#S256" parameter in the JWKS response

JWS refers to FIPS 180-4 as the definition of SHA-256. That spec defines the message digest produced by SHA-256 as a 256-bit binary value, not a hex-encoded string. So the "base64url-encoded SHA-256 thumbprint (a.k.a. digest)" is your Method 1. Anyone doing Method 2 has a bug. -- Neil > On 10

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

> On 7 Nov 2023, at 15:50, Denis wrote: > > Hi Neil, > >> On 7 Nov 2023, at 13:13, Denis > > wrote: >>> >>> Hi Neil, >>> >>> You wrote: >>> "Note that unlinkability is explicitly already not a goal for SD-JWT >>> according to section 12.4". >>> This is untrue: >>>

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

On 7 Nov 2023, at 13:13, Denis wrote: > > Hi Neil, > > You wrote: > "Note that unlinkability is explicitly already not a goal for SD-JWT > according to section 12.4". > This is untrue: > 12.4. Unlinkability > > Colluding Issuer/Verifier or Verifier/Verifier pairs could link > issuance/presen

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

> On 6 Nov 2023, at 16:43, Watson Ladd wrote: > > On Mon, Nov 6, 2023 at 5:46 AM Neil Madden wrote: > >> >> How about the following: >> >> — >> An Issuer MUST NOT allow any security-critical claim to be selectively >> disclosable. The exac

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

Although I think we could add some basic advice, the list of security headers to use is still evolving. For example, there were several headers added after Spectre to limit cross-site interactions. And then there’s things like the “X-XSS-Protection” header, which was best practice to add to resp

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

Although I think we could add some basic advice, the list of security headers to use is still evolving. For example, there were several headers added after Spectre to limit cross-site interactions. And then there’s things like the “X-XSS-Protection” header, which was best practice to add to resp

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

(while also attempting to snip out and declutter the message). > > On Thu, Oct 26, 2023 at 7:03 AM Neil Madden <mailto:neil.e.mad...@gmail.com>> wrote: >> On 25 Oct 2023, at 22:00, Brian Campbell > <mailto:bcampb...@pingidentity.com>> wrote: > > >>> >

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

On 25 Oct 2023, at 22:00, Brian Campbell wrote:Thanks for the comments and questions Neil. With the help of the draft co-authors, I've tried to reply (probably inadequately!) inline below. Thanks. Some responses below. On Tue, Oct 24, 2023 at 3:48 AM Neil Madden <neil.e.mad...@g

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

I’ve had a look through this new draft and I have some comments and questions. Some of which are similar to comments I already raised [1], but haven’t been addressed. Are we concerned about Holders and Issuers colluding? For example, now that claim names are blinded an Issuer can add the same c

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

I support adoption. I have questions about the specifics which I'll try to write up in the next week or so, but the basic idea seems useful. (The tl;dr of my thoughts is: have we learned everything we can do from the *many* iterations of similar mechanisms in the PKI space?) -- Neil > On 30 Se

Re: [OAUTH-WG] Questions on OAuth Protected Resource Metadata

On 21 Sep 2023, at 17:19, Atul Tulshibagwale wrote: > > Hi all, > I'm still looking for answers to these two questions > > regarding the OPRM draft that was recently adopted by the WG: > If I have a resource server that

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

Right. It’s worth noting that many endpoints already publish similar metadata via OpenAPI (Swagger) API descriptions.NeilOn 27 Aug 2023, at 19:42, Dick Hardt wrote:For many resources, the information is already disclosed. What is excessive to you might be crucial to others -- and my use case, the

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

I support adoption. > On 23 Aug 2023, at 20:02, Rifaat Shekh-Yusef wrote: > >  > All, > > This is an official call for adoption for the Protected Resource Metadata > draft: > https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ > > Please, reply on the mailing list and let

Re: [OAUTH-WG] RFC 9396 - RAR doubt about examples

> On 2 Jun 2023, at 14:10, Oliva Fernandez, Jorge > wrote: > > Hi, > > Reviewing the just releases RFC there are a couple of examples that seems > incorrect or maybe I’m missing something, in section 9.1 and 9.2 appear a > field “debtorAccount” outside the “authorization_details” object an

Re: [OAUTH-WG] redirect uri and portals

On 6 Mar 2023, at 17:10, Yannick Majoros wrote: > > Hello, > > From my understanding, OAuth 2 as well as 2.1 do not allow for wildcards in > redirect_uri . Now, a common requirement for a portal or company-wide > website, where multiple applications are deployed, is to be able to login and >

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-step-up-authn-challenge-12

Surely "rogue" resource servers already have a lot of ways they can annoy their own users? Is this a realistic threat? -- Neil > On 2 Mar 2023, at 08:23, Valery Smyslov wrote: > > Thank you for pointing to the deployment consideration section, I re-read it > :-) > This section is mostly conce

Re: [OAUTH-WG] OAUTH for Web Proxy authentication

Right - RFC 6750 doesn't explicitly define how to send an access token with the Proxy-Authorization/Proxy-Authenticate headers, but states: The Bearer authentication scheme is intended primarily for server authentication using the WWW-Authenticate and Authorization HTTP headers but does

Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)

On 20 Jan 2023, at 18:47, Brian Campbell wrote:Hi Mark,Thanks for the review and feedback. I am aware of HTTP Structured Fields and certainly see value in it - even using it in some other work in which I'm involved. However, I'm unsure of its fit or utility for this draft. With that said, I've tri

Re: [OAUTH-WG] Informal RFC: DPoP using ECDH + HMAC instead of DSA

otocols for secure messaging with forward secrecy. How far is it worth taking this before we're building OAuth 3.0/'mutual' OAuth? (I'm half joking and half serious)On Thu, Jan 5, 2023, at 15:37, Neil Madden wrote:Right. A key difference between what I proposed and what Zack is pro

Re: [OAUTH-WG] Informal RFC: DPoP using ECDH + HMAC instead of DSA

encryption mode is unauthenticated anyway in its intended use). Cheers,NeilPS - I like K-PoP!On 5 Jan 2023, at 00:20, Brian Campbell wrote:Hi Zack,For whatever it's worth, HMAC PoP has been discussed in the past (in a few different incarnations). Neil Madden put forth the idea of a somewhat si

Re: [OAUTH-WG] Call for adoption - SD-JWT

hy is that not practical? — Neil > > That's why I support adoption. > > -- Mike > > From: OAuth On Behalf Of Neil Madden > Sent: Tuesday, August 2, 2022 2:16 AM > To: Kristina Yasuda > Cc: oauth > Sub

Re: [OAUTH-WG] Call for adoption - SD-JWT

> On 2 Aug 2022, at 03:20, Kristina Yasuda > wrote: > > I support adoption. > > To add some color. > > One of the use-cases is a flow where issuance of a user credential > (collection of user claims) is decoupled from presentation (where both > issuance and presentation of a user credent

Re: [OAUTH-WG] Call for adoption - SD-JWT

;>>>> You live in the US and going out to a bar. Bars in the US are infamous >>>>> for carding people. You want to tell them that you are over 21, but don't >>>>> want to tell them anything else. So you take out your digital wallet and >>>

Re: [OAUTH-WG] Call for adoption - SD-JWT

I agree with many of these points that Jaimandeep Singh raises. It would be good to know exactly what the intended use-cases within OAuth are. In particular, in OAuth it’s normally the case that the client is relatively untrusted and a privacy goal is to avoid revealing information/PII to the

Re: [OAUTH-WG] .well-known/jwks.json and constrained-voucher and RFC7517

> On 12 Jul 2022, at 20:26, Michael Richardson wrote: > >  > EXEC-SUM: /.well-known/jwks.json seems in use, but not registered > with IANA. I don't know if it's appropriate for my use. > Seems to contain RFC7517 content. A limitation of the JWKSet format is that it provides

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

> On 28 Jun 2022, at 10:28, Neil Madden wrote: > > >> On 28 Jun 2022, at 08:37, Daniel Fett > <mailto:fett=40danielfett...@dmarc.ietf.org>> wrote: >> >> […] >> >>> >>> The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to l

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

> On 28 Jun 2022, at 08:37, Daniel Fett > wrote: > > […] > >> >> The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to length extension >> attacks is also troubling, even if I can’t see an immediate attack. But it’s >> a weird property that Bob, for example, could make a commitment to som

Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)

I’m not entirely sure the OAuth WG is a suitable venue for this kind of document. It should at least get some review from CFRG, to get feedback on the crypto aspects. I have some initial comments about the cryptography being used. Commitments to claim values are of the form HASH(SALT | CLAIM-V

Re: [OAUTH-WG] DPoP JWT claims

pecially as an >> implementer. When you see or observe these claims in a JWT, you can google >> them potentially returning no results. If you know about the IANA registry >> you can find them, even if you don't know that the tokens have anything to >> do with DPoP

[OAUTH-WG] DPoP JWT claims

The DPoP spec registers the “htm”, “htu”, and “ath” claims [1]. But do these claims actually make sense outside of a DPoP proof? Presumably the risk of naming collision within a DPoP proof is pretty small, so is there any benefit to registering them rather than just using them as private claims?

Re: [OAUTH-WG] Call for adoption - Step-up Authentication

I support adoption of this draft. I’m still digesting the details, but it seems like a good problem to solve. — Neil > On 26 Apr 2022, at 11:46, Rifaat Shekh-Yusef wrote: > > This is a call for adoption for the Step-up Authentication document > https://datatracker.ietf.org/doc/draft-bertocci-o

[OAUTH-WG] Fwd: WGLC for DPoP Document

Forgot to reply to the list: > I support publication. > > — Neil > >> On 28 Mar 2022, at 13:01, Rifaat Shekh-Yusef > > wrote: >> >> All, >> >> As discussed during the IETF meeting in Vienna last week, this is a WG Last >> Call for the DPoP document: >> https://

Re: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document

I also support publication of the new draft (the 01 revision, not the 00 revision linked to in this WGLC! I assume that’s just a mistake). — Neil > On 23 Feb 2022, at 08:59, Vladimir Dzhuvinov wrote: > > +1 in support for publication. > > The Nimbus JWT lib was recently updated to match the 0

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

Thanks, these changes address my comments. I am happy with the new draft text. Cheers, Neil > On 15 Feb 2022, at 00:33, Kristina Yasuda > wrote: > > Hi All, > > Thank you very much for the constructive feedback. > We have tried to address the WGLC comments received to date with the latest

Re: [OAUTH-WG] [EXTERNAL] Re: WGLC for JWK Thumbprint URI document

JWK thumbprint, so let's include it. This will > make things more explicit and self-contained. > > What do the authors think about this possibility? > > ~Vladimir > > Vladimir Dzhuvinov > On 04/02/2022 01:47, Neil Madden wrote: > The draft doesn’t specify which ha

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

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

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

The draft doesn’t specify which hash function is being used. I assume it is SHA-256, but it should either say that is the only algorithm allowed or perhaps encode the hash algorithm into the URI. Otherwise the value is ambiguous. Using a (hash of a) public key as an identifier is an idea that h

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

eason. > > I would personally love to see a bis of this RFC, but because of inertia > around existing deployments, I don’t expect it. I think we’d see a lot of > confusion around which version of things to use. > > — Justin > >> On Dec 9, 2021, at 8:52 AM, Neil Madde

Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

I don’t mind about a new error code, although I think it’s of limited value - error codes (rather than descriptive error *messages*) imply that the client may be able to dynamically react to the situation and so something different. But TLS client certs are usually configured statically, so it s

Re: [OAUTH-WG] dpop_jkt Authorization Request Parameter

Sadly I couldn’t make the DPoP session, but I’m not convinced the attack described in the earlier message really needs to be prevented at all. The attack largely hinges on auth codes not being one-time use, which is not a good idea, or otherwise on poor network security on the token endpoint. I’

Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-04.txt

d use a DPoP-Nonce > response header are already not cacheable - response to POST, 401 challenge, > response to a request containing an authorization header - so I don't think > anything is needed. But let me know if I'm missing something. > > On Wed, Oct 6, 2021

Re: [OAUTH-WG] DPoP and MTLS - friends or foes?

I’m not smart enough to remember in what context I might have said this, but I’d hazard a guess it was somehow related to service mesh. Generally, we allow both to be specified largely because of our support for macaroon access tokens: a proxy could transparently add a mtls binding (for ex) to

Re: [OAUTH-WG] [EXTERNAL] Rotating RTs and grace periods

may > solve for it in other less predictable ways raises a valid point. > > Cheers > > Pieter > > From: OAuth On Behalf Of Neil Madden > Sent: Tuesday 2 November 2021 10:29 > To: oauth > Subject: [EXTERNAL] [OAUTH-WG] Rotating RTs and grace periods > > Hi al

[OAUTH-WG] Rotating RTs and grace periods

Hi all, There was a previous discussion on whether to allow a grace period during refresh token rotation, allowing the client to retry a refresh if the response fails to be received due to some transient network issue/timeout [1]. Vittorio mentioned that Auth0 already implement such a grace per

Re: [OAUTH-WG] [DPoP] Order of validation for DPoP proofs and access tokens

I would express a mild preference for “invalid_token” taking priority in this case. It seems pointless for the client to generate a new DPoP proof (in response to invalid_dpop_proof) if they are then going to get an invalid_token on the next request anyway. If they get a new AT they will natural

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

Are we saying that network connections have got significantly worse over the last decade that we need to drop a security feature? I have so far never heard anyone complain about the one-time use nature of authorization codes. (I hear it about refresh tokens, but not auth codes). I don’t think th

Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

I wasn’t on the call either, so maybe I’m missing something. If you’re using PKCE with the “plain” challenge type then both the auth code and the verifier are exposed in redirect URI parameters in the user-agent aren’t they? That seems a bit risky to drop the one-time use requirement. I can’t

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

Canonicalised signature schemes inevitably lead to cryptographic doom, and should die with SAML (ha!). For that reason I do not support adoption of this draft. I also think the arguments for canonicalisation vanish as soon as you want end-to-end confidentiality too. — Neil > On 6 Oct 2021, a

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-04.txt

Overall I think thus is good, but I have a few comments/suggestions: I think the stateful handling of server-supplied nonces (ie the client reuses the same nonce until the server sends a new one) perhaps needs to be clarified with respect to clients making concurrent requests. Especially clients

Re: [OAUTH-WG] Web apps BCP feedback

> On 26 Sep 2021, at 11:28, Jim Manico wrote: > > > That’s why cookies should be set with the __Host- prefix. > > You can also set the domain of a cookie to actually be a host (subdomain). > Does that also prevent subdomains from clobbering root directory cookies No, sadly not. You can set

Re: [OAUTH-WG] Web apps BCP feedback

? I do not think CSRF defense will defeat an >> adversarial subdomains ability to over-write a cookie and circumvent >> double-cookie-submit. >> >>> On 9/25/21 8:10 AM, Neil Madden wrote: >>> Technically yes, CSRF refers to cross-site attacks. However, there i

Re: [OAUTH-WG] Web apps BCP feedback

Technically yes, CSRF refers to cross-site attacks. However, there is a class of attacks that are cross-*origin* but not cross-site and which are otherwise identical to CSRF. SameSite doesn’t protect against these attacks but other traditional CSRF defences *do*. For example, synchronizer tokens

Re: [OAUTH-WG] DPoP key rotation

On 11 Jun 2021, at 21:20, Brian Campbell wrote: > > Hi Dmitry, > > This ML is indeed the appropriate place for this kind of thing. You raise a > legitimate question, however, the general rough consensus thinking has been > that allowing for DPoP key rotation for refresh tokens and public cli

Re: [OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00

I have also read it and it looks good to me. It might be worth explicitly discussing how it relates to the older draft [1] (that we implemented at the time). That older draft also included a client_id parameter in the response, so it would be good to clarify if that is actually needed to prevent

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: Implementation Status

ForgeRock plan to implement PAR. — Neil > On 24 Mar 2021, at 19:53, Hannes Tschofenig wrote: > > Hi all, > > I am working on the shepherd writeup and I need information about the > implementation status of this specification. > > Can you share whether you are implementing, or planning to

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Makes sense, thanks. > On 18 Mar 2021, at 22:55, Brian Campbell wrote: > >  > Thanks Neil. I'll look at incorporating that guidance. Although I think > referencing might be more appropriate than incorporating directly. > >> On Mon, Mar 15, 2021 at 3:44 AM Nei

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

> On 18 Mar 2021, at 11:33, Rifaat Shekh-Yusef wrote: > > On Thu, Mar 18, 2021 at 3:45 AM Neil Madden <mailto:neil.mad...@forgerock.com>> wrote: > > >> On 18 Mar 2021, at 05:33, Andrii Deinega > <mailto:andrii.dein...@gmail.com>> wrote: >>

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

> On 18 Mar 2021, at 05:33, Andrii Deinega wrote: > >  > The Cache-Control header, even with its strongest directive "no-store", is > pretty naive protection... Below is an excerpt from RFC 7234 (Hypertext > Transfer Protocol: Caching). > >> This directive is NOT a reliable or sufficient me

Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]

ace, is apparently the only one able to > “redeem” the auth code returned to the redirect_uri. > > > Von: OAuth Im Auftrag von Om > Gesendet: Mittwoch, 17. März 2021 06:17 > An: Neil Madden > Cc: Vittorio Bertocci ; oauth > ; Warren Parad > Betreff: Re: [OAUTH-WG]

Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]

this under best practices. > >>> On Mon, Mar 15, 2021 at 3:31 PM Neil Madden >>> wrote: >> I want to come back to this topic as a new thread. >> >> As I understand things, the difference on Android is that any app can claim >> to be a generic web brow

[OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]

onation". If you have an app that you want to > ensure is "your" app then the most secure way is to look at "app > attestation". This is however, way off topic for this thread :) > > On 2/14/21 9:28 AM, Neil Madden wrote: >> Public clients are implicit

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

heers, Neil [1]: https://w3c.github.io/webappsec-post-spectre-webdev/#dynamic-subresources <https://w3c.github.io/webappsec-post-spectre-webdev/#dynamic-subresources> > On 20 Feb 2021, at 09:07, Neil Madden wrote: > > I was mentioning it primarily as another example of the

Re: [OAUTH-WG] OAuth mTLS and JWK use/key_ops

> On 8 Mar 2021, at 12:50, Neil Madden wrote: > > An interesting question was raised by our developers around the > interpretation of JWK “use” and “key_ops” constraints when publishing a > self-signed certificate for mTLS client authentication. In X.509 the KeyUsa

[OAUTH-WG] OAuth mTLS and JWK use/key_ops

An interesting question was raised by our developers around the interpretation of JWK “use” and “key_ops” constraints when publishing a self-signed certificate for mTLS client authentication. In X.509 the KeyUsage extension distinguishes between keys intended for use for verifying general signat

Re: [OAUTH-WG] One-time token login

One option is JWT Bearer grant with “jti” and replay prevention (https://tools.ietf.org/html/rfc7523#page-7 ) if your AS supports it. This is nice if some other component is generating the emails as it needs no coordination with the AS. — Neil > On 2 Mar 2021, at 19:04, Evert Pot wrote: > >

Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

On 24 Feb 2021, at 11:39, Bron Gondwana wrote: > >> >> […] > > Let's get down to use cases then, rather than talking in abstracts. > > I'm an end user with a copy of {The Bat email client} and I want to connect > it to {Gmail} + {Yahoo} + {My ISP}. It supports {POP3}, a widely popular > ope

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

context of the bff-token endpoint, that significantly reduces the ways > a cross-site request could be initiated and those ways (pop-up or full page > redirection) further limits the likelihood of the malicious party being able > to read response data. > >> On Thu, Feb 1

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

> On 18 Feb 2021, at 12:25, Philippe De Ryck > wrote: > >> On 18 Feb 2021, at 13:08, Neil Madden wrote: >> >> Thanks for following up, Brian. Responses below. >> >>> On 17 Feb 2021, at 22:48, Brian Campbell wrote: >>> >>> Alway

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

e browser vendors do eliminate 3rd-party cookies then 1, 3, and 4 become largely unnecessary (although 3 might still be a risk due to sub-domain hijacking, and 1 will always be good practice). — Neil > > That got a little rambly, sorry. But hopefully it makes some sense. > > On

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Do you eliminate the cookies too? > On 17 Feb 2021, at 19:50, Dominick Baier wrote: > >  > Well. Maybe it is at least worth while then to at least mention that you > could also take a slightly different approach and eliminate all tokens in the > browser - with the respective trade offs. > >

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

origin. People are online all the time now, so this is at best a mild inconvenience. — Neil > On 15 Feb 2021, at 11:09, Philippe De Ryck > wrote: > >  >> >>> On 15 Feb 2021, at 11:50, Neil Madden wrote: >>> >>>> On 15 Feb 2021, at 10:26,

  1   2   3   >