Dear Jeff, Thank you for taking the time. Your distinction helped us find a real gap in our adapter.
You're right: I blurred the AS grant and the RS decision to execute a refund. Sorry also for the broken quoting in my previous reply, I used the native Apple Mail. I tested the lost-response case in EMILIA’s Gate/Stripe adapter. With a fresh transaction identity, a second valid receipt could reach the mock provider for the same refund. Draft PR #791 binds a stable business-operation ID to the approved refund and provider key. Draft PR #795 adds a durable attempt record that blocks another provider call while the outcome remains uncertain. Given the scope boundary in AIMS §4, would this clarification be useful in §10.5? “Transaction-token validation does not establish whether a downstream operation took effect. Recovery from uncertain execution outcomes is an application responsibility outside the scope of this document.” That keeps recovery at the RS/provider boundary, without requiring a shared ledger with the AS. Sincerely, I. Schrock On Fri, Sep 25, 2026 at 11:57 AM Lombardo, Jeff <[email protected]> wrote: > Side note Iman: I don’t know which client you use for answering on the > list (maybe AI?) but you either drop the thread you answer to or reformat > it in a way that I wish good luck to anyone, if any, trying to follow our > exchange onwards > > I think you speak of two different things: > > > > - Requesting for a delegation of Authorization so that *client 123 > acting on behalf of Jeff for order 123 can perform a refund of 50$* > - this is for the AS to decide if this legit case to issue an > Access Token > - the fact it could be backed by a Mission oriented component as > well as a PDP (whatever AuthZEN or not, this is just a communication > mechanism) and like I said, the AS can: > - Authenticate the Client through the WIMSE issued credential > and PoP (WPT) > - Evaluate the RAR details and scope of the request > - Authenticate the user if applicable – OIDC > - Bound the token to a DPoP key provided > - Enrich the token with the right information if deciding to > issue > - Apply any SSF communication he received about change of a > party in the ecosystem > - If it up to the AS to keep track of request and flag client that > that try to abuse > - Using a delegation of Authorization by *client 123 to act on behalf > of Jeff on order 123 to perform a refund of 50$* > - this is for the RS to decide if the operation should be performed > or not > - the fact it could be backed by a PDP (whatever AuthZEN or not, > this is just a communication mechanism) and like I said, the RS can: > - Authenticate the Client through DPoP proof > - Validate the JWT > - Evaluate the RAR details and scope against the request > - Apply any SSF communication he received about change of a > party in the ecosystem > > > > If you aim to represent any RS resource state in a share ledger with the > AS and the client, good luck. For the Draft currently being written, it is > not mine nor it is public for as much I know of it. I provide pointers when > I would have those. > > > > *Jean-François “Jeff” Lombardo* | Amazon Web Services > > > Principal Standards Specialist, Identity Services > Montréal, Canada > > > > *From:* Iman Schrock <[email protected]> > *Sent:* September 25, 2026 12:59 PM > *To:* Lombardo, Jeff <[email protected]>; [email protected] > *Cc:* [email protected]; [email protected]; [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. > > > > 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 > > -- Iman Schrock Founder EMILIA Protocol emiliaprotocol.ai | [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
