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]>
Sent: September 25, 2026 11:41 AM
To: [email protected]; Lombardo, Jeff <[email protected]>;
[email protected]
Cc: [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]
