Hi Jeff, Thanks for the draft. It looks to be a useful extension. I've also been thinking about this problem as failure modes have become significantly more complicated in the last several years due to evolving privacy/security landscapes, regulation, and now the proliferation of agents. I have an (as yet) unpublished draft of an augmented error protocol for both token endpoint and resource server. I'd be interested in collaborating with you all on this spec as well, to see whether it could fully subsume the functionality from my WIP draft.
I had a couple of thoughts: 1. In Section 5, the spec puts out of scope how the client should respond to a step-up authorization challenge. While I think it's good to leave the door open for RS and AS to define custom options, it seems like it might be useful for the spec to have some normative language for the out-of-the-box options, e.g. RAR, rather than leaving it to clients to infer the expected behavior from the examples. 2. It may be the case that during refresh token exchange, the token endpoint already knows some things will fail. Can we allow the token endpoint to return insufficient_authorization with details too? Nick On Mon, Jun 30, 2025 at 7:41 AM Lombardo, Jeff <jeffsec= 40amazon....@dmarc.ietf.org> wrote: > 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 <(514)%20778-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 to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
