wiseset July 2026
Lombardo, et al. Standards Track [Page]
Workgroup:
OpenID Shared Signals
Published:
Authors:
J. Lombardo
Amazon Web Services
D. Sneeggen
Signicat
S. O'Dell
CVS Health
P. Kasselman
Defakto Security

OpenID WISE Profile Specification 1.0 - draft 02

Abstract

This document defines the Workload Identity Security Events (WISE) profile, a set of Security Event Token (SET) event types for signaling security-relevant state changes related to workload identities. WISE builds on the SET framework defined in [RFC8417] and the Shared Signals Framework [SSF] to enable trust domains and identity infrastructure components to communicate workload identity lifecycle events, credential and key management events, trust material changes, and posture evaluation events.

WISE complements the existing RISC and CAEP profiles by addressing the non-human identity domain, specifically workload-to-workload authentication and the workload identity lifecycle as described in the WIMSE architecture [WIMSE-ARCH].

▲

Table of Contents

1. Introduction

Modern distributed systems rely on workloads, software entities executing for a specific purpose, to deliver services. These workloads include microservices, containers, virtual machines, serverless functions, and increasingly, AI agents operating autonomously or on behalf of users.

The WIMSE architecture [WIMSE-ARCH] establishes the foundational model for workload identity: a trust domain, typically governed by a single authority, provisions cryptographic credentials to workloads that allow them to authenticate to one another. The credentials are short-lived by design, binding a workload identifier to key material through either Workload Identity Tokens (WIT) at the application layer or Workload Identity Certificates (WIC) at the transport layer, as defined in [WIMSE-CRED].

The emergence of AI agents as a new category of workload, as described in [AGENT-AUTH], introduces additional security coordination requirements. AI agents interact with tools, services, and other agents across trust domain boundaries, often autonomously. Like any workload, they require identifiers, credentials, and posture evaluation before credentials are issued. The security events defined in this specification apply equally to traditional service workloads and to AI agent workloads.

While the RISC [RISC] profile addresses risk signals for user accounts and the CAEP [CAEP] profile addresses continuous access evaluation for user sessions, no standardized event profile exists for communicating security-relevant state changes about workload identities. This specification fills that gap.

1.1. Scope

WISE defines event types that enable:

  • Trust domain authorities to signal credential and key lifecycle changes to federated peers and relying parties.

  • Identity infrastructure components to communicate posture evaluation and policy changes that affect workload trust.

  • Cross-domain signaling of trust material updates that require immediate action by relying parties.

  • Runtime posture change notifications that may affect the trust evaluation of a workload.

  • Supply-chain changes including updated or revoked provenance, and changes to the vulnerability status of a workload's components that require relying parties to re-evaluate trust.

1.2. Alignment with WIMSE Architecture

This specification aligns with the WIMSE architecture [WIMSE-ARCH], which defines a model where:

  • A trust domain is a logical grouping of systems that share a common set of security controls and policies, identified by a fully qualified domain name.

  • Workload identity credentials are issued under the authority of a trust domain, which maps to one or more trust anchors used to validate them.

  • Workload identifiers are URIs that uniquely name a workload within a trust domain, as defined in [WIMSE-ID].

Because a trust domain acts as the issuing authority for the workloads within it, WISE events are designed to signal state changes:

  1. From a trust domain authority to federated peers, when changes affect the ability of external parties to validate or trust workloads from that domain.

  2. From a trust domain authority to relying parties within the same domain, for credential and key lifecycle or posture changes that require action.

1.3. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Event Types

The base URI for WISE event types is:

https://schemas.openid.net/secevent/wise/event-type/

2.1. Common Optional Claims

Unless stated otherwise, any WISE event MAY include the common optional claims defined in Section 2 of [CAEP]. In particular:

  • reason_admin - OPTIONAL. A localizable administrative message intended for logging and auditing, as defined in [CAEP]. Its value is a JSON object containing one or more key/value pairs, where each key is a BCP 47 [RFC5646] language tag and each value is the locale-specific message.

  • reason_user - OPTIONAL. A localizable, user-facing message, as defined in [CAEP]. Its value follows the same JSON object structure as reason_admin.

  • initiating_entity - OPTIONAL. A JSON string describing what triggered the event, as defined in [CAEP]: one of admin, user, policy, or system.

When a WISE event includes reason_admin or reason_user, the claim MUST use the localizable JSON object structure defined above rather than a plain string. The following is a non-normative example:

"reason_admin": {
  "en": "Private key material detected in public repository",
  "de": "Privates Schluesselmaterial in oeffentlichem Repository entdeckt"
}

2.2. Workload Credential Lifecycle Events

These events signal changes to the credentials issued to workloads by the trust domain authority.

