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]

Reply via email to