[Openid-specs-risc] New draft: proposal: Extending SSF to workload identities security event (WISE Profile)

Tue Jul 28 16:27:43 UTC 2026

Thanks Sato-san for the reviews.

I agree on the comments and they are currently integrated in the staged -03 branch

Jean-François “Jeff” Lombardo | Amazon Web Services

Architecte Principal de Solutions, Stratégie de Sécurité
Principal Solution Architect, Security Strategy
Montréal, Canada

From: Tom Sato <tomsatomail at gmail.com>
Sent: July 22, 2026 2:38 PM
To: Lombardo, Jeff <jeffsec at amazon.com>; openid-specs-risc at lists.openid.net
Cc: Pieter Kasselman <pieter at defakto.security>; sean.odell at cvshealth.com; Dag Sneeggen <dag.sneeggen at signicat.com>; Atul Tulshibagwale <atul at sgnl.ai>
Subject: RE: [EXT] [Openid-specs-risc] New draft: proposal: Extending SSF to workload identities security event (WISE Profile)

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.

Dear Jeff, Pieter, Sean, Dag, and SSF Working Group,

Thanks for sharing WISE — I spent time with the draft and wanted to send some feedback, starting with why I think the timing and fit are right, then some specific comments.

I think this profile is exactly where AIMS pointed and hasn't yet been built out. AIMS already says participants MAY subscribe to CAEP/RISC-style signals for agent security state, and MUST act on revocation without delay — but CAEP is scoped to human sessions and RISC to user accounts, and neither actually defines event types for a workload identity. WISE is the first draft I've seen that specifies what that signaling layer should actually look like for workloads. Most of the other current activity at IETF — AIMS itself, the agentproto BoF this week, AGTP, DAWN — is about the point of authorization, delegation, transport, or discovery. Almost none of it addresses what happens asynchronously, after a workload is already deployed and something about its security state changes. That's the gap WISE fills, and it's a natural fit for SSF specifically because it's the same pattern CAEP and RISC already proved out, just extended to a subject type they don't currently cover.

Also worth calling out as a good instinct: reusing the VEX model (affected / not_affected / fixed / under_investigation) for workload-vulnerability-status-changed rather than inventing new vocabulary. That's the right way to extend an existing standard.

A few specific points from a close read:

1. Compromise Response coverage looks incomplete against the draft's own vocabulary. The Security Considerations section lists four event/reason combinations that should trigger immediate Receiver action: credential-compromise, credential-revoked (compromise/key_compromise), trust-anchor-changed (compromise), and workload-compromised. But workload-disabled and trust-domain-federation-revoked both also carry a reason: compromise value, and neither is in that list. Rather than maintaining an enumerated list that needs to stay in sync as the vocabulary grows, a general rule — "any event carrying a reason of compromise, regardless of event type, SHOULD trigger the same immediate Receiver action" — would be both more complete today and self-maintaining going forward.

2. txn correlation isn't called out where the draft's own design needs it most. workload-disabled / workload-enabled / workload-purged are explicitly designed to be split from their accompanying credential-revoked / credential-issued events ("a Transmitter SHOULD emit those credential events together with this event"). SSF's txn claim exists precisely so a Receiver can recognize two SETs share an underlying cause, but the draft never instructs Transmitters to set matching txn values across these paired events. Worth making that explicit — without it, a Receiver has no reliable way to associate the lifecycle event with its credential-effect counterpart.

3. previous_context / current_context in workload-baseline-changed are left fully implementation-defined, which works against interoperability — two Receivers could get structurally incompatible payloads for the same event type. It also interacts with the draft's own Confidentiality consideration about leaking workload infrastructure topology: since these fields are free-form, there's no guidance steering implementers away from putting sensitive topology detail (node names, network zones) into a field that may cross a trust-domain boundary. A minimal recommended key set, or at least explicit guidance on what not to include, would help on both fronts.

4. Minor consistency gap: workload-compromised's text says it "SHOULD trigger immediate isolation or credential revocation," but unlike workload-disabled, it doesn't explicitly instruct the Transmitter to emit an accompanying credential-revoked. Matching the pairing language already used for workload-disabled would be a small, easy fix.

Happy to go deeper on any of these if useful. Overall this is a well-scoped profile and I think it fills a real gap.

Best,
Tom Sato
tomsatomail at gmail.com<mailto:tomsatomail at gmail.com>
https://www.linkedin.com/in/tomsato/

On Sun, Jul 19, 2026 at 9:59 PM Lombardo, Jeff via Openid-specs-risc <openid-specs-risc at lists.openid.net<mailto:openid-specs-risc at lists.openid.net>> wrote:
Dear Working Group and Chairs,

I wanted to bring something to the WG's attention that I think fits naturally into the Shared Signals ecosystem.

SSF, CAEP, and RISC have nailed the human identity signal story. But we're now in a world where agents act on behalf of humans, on behalf of other agents, and increasingly on their own behalf. The workloads behind them have their own lifecycle events (credential rotation, trust revocation, posture changes) that need the same asynchronous signal framework.

This gap surfaced while writing draft-klrc-aiagent-auth-03<https://www.ietf.org/archive/id/draft-klrc-aiagent-auth-03.html>, and Sean articulated it well in his recent post: You Already Have the Pieces — Now Build It<https://www.theidentityunderground.com/post/you-already-have-the-pieces-now-build-it>.

Together with my co-authors Dag, Sean, and Pieter, we've been working on WISE (Workload Identity Security Events). It is a profile of SSF that defines SET event types for signaling security-relevant state changes in workload identities. TL;DR: think about CAEP/RISC, but for workloads operating in WIMSE environments.

GitHub: https://github.com/identitymonk/openid-wise
Pages: https://identitymonk.github.io/openid-wise/

We hope you'll find it interesting, and we welcome all comments and feedback.

Appreciated,

Jeff & co-authors

Jean-François “Jeff” Lombardo | Amazon Web Services

Architecte Principal de Solutions, Stratégie de Sécurité
Principal Solution Architect, Security Strategy
Montréal, Canada
Commentaires à propos de notre échange? Exprimez-vous ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.

_______________________________________________
Openid-specs-risc mailing list
Openid-specs-risc at lists.openid.net<mailto:Openid-specs-risc at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-risc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20260728/8129b9ff/attachment-0001.htm>