This specification defines event types that apply to workload credentials regardless of their security properties. Inclusion of a credential type in this specification does not constitute a recommendation for its use. Deployments SHOULD prefer credentials with proof-of-possession semantics as defined in [WIMSE-CRED]. Legacy credential types are included to enable security event signaling for environments operating heterogeneous credential ecosystems or transitioning toward WIMSE-compliant infrastructure.

Proof-of-possession credentials bind a key to the workload identity: a WIT carries the public key in its cnf claim, and the corresponding private key is used to produce Workload Proof Tokens (WPT) [WPT]. WISE does not define separate events for the lifecycle of such keys. Because a bound key has no value once its credential is revoked, a compromised or rotated key is signalled through the credential events in this section: revoke the affected credential (with reason set to key_compromise where applicable) and, where a replacement is issued, emit credential-rotated or credential-issued.

2.2.1. credential-issued

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/credential-issued

The credential-issued event signals that a new credential was issued to a workload by the trust domain authority.

Attributes:

  • credential_type - REQUIRED. The type of credential issued. Possible values:

    • wit - Workload Identity Token as defined in [WIMSE-CRED]

    • wic - Workload Identity Certificate as defined in [WIMSE-CRED]

    • x509_svid - X.509-SVID as defined in [SPIFFE]

    • x509_generic - Generic X.509 certificate not conforming to WIC or SVID profiles

    • oauth_private_key_jwt - OAuth 2.0 client authentication using private_key_jwt [RFC7523]

    • oauth_mtls - OAuth 2.0 mutual TLS client authentication [RFC8705]

    • oauth_client_secret - OAuth 2.0 client_id and client_secret credential pair

    • api_key - Static API key or long-lived bearer token

  • Additional values MAY be defined by profiling specifications or private agreement between Transmitter and Receiver.

  • credential_id - OPTIONAL. An identifier for the credential (e.g., certificate serial number, jti claim value).

  • expiry - OPTIONAL. The expiration time of the credential as a JSON number (NumericDate per [RFC7519]).

  • key_storage - OPTIONAL. Where the private key bound to the credential is stored. Possible values:

    • hardware - Key is stored in a hardware security module, TPM, secure enclave, or equivalent tamper-resistant storage.

    • software - Key is stored in software (filesystem, memory, or application-managed keystore).

  • key_storage_ecosystem - OPTIONAL. Free-text description of the hardware or software environment protecting the key. Examples: "iPhone 17s, iOS 23 patch 6", "AWS Nitro Enclave", "Azure Confidential VM, AMD SEV-SNP", "FIPS 140-3 Level 3 HSM".

  • event_timestamp - OPTIONAL. The time at which the credential was issued. JSON number representing seconds since Unix epoch.

The following example is non-normative.

{
  "iss": "https://authority.example.com/",
  "jti": "wise-evt-001",
  "iat": 1700000000,
  "aud": "https://rp.partner.example.net/wise",
  "events": {
    "https://schemas.openid.net/secevent/wise/event-type/credential-issued": {
      "subject": {
        "format": "uri",
        "uri": "wimse://trust.example.com/workload/payment-service"
      },
      "credential_type": "wic",
      "credential_id": "serial:ABC123DEF456",
      "expiry": 1700086400
    }
  }
}
Figure 1: Example: Credential Issued

2.2.2. credential-rotated

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/credential-rotated

The credential-rotated event signals that a workload's credential was rotated. A new credential replaces the previous one.

Attributes:

  • credential_type - REQUIRED. The type of credential rotated. Same values as in Section 2.2.1.

  • previous_credential_id - OPTIONAL. Identifier of the credential being replaced.

  • new_credential_id - OPTIONAL. Identifier of the newly issued credential.

  • grace_period_end - OPTIONAL. The time until which the previous credential remains valid. JSON number (NumericDate).

  • event_timestamp - OPTIONAL. The time at which the rotation occurred.

The following example is non-normative.

{
  "iss": "https://authority.example.com/",
  "jti": "wise-evt-002",
  "iat": 1700000000,
  "aud": "https://rp.partner.example.net/wise",
  "events": {
    "https://schemas.openid.net/secevent/wise/event-type/credential-rotated": {
      "subject": {
        "format": "uri",
        "uri": "wimse://trust.example.com/workload/payment-service"
      },
      "credential_type": "wit",
      "previous_credential_id": "jti:wit-2024-q4-001",
      "new_credential_id": "jti:wit-2024-q4-002",
      "grace_period_end": 1700003600
    }
  }
}
Figure 2: Example: Credential Rotated

2.2.3. credential-revoked

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/credential-revoked

The credential-revoked event signals that a workload's credential was explicitly revoked before its natural expiry.

