Please message me 09454503062
On Wed, Jul 2, 2025, 7:21 PM <[email protected]> wrote: > Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > Today's Topics: > > 1. Re: [OAUTH-WG/IETF-123] Introduction and socialization of Personal > Draft - OAuth 2.0 step-up authorization challenge protocol > (Yaron ZEHAVI) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 2 Jul 2025 11:21:07 +0000 > From: Yaron ZEHAVI <[email protected]> > Subject: [OAUTH-WG] Re: [OAUTH-WG/IETF-123] Introduction and > socialization of Personal Draft - OAuth 2.0 step-up authorization > challenge protocol > To: Nick Watson <[email protected]>, "Lombardo, Jeff" > <[email protected]> > Cc: "Lombardo, Jeff" <[email protected]>, > "[email protected]" <[email protected]>, Alex Babeanu > <[email protected]>, "[email protected]" > <[email protected]>, Grese HYSENI > <[email protected]>, Henrik KROLL > <[email protected]> > Message-ID: <[email protected] > prd04.prod.outlook.com> > Content-Type: multipart/alternative; boundary="_000_HE1PR04MB325748 > E4D371ADF42FB3BAE69340AHE1PR04MB3257eurp_" > > Thanks Nick, > I created an issue with my initial feedback and questions to your draft: > https://github.com/njwatson32/oauth-error/issues/2 > > Let’s keep the discussion and collaborate as both our drafts touch quite > similar challenges. > I like the proposal to add to our draft errors in response to refused > refresh token request. But my first thought would be existing > error=invalid_grant fits in this case, and client can place a new request, > during its processing the policies will be evaluated and errors would be > shown to end-user, preserving their privacy. > Why do you think new responses are required in this case? > > Regards, > Yaron ZEHAVI > > > > > Classification: GENERAL > From: Nick Watson <[email protected]> > Sent: Wednesday, July 2, 2025 1:55 AM > To: Lombardo, Jeff <[email protected]> > Cc: Lombardo, Jeff <[email protected]>; [email protected]; > Alex Babeanu <[email protected]>; Yaron ZEHAVI < > [email protected]>; [email protected] > Subject: Re: [OAUTH-WG] [OAUTH-WG/IETF-123] Introduction and socialization > of Personal Draft - OAuth 2.0 step-up authorization challenge protocol > > You don't often get email from [email protected]<mailto: > [email protected]>. Learn why this is important< > https://aka.ms/LearnAboutSenderIdentification> > This message is from an external sender - be cautious, particularly with > links and attachments. > > Yes it's hyperlinked above. It's https://github.com/njwatson32/oauth-error > . > > On Tue, Jul 1, 2025 at 3:48 PM Lombardo, Jeff <[email protected]<mailto: > [email protected]>> wrote: > Do you have a git repo too? > > > 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<tel:(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$ > >. > > From: Nick Watson <[email protected]<mailto:[email protected]>> > Sent: July 1, 2025 6:28 PM > To: Lombardo, Jeff <[email protected]<mailto:[email protected]>> > Cc: Lombardo, Jeff <[email protected]<mailto: > [email protected]>>; [email protected]<mailto:[email protected]>; > Alex Babeanu <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]> > Subject: RE: [EXT] [OAUTH-WG] [OAUTH-WG/IETF-123] Introduction and > socialization of Personal Draft - OAuth 2.0 step-up authorization challenge > protocol > > > 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. > > I uploaded my early draft to datatracker – > https://datatracker.ietf.org/doc/draft-watson-oauth-rich-error-response/ > (github<https://github.com/njwatson32/oauth-error>) – so people can take > a look if they want. > > On Mon, Jun 30, 2025 at 12:30 PM Lombardo, Jeff <[email protected] > <mailto:[email protected]>> wrote: > Hi Nick, > > Happy to contribute and take a look into your work to build a stronger > case to present to this WG. > > Will you be in Madrid per chance? > > 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<tel:(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$ > >. > > From: Nick Watson <[email protected]<mailto:[email protected]>> > Sent: June 30, 2025 1:45 PM > To: Lombardo, Jeff <[email protected]<mailto: > [email protected]>> > Cc: [email protected]<mailto:[email protected]>; Alex Babeanu < > [email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; Lombardo, > Jeff <[email protected]<mailto:[email protected]>> > Subject: RE: [EXT] [OAUTH-WG] [OAUTH-WG/IETF-123] Introduction and > socialization of Personal Draft - OAuth 2.0 step-up authorization challenge > protocol > > > 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, > > 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= > [email protected]<mailto:[email protected]>> 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<tel:(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 -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to [email protected]<mailto: > [email protected]> > This message and any attachment ("the Message") are confidential. If you > have received the Message in error, please notify the sender immediately > and delete the Message from your system, any use of the Message is > forbidden. Correspondence via e-mail is primarily for information purposes. > RBI neither makes nor accepts legally binding statements via e-mail unless > explicitly agreed otherwise. Information pursuant to § 14 Austrian > Companies Code: Raiffeisen Bank International AG; Registered Office: Am > Stadtpark 9 > <https://www.google.com/maps/search/Am+Stadtpark+9?entry=gmail&source=g>, > 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial > Court of Vienna (Handelsgericht Wien). > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 39780 bytes > Desc: not available > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > ------------------------------ > > End of OAuth Digest, Vol 201, Issue 5 > ************************************* >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
