We agree on starting with a single document and on producing something that
addresses the issues in a timely and responsible manner.
We disagree that the current document is correctly scoped to do so.
As background, when asked, the Stuttgart security researchers who identified
the vulnerability also told us that the authorization grant is vulnerable to
the same attacks. That’s why the draft also fixes the audience for these
tokens.
We should fix all the vulnerabilities in a consistent manner, rather than
picking and choosing which to fix and having to come back and fix more later.
I'll also note that any potential interop problems are mitigated Filip Skokan’s
suggestion to explicitly type the tokens, which the draft does. Your code can
know that you're using rfc7523bis tokens when they're explicitly typed and
you'll know that you aren't when they aren't. Code can continue to allow the
old behaviors when explicit types aren't present, if the context is such that
the security risks are acceptable.
I view the current draft as a practical means to close all the identified
vulnerabilities in a timely manner with minimum disruption to deployments.
-- Mike
From: Brian Campbell <[email protected]>
Sent: Friday, February 7, 2025 10:24 AM
To: Filip Skokan <[email protected]>
Cc: Michael Jones <[email protected]>; [email protected]
Subject: Re: [OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and
questions to the working group
Thanks for the work on this document Mike. Regarding the questions for the
working group:
1. My preference is for a single document.
2. The scope of the changes should be constrained to only what is necessary
to address the issue that brought us here, which is JWT Client Assertion
Authentication. Updates beyond that scope will needlessly introduce confusion
and interoperability problems as well as maintenance and support burden and/or
unnecessarily hinder progress of the work.
3. I would like to see the WG produces something that address the issue in a
timely and responsible manner. The current draft is not well positioned to do
either.
On Fri, Jan 31, 2025 at 8:57 AM Filip Skokan
<[email protected]<mailto:[email protected]>> wrote:
Hello Mike,
thank you for a quick turnaround on these
As far as questions 1-3 go:
1. I believe a precise incision in the form of a single "bis" document is
fine but if these were individual documents it wouldn't hurt, whatever we can
get out the door faster.
2. We have not done the homework of understanding the impact of changing
anything but client authentication JWTs.
* Ad JAR) There's no conflicting definition that would mention anything
but using RFC8414 issuer in RFC9101 and so I am in favour of leaving it be in
its current pre-bis state as the only change would be forbidding the array
style of audience. It is unnecessary. In the client auth case we have
conflicting definitions with MAY and SHOULD about the token endpoint being
used; We don't have that in JAR.
* Ad authorization grant JWTs) Aaron pointed out in prior discussions
that these would better remain unchanged [^1], is that still the case?
* Ad SAML) I cannot imagine any changes being done here but will admit
that I would leave this with others who better understand how SAML assertions
are used today.
* Bottom line I hope we can deal with just the issue at hand and avoid
changes to unaffected assertions.
1. Doesn't it sort of hinge on what we believe the right answer to 1) is?
[^1]: Question for Aaron, if authorization grant JWTs remained as is wrt. to
the audience claim, what about the added "typ"?
S pozdravem,
Filip Skokan
On Thu, 30 Jan 2025 at 20:03, Michael Jones
<[email protected]<mailto:[email protected]>> wrote:
I’ve published
draft-jones-oauth-rfc7523bis<https://www.ietf.org/archive/id/draft-jones-oauth-rfc7523bis-00.html>,
which proposes replacing RFC 7523<https://www.rfc-editor.org/rfc/rfc7523> (JWT
Assertions) and proposes corresponding updates to RFC
7521<https://www.rfc-editor.org/rfc/rfc7521> (Assertions Framework), RFC
7522<https://www.rfc-editor.org/rfc/rfc7522> (SAML Assertions), RFC
9101<https://www.rfc-editor.org/rfc/rfc9101> (JAR), and RFC
9126<https://www.rfc-editor.org/rfc/rfc9126> (PAR), as discussed during
Monday’s interim. See the deck that Joseph Heenan and I
presented<https://datatracker.ietf.org/meeting/interim-2025-oauth-04/materials/slides-interim-2025-oauth-04-sessa-private-key-jwt-aud-issues-00.pdf>.
Note that corresponding updates have also been published to OpenID Connect
Core, OpenID FAPI 1, OpenID FAPI 2, and OpenID CIBA Core.
The discussion on Monday resulted in these questions for the working group:
1. The draft proposes to update affected specs other than RFC 7523, rather
than replacing them. This was done to make the changes easier to review. See
the four sets of updates beginning at Section
9<https://www.ietf.org/archive/id/draft-jones-oauth-rfc7523bis-00.html#name-updates-to-rfc-7521>.
Do we want to update the affected specs from this single “bis” document or
create individual “bis” documents for each of them?
2. The draft proposes to uniformly update the audience values in security
tokens sent to the authorization server to the AS’s issuer identifier. This
includes client authentication JWTs, authorization grant JWTs, and Request
Object JWTs. This is a change in some cases and a narrowing to a single
already-acceptable specified audience choice in others. Do we want to
uniformly use the issuer identifier for token audiences, or have a different
special case audience value of the token endpoint URL for authorization grant
JWTs?
3. Are people in favor of adopting the draft as-is and then making any
changes wanted by the working group to the adopted spec or are there specific
changes people believe we should make before adoption? As a reminder (quoting
from an IETF call for adoption), “Adoption does not mean a document is
finished, only that it is an acceptable starting point.”
Thanks to all who put in substantial work over the last few months to get us to
this point!
-- Mike
_______________________________________________
OAuth mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
OAuth mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
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 -- [email protected]
To unsubscribe send an email to [email protected]