Attributes:

  • credential_type - REQUIRED. The type of credential revoked.

  • credential_id - OPTIONAL. Identifier of the revoked credential.

  • reason - OPTIONAL. Why the credential was revoked. Possible values:

    • compromise - The credential is believed compromised.

    • key_compromise - The private key bound to the credential is believed compromised.

    • superseded - Replaced by a new credential.

    • cessation - The workload no longer operates.

    • policy_violation - Revoked due to a policy violation.

  • event_timestamp - OPTIONAL. The time at which revocation occurred.

The following example is non-normative.

{
  "iss": "https://authority.example.com/",
  "jti": "wise-evt-003",
  "iat": 1700000000,
  "aud": "https://rp.partner.example.net/wise",
  "events": {
    "https://schemas.openid.net/secevent/wise/event-type/credential-revoked": {
      "subject": {
        "format": "uri",
        "uri": "wimse://trust.example.com/workload/payment-service"
      },
      "credential_type": "wic",
      "credential_id": "serial:ABC123DEF456",
      "reason": "compromise"
    }
  }
}
Figure 3: Example: Credential Revoked

2.2.4. credential-compromise

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/credential-compromise

The credential-compromise event signals that a workload credential is believed to have been compromised. This is an advisory signal that may precede or accompany a credential-revoked event.

Attributes:

  • credential_type - REQUIRED. The type of credential compromised.

  • credential_id - OPTIONAL. Identifier of the compromised credential.

  • event_timestamp - OPTIONAL. The time at which the compromise was detected.

  • reason_admin - OPTIONAL. Localizable administrative description of the compromise, as defined in the Common Optional Claims (Section 2.1).

The following example is non-normative.

{
  "iss": "https://authority.example.com/",
  "jti": "wise-evt-004",
  "iat": 1700000000,
  "aud": "https://rp.partner.example.net/wise",
  "events": {
    "https://schemas.openid.net/secevent/wise/event-type/credential-compromise": {
      "subject": {
        "format": "uri",
        "uri": "wimse://trust.example.com/workload/payment-service"
      },
      "credential_type": "wit",
      "credential_id": "jti:wit-signing-key-2024-q4",
      "reason_admin": {
        "en": "Private key material detected in public repository"
      }
    }
  }
}
Figure 4: Example: Credential Compromise

2.2.5. credential-renewal-failure

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/credential-renewal-failure

The credential-renewal-failure event signals that the credential provisioning pipeline failed to renew a workload's credential. In the WIMSE model, credentials are intentionally short-lived to force regular posture evaluation before re-issuance. Under normal operation, renewal happens automatically. This event indicates that the renewal process has failed, and the workload may lose its ability to authenticate once the current credential expires.

Attributes:

  • credential_type - REQUIRED. The type of credential that failed to renew.

  • credential_id - OPTIONAL. Identifier of the credential that was not renewed.

  • current_expiry - OPTIONAL. Expiration of the current (last valid) credential. JSON number (NumericDate).

  • failure_reason - OPTIONAL. Why renewal failed. Possible values:

    • credential_service_unreachable - Cannot reach the Credential Service (Section 3.2.1 of [WIMSE-ARCH]).

    • posture_evaluation_failed - The workload did not pass posture evaluation.

    • policy_denied - Issuance policy denied renewal.

    • internal_error - Internal error in the provisioning pipeline.

  • event_timestamp - OPTIONAL. Time the failure was detected.

The following example is non-normative.

{
  "iss": "https://authority.example.com/",
  "jti": "wise-evt-005",
  "iat": 1700000000,
  "aud": "https://rp.partner.example.net/wise",
  "events": {
    "https://schemas.openid.net/secevent/wise/event-type/credential-renewal-failure": {
      "subject": {
        "format": "uri",
        "uri": "wimse://trust.example.com/workload/payment-service"
      },
      "credential_type": "wit",
      "current_expiry": 1700003600,
      "failure_reason": "posture_evaluation_failed"
    }
  }
}
Figure 5: Example: Credential Renewal Failure

2.3. Workload Lifecycle Events

These events signal changes to the lifecycle state of a workload as managed by the trust domain authority.

2.3.1. workload-disabled

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/workload-disabled

The workload-disabled event signals that the trust domain authority has suspended a workload. The authority will no longer issue credentials for this workload, and it cancels the workload's currently valid credentials. This event conveys only the lifecycle state change; the resulting credential cancellation is signalled separately through accompanying credential-revoked events. A Transmitter SHOULD emit those credential events together with this event.

Attributes:

  • reason - OPTIONAL. Why the workload was disabled. Possible values:

    • compromise - The workload is believed compromised.

    • policy_violation - Suspended due to a policy violation.

    • administrative - Disabled by an administrator.

    • maintenance - Temporarily disabled for maintenance.

  • event_timestamp - OPTIONAL. Time of disablement.

