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]<mailto:[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]<mailto:[email protected]>> Sent: September 25, 2026 12:10
PM To: Iman Schrock <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]> Cc:
[email protected]<mailto:[email protected]>; Pieter Kasselman
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Lombardo, Jeff
<[email protected]<mailto:[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]><mailto:[email protected]<mailto:[email protected]>>>
Sent: September 25, 2026 11:41 AM To:
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>;
Lombardo, Jeff
<[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>;
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[email protected]><mailto:[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]
