Hi Alex,
Thanks for the reading, and yes we are not discussing here feedback over WG
feedback but more new feedback so that I might rework the proposal in a more
intelligent way.
The principle of the draft is that the RS is the first real stage for
enforcement of if a resource has to be disclosed or not, and for that it needs
information about the context of the issuance of the tokens by the AS.
* The RS trusts the AS and has a way to validate what's coming in - Token
validation as part of RFC6749 - The OAuth 2.0 Authorization Framework and all
the BCP that comes with it
* Still:
* The RS might need some higher assurance in the subject (if involved)
authentication - That's what RFC 9470 - OAuth 2.0 Step Up Authentication
Challenge Protocol expects to signal back when it is not on par with the RS
expectation. For that it needs dedicated claims. This is not a questioning of
the validity AS.
* The RS might need fine grained claims about the transaction - That's
what RFC9396 - OAuth 2.0 Rich Authorization Requests can provide but there is
no way to:
* Signal from the client to the RS how those Authorization Details
have been acquired: PAR, RAR, JAR?
* Signal from the RS to the Client a preferred way of acquisition and
which authorization details to acquire
* This is not a questioning of the validity of AS, it is negotiating
through the client between the AS and RS to reach a positive outcome if all
expectations are met.
* The RS, being under specific regulations like FAPI or FHIR, might need
some higher assurance in the client authentication but there is no way to:
* Signal from the client to the RS how the client authentication was
performed and which OAuth2 extensions have been used
* Signal from the RS to the Client preferred authentication method
(like for the user)
https://datatracker.ietf.org/doc/draft-lombardo-oauth-client-extension-claims/
is the proposal for the signaling from the client to the RS.
https://datatracker.ietf.org/doc/draft-lombardo-oauth-step-up-authz-challenge-proto/
was the proposal for the signaling from the RS to the client.
* note that Yoran came with a more recent proposal on this aspect with
https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/ focusing more
on RAR aspect
Jeff
Jean-François "Jeff" Lombardo | Amazon Web Services
Architecte Principal de Solutions, Spécialiste de Sécurité
Principal Solution Architect, Security Specialist
Montréal, Canada
Commentaires à propos de notre échange? Exprimez-vous
ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.
Thoughts on our interaction? Provide feedback
here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.
From: [email protected] <[email protected]>
Sent: February 3, 2026 5:28 AM
To: [email protected]; [email protected]
Cc: Lombardo, Jeff <[email protected]>
Subject: [EXT] draft-lombardo-oauth-client-extension-claims Re: [OAUTH-WG] RAR
examples not using "typ" oauth-wg/draft-ietf-oauth-rfc7523bis
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
AVERTISSEMENT: Ce courrier électronique provient d'un expéditeur externe. Ne
cliquez sur aucun lien et n'ouvrez aucune pièce jointe si vous ne pouvez pas
confirmer l'identité de l'expéditeur et si vous n'êtes pas certain que le
contenu ne présente aucun risque.
Hi Jeff,
I am torn about your draft:
https://identitymonk.github.io/draft-lombardo-oauth-client-extension-claims/draft-lombardo-oauth-client-extension-claims.html
Providing that information to the RS allows the RS to validate the decisions
the AS made before granting the access token. That is good and bad. Bad because
the RS is questioning the AS and can reject a valid access token if it does not
agree with new claims. I want that the RS trusts the AS and I want that the
client can rely on that a valid access token is accepted. Good because RSses
that are somewhat loosely coupled with the AS can keep track of what lead to
the access token being created.
I assume it was not the intention of the draft that RSes can reject valid
access tokens, but I fear that is going to happen. What would be error? Maybe
"HTTP 500 Internal Error" if we see the RS and AS as one system which do not
agree on something?
Maybe the new claims should be part of the token introspection endpoint
response?
That would allow the RS to get to the information, but we do not have to ship
it in every access token.
The RS could still reject an access token but maybe they are more reluctant to
do an extra request to the token introspection endpoint which increases the
latency of the API response. Maybe the RS would do this auditing only from time
to time like every 1/10000 request and then send a security event token to the
AS...
Sorry, I did not provide feedback to the feedback the WG gave.
Regarding what subcomponents know, should know and might reject, ...
It's complicated. "My" RS send requests to several subcomponents that are
sometimes in different jurisdictions and operate on a different legal basis. In
general, I want to clarify before we go live what clients are accepted by
business, the legal basis for using the API, privacy - GDPR and local laws -,
etc and I do not want the RS or its subcomponents to question the AS after we
are in production.
have fun
Axel
DMs welcome
From: Lombardo, Jeff
<[email protected]<mailto:[email protected]>>
Date: Monday, 2. February 2026 at 15:17
To: Nennker, Axel <[email protected]<mailto:[email protected]>>,
reply+aanemb3vnwtdtwwiasng5ndj6pcapevbnhhof6d...@reply.github.com<mailto:reply+aanemb3vnwtdtwwiasng5ndj6pcapevbnhhof6d...@reply.github.com>
<reply+aanemb3vnwtdtwwiasng5ndj6pcapevbnhhof6d...@reply.github.com<mailto:reply+aanemb3vnwtdtwwiasng5ndj6pcapevbnhhof6d...@reply.github.com>>,
[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Cc: Lombardo, Jeff <[email protected]<mailto:[email protected]>>
Subject: RE: [OAUTH-WG] RAR examples not using "typ"
oauth-wg/draft-ietf-oauth-rfc7523bis
Hi Alex,
Glad to see you here!
commenting on the second part, signaling the grant type and extensions used as
part of a token issuance, I initially proposed this as a personal Draft to
Madrid:
https://github.com/identitymonk/draft-lombardo-oauth-client-extension-claims
following a presentation Alex Babeanu and I made at OSW:
https://youtu.be/9683Ds9GldY
We had a debate as:
* The header might be available to all the sub-components exercising the
access control at a RS while the payload is
* Surcharging the jwt typ header value with a lot prefixes might lead to a
confused deputy situation depending on the order of the values, at least it
would require a draft to specify the order to make sure everyone got it right.
The feedback was:
* don't use claim that are already used by the market, this is not a Pro,
this is a Con to the proposal as it will have replying effects - This should be
an easy fix
* consider Vector of Trust as way to carry information
* I am still torn onto that VoT passes reference values that need to be
mapped on both sides not necessarily specification related values that have a
clear meaning
Happy to follow-up discussions in DM to resume the proposal if any interest.
Jeff
Jean-François "Jeff" Lombardo | Amazon Web Services
Architecte Principal de Solutions, Spécialiste de Sécurité
Principal Solution Architect, Security Specialist
Montréal, Canada
Commentaires à propos de notre échange? Exprimez-vous
ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.
Thoughts on our interaction? Provide feedback
here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.
From:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Sent: February 1, 2026 9:14 AM
To:
reply+aanemb3vnwtdtwwiasng5ndj6pcapevbnhhof6d...@reply.github.com<mailto:reply+aanemb3vnwtdtwwiasng5ndj6pcapevbnhhof6d...@reply.github.com>;
[email protected]<mailto:[email protected]>
Subject: [EXT] [OAUTH-WG] RAR examples not using "typ"
oauth-wg/draft-ietf-oauth-rfc7523bis
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
AVERTISSEMENT: Ce courrier électronique provient d'un expéditeur externe. Ne
cliquez sur aucun lien et n'ouvrez aucune pièce jointe si vous ne pouvez pas
confirmer l'identité de l'expéditeur et si vous n'êtes pas certain que le
contenu ne présente aucun risque.
Hi,
draft-ietf-oauth-rfc7523bis recommends strong typing of JWT but currently none
of the examples use "typ".
I think that
https://drafts.oauth.net/draft-ietf-oauth-rfc7523bis/draft-ietf-oauth-rfc7523bis.html#section-5
should update all examples in
"OAuth 2.0 Pushed Authorization Requests"
[RFC9126<https://drafts.oauth.net/draft-ietf-oauth-rfc7523bis/draft-ietf-oauth-rfc7523bis.html#RFC9126>]
E.g.:
eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrhTWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6sef5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-KdTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8WyeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJERWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6GQ
Uses
{
"kid": "k2bdc",
"alg": "RS256"
}
I think there should be the now recommended typ value.
Examples are only examples and not normative, but I think examples should
follow security recommendations.
Another topic, wouldn't it be better to have more types instead of one for
client authentication?
Something like rar_client_authn+jwt for rar, and ciba_client_authn+jwt for CIBA
and ... Doesn't hurt because servers and clients are recommended to adapt
current implementations anyway, right?
Kind regards
Axel
From: Michael B. Jones
<[email protected]<mailto:[email protected]>>
Date: Saturday, 31. January 2026 at 23:05
To: oauth-wg/draft-ietf-oauth-rfc7523bis
<[email protected]<mailto:[email protected]>>
Cc: Nennker, Axel <[email protected]<mailto:[email protected]>>,
Author <[email protected]<mailto:[email protected]>>
Subject: Re: [oauth-wg/draft-ietf-oauth-rfc7523bis] tradeoffs between using
issuer and specific endpoint urls (PR #24)
@selfissued commented on this pull request.
________________________________
In
draft-ietf-oauth-rfc7523bis.xml<https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/24#discussion_r2750097587>:
> + or its token endpoint URL. Using the specific token
> endpoint URL provides
+ stronger endpoint binding and is RECOMMENDED when the
endpoint URL is
+ configured from a trusted, out-of-band source. Using
the issuer identifier
+ allows greater flexibility at the cost of reduced
endpoint-specific binding.
As @PedramHD<https://github.com/PedramHD> wrote in his initial description of
the attack, "a malicious OP could specify token endpoints of other OPs, thus,
obtaining private key JWTs created by an RP that it could use at those OPs."
This is the core of what enables the attack: Attackers can specify that the
audience be the token endpoint of the legitimate site being attacked.
The use of endpoint URLs as audience values do not stop the attack. The use of
validated issuer URLs do.
-
Reply to this email directly, view it on
GitHub<https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/24#discussion_r2750097587>,
or
unsubscribe<https://github.com/notifications/unsubscribe-auth/AANEMB3OWYNI4YEH3RVCZHL4JURJPAVCNFSM6AAAAACRQSIOLGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTOMZTGY3TCNJRGQ>.
You are receiving this because you authored the thread.[Image removed by
sender.]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