2.3.2. workload-enabled

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/workload-enabled

The workload-enabled event signals that a previously disabled workload is active again. The trust domain authority will resume issuing credentials for this workload. As with disablement, this event conveys only the lifecycle state change; any credential provisioned as a result is signalled separately through an accompanying credential-issued event.

Attributes:

  • event_timestamp - OPTIONAL. Time of re-enablement.

2.3.3. workload-purged

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/workload-purged

The workload-purged event signals that a workload has been permanently removed from the trust domain. This is irreversible. The workload will not be re-provisioned. All credentials previously issued for this workload MUST be considered invalid. As with workload-disabled, this event conveys only the lifecycle state change; the resulting credential cancellation is signalled separately through accompanying credential-revoked events.

Attributes:

  • event_timestamp - OPTIONAL. Time of removal.

2.4. Trust and Federation Events

These events signal changes to the trust material that federated peers and relying parties use to validate workload identity credentials from a trust domain.

2.4.1. trust-anchor-changed

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/trust-anchor-changed

The trust-anchor-changed event signals that the trust anchors for a trust domain have changed. Relying parties and federated peers MUST update their validation material accordingly.

Attributes:

  • anchor_type - REQUIRED. The type of trust material that changed. Possible values:

    • x509_ca - X.509 CA certificate(s) used to validate Workload Identity Certificates (WIC) or X.509-SVIDs.

    • jwks - JSON Web Key Set [RFC7517] used to validate Workload Identity Tokens (WIT).

  • change_type - REQUIRED. The nature of the change. Possible values:

    • key_added - A new key or CA was added to the trust bundle.

    • key_rotated - An existing key or CA was replaced.

    • key_revoked - A key or CA was revoked and MUST no longer be trusted.

    • key_expired - A key or CA has expired.

    • full_replacement - The entire trust bundle was replaced.

  • trust_domain - REQUIRED. The FQDN of the trust domain whose material changed.

  • effective_at - OPTIONAL. When the new material becomes (or became) active. JSON number (NumericDate).

  • old_material_expiry - OPTIONAL. When the old material will cease to be valid (grace period end). JSON number (NumericDate).

  • jwks_uri - OPTIONAL. When anchor_type is jwks, the URI to fetch the updated JWK Set.

  • x509_bundle_uri - OPTIONAL. When anchor_type is x509_ca, the URI to fetch the updated CA bundle.

  • key_id - OPTIONAL. The specific key affected. For JWKS, the kid value. For X.509, the certificate serial number or Subject Key Identifier.

  • reason - OPTIONAL. Why the change was made. Possible values:

    • scheduled_rotation - Routine key rotation.

    • compromise - A key or CA is believed compromised.

    • policy_change - Changed due to updated security policy.

    • expiry - Proactive rotation before scheduled expiry.

The following example is non-normative.

{
  "iss": "https://authority.example.com/",
  "jti": "wise-evt-020",
  "iat": 1700000000,
  "aud": "https://federation-peer.example.net/wise",
  "events": {
    "https://schemas.openid.net/secevent/wise/event-type/trust-anchor-changed": {
      "subject": {
        "format": "uri",
        "uri": "wimse://trust.example.com"
      },
      "anchor_type": "jwks",
      "change_type": "key_rotated",
      "trust_domain": "trust.example.com",
      "effective_at": 1700000000,
      "old_material_expiry": 1700604800,
      "jwks_uri": "https://authority.example.com/.well-known/jwks.json",
      "key_id": "kid:signing-2024-q4",
      "reason": "scheduled_rotation"
    }
  }
}
Figure 6: Example: Trust Anchor Changed (JWKS Rotation)

The following example is non-normative.

{
  "iss": "https://authority.example.com/",
  "jti": "wise-evt-021",
  "iat": 1700000000,
  "aud": "https://federation-peer.example.net/wise",
  "events": {
    "https://schemas.openid.net/secevent/wise/event-type/trust-anchor-changed": {
      "subject": {
        "format": "uri",
        "uri": "wimse://trust.example.com"
      },
      "anchor_type": "x509_ca",
      "change_type": "key_revoked",
      "trust_domain": "trust.example.com",
      "key_id": "serial:CA-ROOT-2023-001",
      "reason": "compromise"
    }
  }
}
Figure 7: Example: Trust Anchor Changed (CA Compromise)

2.4.2. trust-domain-federation-revoked

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/trust-domain-federation-revoked

The trust-domain-federation-revoked event signals that a previously federated trust domain is no longer trusted. All workload credentials originating from the specified trust domain MUST be rejected.

