OAuth Virtual Interim Meeting - 21.09.2026

Welcome

Rifaats starts the meeting and goes through his slide deck.

OAuth Protected Authorization

https://datatracker.ietf.org/doc/draft-hardt-oauth-protected-authorization/

Dick starts his presentation. First idea, move the authorization code to
a HTTP header field.

Additionally, the browser is allowed to set a new field: origin

Emelia: Question about the origin processing related to the question #4
in the open question slide.

Dick: Does the origin check against the redirect URI make sense? This is
the question I was wondering.

Emelia is asking this question as well. Currently, we use exact matching
for the redirect URI. Would you add parsing to the redirect URI?

Dick: You raise good points: Does it make sense? Does it add value? Does
it break certain use cases?

Is the origin and a redirect not a match? Currently we do not know what
is widely deployed.

Emelia: It would be good to get this question answered. Add the open
issues on the issue tracker.

Krooj: The header size issue is a concern.

Dick: Changing things that have been there for a decade triggers some
challenges.

Krooj: This is an issue for us.

Dick: This is an extra security feature and not a mandatory security. If
it cannot be deployed due to size issues, then you do not do it.

Filip: The browser adds the origin. The server is responsible for the
origin to match. If the browser does not support it, the origin is not
going to be there. The client is doing the 303 with the header. If the
browser does not support the protocol, it does not add the origin
header. How would this work for public clients who do not use a 303? Why
are we talking about it? For confidential clients we do not have an
issue.

Dick: There is still a big issue with logging credential. If a public
client is running on a server this is also an issue.

Emelia: There is also the FedCM work. See also idp-initiated:
https://github.com/fedidcg/idp-initiated

Dick: This is a separate solution to a related problem.

Hannes asked about the status of the FedCM work.

Emelia: The FedCM working group is still doing work and it makes good
progress for decentralized group. Chrome has implemented the
functionality but others have not implemented it. Other browsers are not
willing to implement the full FedCM spec. For this reason there is work
on

Max: Why is this not a generic change to HTTP?

Dick: I presented this to HTTP and they are not interested in this
issue. This is an OAuth issue.

Max: Aren't there others who pass credentials around in redirects?

Dick: I cannot force the group to care about this work.

Emelia points to text related to logging that might not be followed in
practice:
https://www.ietf.org/archive/id/draft-hardt-oauth-protected-authorization-00.html#section-10.5

You need to get a way so that libraries do not log this header.

Hannes asking for the encryption of the header.

Dick: This requires a bigger lift for the client.

Aaron posts: "it would be useful to go through the browser apps BCP
which lists out a bunch of attacker models and see whether this actually
solves those"

Dick: Sure.

Emelia: We already have PKCE mandatory for all clients and we also have
DPoP. What is the added security?

Dick: The discussion on the list was to switch to form-post. This
motivated me to look at the alternatives. I have to look at the list of
what attacks are addressed.

Emelia: I think I am asking for an explanatory document that goes
through the threats and compares it with the solution.

Max posted the link to the presentation that talks about why PKCE did
not help:
https://datatracker.ietf.org/meeting/124/materials/slides-124-oauth-sessa-browser-swapping-01

Here are the notes from HTTP presentation: notes from the HTTP meeting
where this was previously presented:
https://datatracker.ietf.org/meeting/125/materials/minutes-125-httpbis-00

Emelia: I cannot say whether I support.

Dick: The persons who raised the attack through that the solution
addresses the attack but they are not on the call today.

Dick: The feedback from Chrome was that this work could be useful.

Q: Does the group agree that there is a problem to be solved?

Yes: 3, No: 5, No opinion: 1

Krooj: I voted no because I want to see an attack surface presented.

Justin: Same here.

Some discussions about what the problem actually is.

Details of the attack from Jonas -
https://blog.syss.com/posts/browser_swapping/

Emelia discussing the slides about the browser-swapping attack from IETF
124. There are several attacks in the presentation. Getting clarity
about the attacks from that presentation is important

Filip discusses the attack scenario as well and focuses on the
assumptions for the attack to work.

Aaron in the chat: the attack relies on the attacker convincing the user
to copy and paste the authorization code in the url to the attacker
manually

Dick: I came here to present a solution to a problem that was already
presented.

Deb: Restarting the problem is the first part of the solution. It has to
be documented in the draft.

Maybe get Jonas to help formulate the problem. If you state the problem
it will be easier for the group to agree.

Dick: If the authorization code gets stolen then there is problem. I was
focusing on how to get the bad guy from stealing the authorization code.