Hi Jeff,
The resource server MAY return a challenge with the key
|resource_metadata_uri|. When this challenge is present, its value
MUST be set to the OAuth2 Protected Resource Metadata Endpoint URI for
the resource server as defined in [RFC9728
<https://www.rfc-editor.org/rfc/rfc9728>].
In this draft, you use |resource_metadata_uri |but |resource_metadata
|(as defined in RFC9728) could/should actually be used, isn't it?
RFC9728:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer*resource_metadata*=
"https://resource.example.com/.well-known/oauth-protected-resource";
This draft :
HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_authorization",
error_description="The authorization level is not met",
*resource_metadata_uri*="https://www.example.com/.well-known/oauth-protected-resource";,
body_instructions=true
The resource server MAY return a challenge with the key
|body_instructions| When this challenge is present, its value MUST be
set to |false| if no body is associated to the response from the
resource server, or |true| if a body is associated to the response
from the resource server.
Do we actually need this parameter? Can we just check the content-type
of the response?
Maybe it is needed. It feels somewhat awkward, though.
If a body is attached to the to the response from the resource server,
it MUST be formatted as an AuthZEN [D-OpenID-AuthZEN
<https://openid.github.io/authzen/>] response which MUST contain the
following keys:
How useful is that? Can the client actually use this to know which
authorization request it should make ? In other words, how does the
client translate Authzen into a OAuth authorization request? Wouldn't it
be more appropriate to include a payload which more directly translates
into OAuth authorization requests ?
If the main idea of this draft is to convey step up authentication data
as Authzen, maybe it should be called "OAuth 2.0 Authzen step-up
authorization challenge proto". It might be better to avoid hard-coding
the format, many deployments (i.e. decentralized ones) might find it
more useful to use another challenge format. Could be have content-type
negotiation here?
Doesn't it potentially leak information that the client should not have
access to? How can the resource server known which information can
safely forwarded to the client ? This is discussed in 8.3 but additional
guidance on that might be useful.
RFC9728 might be abused by a malicious resource server to obtain access
tokens intended for another access token (fishing discussed in 7.8). Can
this make it worse?
Regards,
Gabriel
Le 30/06/2025 à 16:37, Lombardo, Jeff a écrit :
Dear OAuth Working Group,
Alex, Yaron, George, and I would like to introduce a personal Draft to
you. We have been working on since the beginning of the year while we
were water testing our use cases and preliminary thoughts at OSW25.
/Personal Draft - OAuth 2.0 step-up authorization challenge protocol
/[https://datatracker.ietf.org/doc/draft-lombardo-oauth-step-up-authz-challenge-proto/]
would extend of *RFC 9470 - OAuth 2.0 Step Up Authentication Challenge
Protocol* by allowing a resource server to return detailed step-up
authorization challenges:
1/ Based on access control decisions enforced at the resource server –
whatever through a dedicated logic or a call to a Policy Decision
Point (PDP)
2/ Enabling clients to request new tokens through enhanced grant types
and extension like, but not limited to, RFC9396 - OAuth 2.0 Rich
Authorization Requests, RFC9126 - OAuth 2.0 Pushed Authorization
Requests, RFC8693 - OAuth 2.0 Token Exchange, or other grant type as
the client might see fit **
This Personal Draft also aims at supporting requirements for
[FAPI2.0-Security-Profiles] or [hl7.fhir.uv.smart-app-launch]
regulated APIs when they are supporting and recommending those
enhanced flows as ways to make access token least privilege, context
based, and finer grained.
We are also requesting, please, a 10 minutes time slot at IETF-123 /
Madrid to be able to present our work and gather comments, questions,
and support in the aim of working forward on this proposal as an IETF
Draft.
In the meantime, we remain available to answer any questions,
comments, suggestions.
Regards,
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
(+1 514 778 5565
/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$>/./
_______________________________________________
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