Attributes:

  • trust_domain - REQUIRED. The FQDN of the trust domain that is no longer trusted.

  • reason - OPTIONAL. Why federation was revoked. Possible values:

    • compromise - The federated domain is believed compromised.

    • policy_violation - Federation revoked due to policy.

    • administrative - Administrative decision to end federation.

    • contractual - Business relationship ended.

  • effective_at - OPTIONAL. When the revocation takes effect. JSON number (NumericDate).

  • event_timestamp - OPTIONAL. Time the decision was made.

2.5. Policy and Posture Evaluation Events

These events signal changes to the policies governing workload identity issuance, posture evaluation, and credential validation within or across trust domains.

In the WIMSE model, posture evaluation is the process by which the Credential Service assesses a workload's runtime environment, software integrity, and deployment context before issuing or renewing credentials. This replaces the traditional notion of static attestation with a continuous evaluation model.

2.5.1. issuance-policy-changed

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/issuance-policy-changed

The issuance-policy-changed event signals that the policy governing credential issuance for workloads has changed. This may affect which workloads are eligible for credentials, what credential types are issued, lifetime constraints, or required posture evidence.

Attributes:

  • policy_id - OPTIONAL. Identifier of the policy that changed.

  • change_description - OPTIONAL. Human-readable description of the change.

  • effective_at - OPTIONAL. When the new policy takes effect.

  • event_timestamp - OPTIONAL. Time the change was made.

2.5.2. posture-evaluation-policy-changed

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/posture-evaluation-policy-changed

The posture-evaluation-policy-changed event signals that the posture evaluation policy has changed. This may affect which evidence is required from workloads, what evaluation criteria apply, or what deployment context signals are considered during credential issuance and renewal.

Attributes:

  • policy_id - OPTIONAL. Identifier of the policy that changed.

  • change_description - OPTIONAL. Human-readable description.

  • effective_at - OPTIONAL. When the new policy takes effect.

  • event_timestamp - OPTIONAL. Time the change was made.

2.5.3. validation-policy-changed

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/validation-policy-changed

The validation-policy-changed event signals that the policy used to validate workload identity credentials at relying parties has changed. This includes changes to trust anchor validation rules, claim validation requirements, audience restrictions, or acceptable credential types.

Attributes:

  • policy_id - OPTIONAL. Identifier of the policy that changed.

  • change_description - OPTIONAL. Human-readable description.

  • effective_at - OPTIONAL. When the new policy takes effect.

  • event_timestamp - OPTIONAL. Time the change was made.

2.5.4. posture-evaluation-failed

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/posture-evaluation-failed

The posture-evaluation-failed event signals that a workload did not pass posture evaluation. The Credential Service determined that the workload's runtime environment, software integrity, or deployment context did not meet the requirements for credential issuance.

Attributes:

  • evaluation_type - OPTIONAL. The scope of evaluation that failed. Possible values:

    • platform - Platform-level evaluation (e.g., node integrity, TEE verification).

    • workload - Workload-level evaluation (e.g., binary identity, image hash).

    • runtime - Runtime environment evaluation (e.g., configuration compliance, network posture).

  • reason - OPTIONAL. Why the evaluation failed.

  • event_timestamp - OPTIONAL. Time of the failure.

2.5.5. posture-evaluation-succeeded

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/posture-evaluation-succeeded

The posture-evaluation-succeeded event signals that a workload successfully passed posture evaluation. This event is produced as part of the regular credential provisioning process. It confirms that the workload met the Credential Service's requirements and that a credential was or will be issued.

This event does not imply that a prior failure occurred. It is generated each time posture evaluation completes successfully, providing an audit trail and enabling downstream systems to track the health of the provisioning pipeline.

Attributes:

  • evaluation_type - OPTIONAL. The scope of evaluation that succeeded.

  • event_timestamp - OPTIONAL. Time of successful evaluation.

2.6. Runtime Posture Events

2.6.1. workload-baseline-changed

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/workload-baseline-changed

The workload-baseline-changed event signals that a workload's runtime environment, deployment context, or metadata has changed. This may trigger re-evaluation of trust by relying parties or require the workload to undergo posture evaluation before new credentials are issued.

Attributes:

  • reason - OPTIONAL. Why the baseline changed. Possible values:

    • migration - Workload moved to a different node, region, or zone.

    • scaling - New instances added or removed.

    • redeployment - Workload was redeployed (same identity, new instance).

    • image_update - Runtime image or binary was updated.

    • config_change - Configuration affecting identity posture changed.

    • node_reassignment - Underlying compute node changed.

  • previous_context - OPTIONAL. JSON object describing the prior environment metadata (structure defined by implementation).

  • current_context - OPTIONAL. JSON object describing the new environment metadata.

  • posture_evaluation_status - OPTIONAL. Whether posture re-evaluation has occurred. Possible values:

    • succeeded - Re-evaluation completed successfully.

    • pending - Re-evaluation has not yet occurred.

    • failed - Re-evaluation was attempted and failed.

  • event_timestamp - OPTIONAL. Time of the change.

