Jeff, Thank you. I agree that this should compose with AIMS rather than fragment it.
The part I still cannot map is the one-time effect transition. Suppose the AS authorizes a $50 refund for order 123. The client sends the same valid, RAR-described, DPoP-bound request twice after losing the first response. Both requests remain within scope, posture is healthy, and no revocation signal has fired. Which AIMS or SSF artifact lets the RS distinguish a retry from a second authorized effect, and which durable state is consumed? If the authorization-lifecycle profile is meant to carry that transition, that sounds like the right place to map EMILIA’s crossing record rather than create a parallel stack. Could you point me to the current draft or repository? Appreciate your time ! Best, Iman On Fri, 25 Sep 2026 16:29:19 +0000, "Lombardo, Jeff" <[email protected]> wrote: And if you need more, there is a profile for SSF being worked on a new set of signals that would allow parties (AS, and RS at least) to communicate on Authorization request lifecycle events. This is working from the inside and not from the outside which will reinforce the framework instead of fragmenting it. Jean-François “Jeff” Lombardo | Amazon Web Services Principal Standards Specialist, Identity Services Montréal, Canada From: Lombardo, Jeff <[email protected]> Sent: September 25, 2026 12:10 PM To: Iman Schrock <[email protected]>; [email protected] Cc: [email protected]; Pieter Kasselman <[email protected]>; [email protected]; Lombardo, Jeff <[email protected]> Subject: RE: [EXT] [OAUTH-WG] Beyond the DPoP / HTTPSig choice: login and session as one problem And that is why the RAR Remediation and Mission references I provided were not mere content stuffing. * WIMSE says this client has an attested Identity bound to a cryptographic element * SSF will notify you in realtime of any changes if happening using CAEP, RISC, WISE, and maybe IITP profiles * Client to authenticate to AS using WIMSE issued credential and WPT for proof of possession as part of an OAuth grant type * RAR can describe has much as the “contract contains” * RAR metadata allows to build the RAR structure that the AS can understand, the semantics * Maybe some of those elements required came from a previous attempt at the RS that failed but for which the RS provided a RAR remediation (what to ask to the AS) * The AS will do its own assessment of the legitimacy of the OAuth grant request * Authenticate the Client through the WIMSE issued credential and PoP (WPT) * Evaluate the RAR details and scope of the request * Using OAuth Missions (does this action fits in the original intent) * Using AuthZEN to apply control policy: is this request valid, does it not too broad, is client not blocked cause we received a SSF signal saying so * Authenticate the user if applicable – OIDC * Bound the token to a DPoP key provided * Enrich the token with the right information * The client then make the request to the RS using the Bearer Token and the DPoP proof * The RS * Authenticate the Client through DPoP proof * Validate the JWT * Evaluate the RAR details and scope against the request * Using AuthZEN to apply control policy: is this request valid, does it not too broad, is client not blocked cause we received a SSF signal saying so Et voilà no need for a ledger. Just follow AIMS. Jean-François “Jeff” Lombardo | Amazon Web Services Principal Standards Specialist, Identity Services Montréal, Canada From: Iman Schrock <[email protected]<mailto:[email protected]>> Sent: September 25, 2026 11:41 AM To: [email protected]<mailto: [email protected]>; Lombardo, Jeff <[email protected]<mailto: [email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: RE: [EXT] [OAUTH-WG] Beyond the DPoP / HTTPSig choice: login and session as one problem 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, Thi, Neil, all, Jeff, this composition map helps. AIMS can assemble posture, workload credentials, proof of possession, step-up, and AuthZEN. The remaining question I see is narrower: does the authority cover this exact consequential action, and was that authority consumed once at the effect boundary? A healthy, correctly authenticated workload might hold authority for a $50 refund and attempt $500. Posture and client binding can both succeed while the action still needs to fail. That suggests a profile point, not a parallel stack: a Gate can accept AIMS, WIMSE, and OAuth evidence upstream, recompute the frozen action at admission, and produce evidence of that decision. Would you place that in AIMS composition guidance, an AuthZEN interop profile, or separate evidence work? Best, Iman
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
