This is a good discussion with multiple facets. It’s what WG discussions
should be.
In the JWT authorization grant case, I see our options as being to either
definitively fixing the problem or having the authorization grant be a special
case with different audience values than the cases we do fix. I can see this
going either way.
In the SAML case, yes, there isn’t an explicit typing option. I think that
leaves a choice between fixing the SAML audiences or deprecating the SAML
assertions draft entirely. Again, I could see this going either way.
In the JAR case, all the draft does is change “should be the issuer identifier”
to “MUST be solely the issuer identifier”. I think we should do this for
consistency with the other fixes and it won’t be a breaking change. But again,
the working group gets to decide.
And of course, I think we have consensus about what to do for private_key_jwt
JWTs.
As I see it, the fact we’re discussing legitimate choices for some of the cases
shouldn’t stop us from adopting the draft to get going on fixing the things
that there is consensus to fix right away.
Best wishes,
-- Mike
From: Brian Campbell <bcampb...@pingidentity.com>
Sent: Friday, February 7, 2025 12:15 PM
To: Michael Jones <michael_b_jo...@hotmail.com>
Cc: Filip Skokan <panva...@gmail.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] Re: draft-jones-oauth-rfc7523bis published and
questions to the working group
On Fri, Feb 7, 2025 at 7:37 PM Michael Jones
<michael_b_jo...@hotmail.com<mailto:michael_b_jo...@hotmail.com>> wrote:
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.
I was party to that conversation and what was described in telling us how the
authorization grant is vulnerable was sufficiently contrived to the point of
being vanishingly unrealistic (involving a 'local' AS doing token exchange with
the client using different 'remote' AS's including one that is malicious).
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.
Filip's suggestion was for JWT client auth FWIW and explicitly typing the
tokens provides some visibility and controls into the interop problems but does
not make them go away.
It also can't really be applied to SAML because there's no equivalent construct
in a SAML assertion to the typ header in JWS/JWT.
And it doesn't work for request objects because RFC 9101 already has a media
type defined.
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
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>
Sent: Friday, February 7, 2025 10:24 AM
To: Filip Skokan <panva...@gmail.com<mailto:panva...@gmail.com>>
Cc: Michael Jones
<michael_b_jo...@hotmail.com<mailto:michael_b_jo...@hotmail.com>>;
oauth@ietf.org<mailto:oauth@ietf.org>
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
<panva...@gmail.com<mailto:panva...@gmail.com>> 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
<michael_b_jo...@hotmail.com<mailto:michael_b_jo...@hotmail.com>> 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 -- oauth@ietf.org<mailto:oauth@ietf.org>
To unsubscribe send an email to
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org>
To unsubscribe send an email to
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
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
To unsubscribe send an email to oauth-le...@ietf.org