The following example is non-normative.

{
  "iss": "https://authority.example.com/",
  "jti": "wise-evt-030",
  "iat": 1700000000,
  "aud": "https://rp.partner.example.net/wise",
  "events": {
    "https://schemas.openid.net/secevent/wise/event-type/workload-baseline-changed": {
      "subject": {
        "format": "uri",
        "uri": "wimse://trust.example.com/workload/payment-service"
      },
      "reason": "migration",
      "previous_context": {
        "region": "us-east-1",
        "node": "node-abc"
      },
      "current_context": {
        "region": "eu-west-1",
        "node": "node-xyz"
      },
      "posture_evaluation_status": "succeeded"
    }
  }
}
Figure 8: Example: Workload Baseline Changed (Migration)

2.6.2. workload-compromised

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/workload-compromised

The workload-compromised event signals that a workload is believed to be compromised based on runtime detection. This is a high-severity signal that SHOULD trigger immediate isolation or credential revocation.

Attributes:

  • detection_method - OPTIONAL. How the compromise was detected.

  • reason_admin - OPTIONAL. Localizable administrative description, as defined in the Common Optional Claims (Section 2.1).

  • event_timestamp - OPTIONAL. Time of detection.

2.6.3. anomalous-behavior-detected

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/anomalous-behavior-detected

The anomalous-behavior-detected event signals that unusual behavior was observed for a workload. This is an advisory signal of lower severity than workload-compromised, intended for SIEM and SOC integration.

Attributes:

  • anomaly_type - OPTIONAL. Category of the anomaly.

  • severity - OPTIONAL. Severity level. Possible values:

  • reason_admin - OPTIONAL. Localizable administrative description, as defined in the Common Optional Claims (Section 2.1).

  • event_timestamp - OPTIONAL. Time of detection.

2.7. Supply Chain Events

These events signal changes in a workload's supply chain including the provenance of the software it is built from and the vulnerability status of its components. The underlying detail such as a Software Bill of Materials (SBOM), a build attestation, or a vulnerability advisory is typically held in a separate document maintained by other tooling. These events act as signals that inform a relying party that something relevant has changed, and where to obtain the detail, rather than carrying the full supply-chain record inline.

2.7.1. workload-provenance-changed

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/workload-provenance-changed

The workload-provenance-changed event signals that the provenance of a workload, such as its SBOM or a build attestation has changed. This includes newly available or updated provenance, and the revocation or failed verification of previously trusted provenance. A relying party may re-evaluate its trust in the workload, or fetch the referenced document to assess the change.

Attributes:

  • change_type - REQUIRED. The nature of the change. Possible values:

    • updated - New or updated provenance (for example, a new SBOM) is available.

    • revoked - Previously trusted provenance or an attestation is no longer valid.

    • verification_failed - Verification of the workload's provenance failed.

  • provenance_uri - OPTIONAL. A URI at which the affected provenance document can be retrieved.

  • provenance_format - OPTIONAL. A hint indicating the kind of document referenced, for example sbom or attestation.

  • artifact_digest - OPTIONAL. A digest of the workload artifact (such as a container image) that the provenance describes, allowing the relying party to correlate the event with what is running.

  • reason_admin - OPTIONAL. Localizable administrative description of the change, as defined in the Common Optional Claims (Section 2.1).

  • event_timestamp - OPTIONAL. The time the change occurred.

The following example is non-normative.

{
  "iss": "https://authority.example.com/",
  "jti": "wise-evt-040",
  "iat": 1700000000,
  "aud": "https://rp.partner.example.net/wise",
  "events": {
    "https://schemas.openid.net/secevent/wise/event-type/workload-provenance-changed": {
      "subject": {
        "format": "uri",
        "uri": "wimse://trust.example.com/workload/payment-service"
      },
      "change_type": "revoked",
      "provenance_uri": "https://provenance.example.com/payment-service/attestation",
      "reason_admin": {
        "en": "Build provenance attestation revoked by source repository owner"
      }
    }
  }
}
Figure 9: Example: Workload Provenance Changed

2.7.2. workload-vulnerability-status-changed

Event Type URI: https://schemas.openid.net/secevent/wise/event-type/workload-vulnerability-status-changed

The workload-vulnerability-status-changed event signals a change in the status of a vulnerability with respect to a workload. The status values follow the Vulnerability Exploitability eXchange (VEX) model [VEX], which distinguishes whether a workload is actually affected by a known vulnerability. This allows a transmitter both to warn a relying party that a workload has become affected, and to relax a prior warning when a vulnerability is found not to apply or has been fixed.

Attributes:

  • vulnerability_id - REQUIRED. A public identifier for the vulnerability, such as a CVE identifier.

  • status - REQUIRED. The status of the workload with respect to the vulnerability, following the VEX model [VEX]. Possible values:

    • affected - Actions are recommended to remediate or address the vulnerability.

    • not_affected - No remediation is required (for example, the vulnerable code is not reachable).

    • fixed - This workload contains a fix for the vulnerability.

    • under_investigation - Whether the workload is affected is not yet known.

  • severity - OPTIONAL. A qualitative severity to help the relying party prioritise. Possible values: low, medium, high, critical.

  • advisory_uri - OPTIONAL. A URI at which a full advisory or VEX statement can be retrieved.

  • reason_admin - OPTIONAL. Localizable administrative description, as defined in the Common Optional Claims (Section 2.1).

  • event_timestamp - OPTIONAL. The time the status changed.

The following example is non-normative.

{
  "iss": "https://authority.example.com/",
  "jti": "wise-evt-041",
  "iat": 1700000000,
  "aud": "https://rp.partner.example.net/wise",
  "events": {
    "https://schemas.openid.net/secevent/wise/event-type/workload-vulnerability-status-changed": {
      "subject": {
        "format": "uri",
        "uri": "wimse://trust.example.com/workload/payment-service"
      },
      "vulnerability_id": "CVE-2026-12345",
      "status": "affected",
      "severity": "critical",
      "advisory_uri": "https://advisories.example.com/CVE-2026-12345"
    }
  }
}
Figure 10: Example: Workload Vulnerability Status Changed

3. Subject Identifiers for Workload Events

WISE events use subject identifiers as defined in [RFC9493]. Workload identities in the WIMSE model are expressed as URIs following the format defined in [WIMSE-ID].

3.1. URI Format

The uri format is the primary subject identifier format for WISE events. It carries the Workload Identifier as defined in [WIMSE-ID], which is a URI containing a trust domain in the authority component and a workload-specific path.

The following example is non-normative.

{
  "format": "uri",
  "uri": "wimse://trust.example.com/workload/payment-service"
}

Deployments using SPIFFE identifiers [SPIFFE] express the subject using the spiffe URI scheme:

The following example is non-normative.

{
  "format": "uri",
  "uri": "spiffe://trust.example.com/ns/production/sa/payment-service"
}

Deployments using OAuth 2.0 Client ID Metadata Documents [CIMD] may express the workload subject using the client identifier URI:

The following example is non-normative.

{
  "format": "uri",
  "uri": "https://client.example.com/.well-known/oauth-client"
}

3.2. Trust Domain Subject

For events that apply to an entire trust domain (e.g., trust-anchor-changed, trust-domain-federation-revoked), the subject identifies the trust domain itself using its Workload Identifier Origin as defined in [WIMSE-ID]:

The following example is non-normative.

{
  "format": "uri",
  "uri": "wimse://trust.example.com"
}

4. Security Considerations

4.1. Confidentiality

WISE events MAY contain sensitive information about workload infrastructure topology, credential identifiers, and security posture. All network requests in this protocol MUST use TLS, and the use of TLS MUST follow the recommendations in [RFC9325]. Events SHOULD be encrypted using JSON Web Encryption (JWE) [RFC7516] when transmitted across trust domain boundaries.

4.2. Replay and Freshness

Receivers MUST validate the iat claim and reject events that are unreasonably old. Receivers SHOULD maintain a record of recently received jti values to detect replay attacks.

4.3. Authorization

Access to WISE event streams MUST be authorized. Transmitters MUST verify that Receivers are authorized to receive events for the specified subjects. A trust domain authority SHOULD NOT transmit workload-level events to parties that have no trust relationship with those workloads.

4.4. Compromise Response

Upon receiving a credential-compromise, credential-revoked (with reason compromise or key_compromise), trust-anchor-changed (with reason compromise), or workload-compromised event, Receivers SHOULD take immediate action to reject the affected credentials, keys, or trust material without waiting for additional confirmation.

4.5. Relationship to Credential Freshness Models

Deployments use different mechanisms to limit the exposure window of a compromised or deprovisioned workload:

  • Issuer-side status signalling, where the trust domain authority communicates lifecycle changes to relying parties through an event channel. The events defined in this specification serve this purpose.

  • Short credential lifetime, where the remaining validity period bounds the exposure window. In the WIMSE model, credentials are intentionally short-lived to force posture evaluation before re-issuance.

  • Condition-liveness, where a locally observable condition (hardware release policy, TEE state, platform integrity measurement) gates each key operation. Failure of the condition prevents the next presentation or handshake step without requiring a remote signal.

These mechanisms are complementary, not mutually exclusive. Condition-bounded credentials reduce the local deprovisioning window but cannot observe externally originated changes: issuer policy withdrawal, trust anchor rotation, cross-domain incident response, or administrative decisions to terminate an established connection. WISE events address these cases. Deployments combining short-lived credentials with condition-liveness properties still benefit from issuer-side signalling for lifecycle changes that no local mechanism can detect.

4.6. Supply Chain Signals

Supply chain events are advisory inputs to a Receiver's own decision-making. A Receiver SHOULD treat a workload-vulnerability-status-changed event as information to be evaluated against its own policies, rather than as a directive to be enforced automatically. In particular, a Receiver SHOULD NOT block, revoke, or otherwise restrict a workload's access solely because such an event was received. It SHOULD weigh the event together with the referenced advisory, the reported status and severity, and its own risk posture before deciding what action, if any, to take. A revoked provenance change, once validated, indicates that the affected provenance MUST NOT be relied upon.

5. Privacy Considerations

WISE events may reveal information about internal infrastructure, deployment patterns, scaling behavior, and security incidents. Transmitters SHOULD minimize the information disclosed to what is necessary for the Receiver to take appropriate action.

Events SHOULD NOT include personally identifiable information. Workload identifiers SHOULD NOT encode information about the humans who manage or operate the workloads.

6. IANA Considerations

This specification defines no new IANA registrations. Event Type URIs are registered under the OpenID Foundation namespace.

7. References

7.1. Normative References

[RFC5646]
Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, , <https://www.rfc-editor.org/rfc/rfc5646>.
[RFC7516]
Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, , <https://www.rfc-editor.org/rfc/rfc7516>.
[RFC7523]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, , <https://www.rfc-editor.org/rfc/rfc7523>.
[RFC8417]
Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, , <https://www.rfc-editor.org/rfc/rfc8417>.
[RFC8705]
Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, , <https://www.rfc-editor.org/rfc/rfc8705>.
[RFC9325]
Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, , <https://www.rfc-editor.org/rfc/rfc9325>.
[RFC9493]
Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, , <https://www.rfc-editor.org/rfc/rfc9493>.
[SSF]
Tulshibagwale, A., Cappalli, T., Scurtescu, M., Backman, A., Bradley, J., and S. Miel, "OpenID Shared Signals Framework Specification 1.0", , <https://openid.net/specs/openid-sharedsignals-framework-1_0.html>.
[CAEP]
Cappalli, T. and A. Tulshibagwale, "OpenID Continuous Access Evaluation Profile 1.0", , <https://openid.net/specs/openid-caep-1_0.html>.
[RISC]
Scurtescu, M., Backman, A., Hunt, P., Bradley, J., Bounev, S., and A. Tulshibagwale, "OpenID RISC Profile Specification 1.0", , <https://openid.net/specs/openid-risc-1_0-final.html>.
[WIMSE-ARCH]
Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", , <https://www.ietf.org/archive/id/draft-ietf-wimse-arch-07.html>.
[WIMSE-ID]
Rosomakho, Y. and J. Salowey, "Workload Identifier", , <https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/>.
[WIMSE-CRED]
Campbell, B., Salowey, J., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", , <https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/>.
[WPT]
Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", , <https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

7.2. Informative References

[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7517]
Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, , <https://www.rfc-editor.org/rfc/rfc7517>.
[SPIFFE]
"Secure Production Identity Framework for Everyone", , <https://spiffe.io/docs/latest/spiffe-specs/spiffe/>.
[AGENT-AUTH]
Kasselman, P., Hardt, D., and A. Schwenkschuster, "AI Agent Authentication and Authorization", , <https://www.ietf.org/archive/id/draft-klrc-aiagent-auth-02.html>.
[CIMD]
Parecki, A., "Client ID Metadata Document", , <https://www.ietf.org/archive/id/draft-parecki-oauth-client-id-metadata-document-07.html>.
[VEX]
"Minimum Requirements for Vulnerability Exploitability eXchange (VEX)", , <https://www.cisa.gov/resources-tools/resources/minimum-requirements-vulnerability-exploitability-exchange-vex>.

Acknowledgments

The authors would like to thank the members of the OpenID Foundation Shared Signals Working Group and the IETF WIMSE Working Group for their contributions to this specification.

Document History

-02

-01

-00

Authors' Addresses

Jeff Lombardo
Amazon Web Services
Dag Sneeggen
Signicat
Sean O'Dell
CVS Health
Pieter Kasselman
Defakto Security