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 Security Event Token (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 machine identity lifecycle as described in the WIMSE architecture [WIMSE-ARCH].¶
+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].¶
2.1. Workload Credential Lifecycle Events
-2.3. Workload Identity State Events
+2.3. Workload Lifecycle Events
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, 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 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.¶
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.¶
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.¶
A single trust domain authority issues workload identity credentials for all workloads within that domain.¶
+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 single authority governs each trust domain, WISE events are designed to signal state changes:¶
+Because a trust domain acts as the issuing authority for the workloads within it, WISE events are designed to signal state changes:¶
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"
+}
+¶
+These events signal changes to the credentials issued to workloads by -the trust domain authority.¶
-This specification defines event types that apply to workload +
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.¶
+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.¶
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:¶
+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:¶
+credential_type - REQUIRED. The type of credential issued. Possible values:¶
wit - Workload Identity Token as defined in [WIMSE-CRED]¶
wit - Workload Identity Token as defined in [WIMSE-CRED]¶
wic - Workload Identity Certificate as defined in [WIMSE-CRED]¶
wic - Workload Identity Certificate as defined in [WIMSE-CRED]¶
x509_generic - Generic X.509 certificate not conforming to WIC or SVID profiles¶
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 (RFC 7523)¶
oauth_private_key_jwt - OAuth 2.0 client authentication using private_key_jwt [RFC7523]¶
oauth_mtls - OAuth 2.0 mutual TLS client authentication (RFC 8705)¶
oauth_mtls - OAuth 2.0 mutual TLS client authentication [RFC8705]¶
oauth_client_secret - OAuth 2.0 client_id and client_secret credential pair¶
oauth_client_secret - OAuth 2.0 client_id and client_secret credential pair¶
api_key - Static API key or long-lived bearer token¶
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.¶
+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]).¶
credential_id - OPTIONAL. An identifier for the credential (e.g., certificate serial number, jti claim value).¶
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.¶
expiry - OPTIONAL. The expiration time of the credential as a JSON number (NumericDate per [RFC7519]).¶
+software - Key is stored in software (filesystem, memory, or application-managed keystore).¶
event_timestamp - OPTIONAL. The time at which the credential was issued. JSON number representing seconds since Unix epoch.¶
+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.¶
+The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
@@ -1617,34 +1676,34 @@
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:¶
+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.1.1.¶
+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.¶
+previous_credential_id - OPTIONAL. Identifier of the credential being replaced.¶
new_credential_id - OPTIONAL. Identifier of the newly issued credential.¶
+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).¶
+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.¶
+event_timestamp - OPTIONAL. The time at which the rotation occurred.¶
The following example is non-normative.¶
+The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
@@ -1673,45 +1732,48 @@
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:¶
+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_type - REQUIRED. The type of credential revoked.¶
credential_id - OPTIONAL. Identifier of the revoked credential.¶
+credential_id - OPTIONAL. Identifier of the revoked credential.¶
reason - OPTIONAL. Why the credential was revoked. Possible values:¶
+reason - OPTIONAL. Why the credential was revoked. Possible values:¶
compromise - The credential is believed compromised.¶
compromise - The credential is believed compromised.¶
key_compromise - The private key bound to the credential is believed compromised.¶
superseded - Replaced by a new credential.¶
superseded - Replaced by a new credential.¶
cessation - The workload no longer operates.¶
cessation - The workload no longer operates.¶
policy_violation - Revoked due to a policy violation.¶
policy_violation - Revoked due to a policy violation.¶
event_timestamp - OPTIONAL. The time at which revocation occurred.¶
+event_timestamp - OPTIONAL. The time at which revocation occurred.¶
The following example is non-normative.¶
+The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
@@ -1739,31 +1801,31 @@
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:¶
+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_type - REQUIRED. The type of credential compromised.¶
credential_id - OPTIONAL. Identifier of the compromised credential.¶
+credential_id - OPTIONAL. Identifier of the compromised credential.¶
event_timestamp - OPTIONAL. The time at which the compromise was detected.¶
+event_timestamp - OPTIONAL. The time at which the compromise was detected.¶
reason_admin - OPTIONAL. A human-readable description of the compromise, intended for administrators.¶
+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.¶
+The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
@@ -1778,7 +1840,9 @@
},
"credential_type": "wit",
"credential_id": "jti:wit-signing-key-2024-q4",
- "reason_admin": "Private key material detected in public repository"
+ "reason_admin": {
+ "en": "Private key material detected in public repository"
+ }
}
}
}
@@ -1791,48 +1855,48 @@
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:¶
+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_type - REQUIRED. The type of credential that failed to renew.¶
credential_id - OPTIONAL. Identifier of the credential that was not renewed.¶
+credential_id - OPTIONAL. Identifier of the credential that was not renewed.¶
current_expiry - OPTIONAL. Expiration of the current (last valid) credential. JSON number (NumericDate).¶
+current_expiry - OPTIONAL. Expiration of the current (last valid) credential. JSON number (NumericDate).¶
failure_reason - OPTIONAL. Why renewal failed. Possible values:¶
+failure_reason - OPTIONAL. Why renewal failed. Possible values:¶
identity_server_unreachable - Cannot reach the Identity Server.¶
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.¶
posture_evaluation_failed - The workload did not pass posture evaluation.¶
policy_denied - Issuance policy denied renewal.¶
policy_denied - Issuance policy denied renewal.¶
internal_error - Internal error in the provisioning pipeline.¶
internal_error - Internal error in the provisioning pipeline.¶
event_timestamp - OPTIONAL. Time the failure was detected.¶
+event_timestamp - OPTIONAL. Time the failure was detected.¶
The following example is non-normative.¶
+The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
@@ -1861,216 +1925,19 @@
Bound keys are proof-of-possession keys cryptographically tied to a workload credential. They have an independent lifecycle from the credential itself. A credential may remain valid while its bound key is rotated or revoked, and a key compromise may be addressed without full credential revocation.¶
-In the WIMSE model, the WIT contains a cnf claim binding a public key to the workload identity. The corresponding private key is used to produce Workload Proof Tokens (WPT). Bound keys in this context include DPoP proof keys, mTLS certificate-bound keys, and attestation keys used during posture evaluation.¶
Event Type URI: https://schemas.openid.net/secevent/wise/event-type/bound-key-issued¶
The bound-key-issued event signals that a new proof-of-possession key was bound to a workload credential.¶
Attributes:¶
-key_type - REQUIRED. The type of key binding. Possible values:¶
- -key_id - OPTIONAL. Identifier of the bound key (kid or Subject Key Identifier).¶
credential_id - OPTIONAL. Identifier of the credential the key is bound to.¶
-key_storage - OPTIONAL. Where the private key material is stored. Possible values:¶
- -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".¶
-expiry - OPTIONAL. Expiration of the bound key. JSON number (NumericDate).¶
-event_timestamp - OPTIONAL. Time of issuance.¶
-The following example is non-normative.¶
-
-{
- "iss": "https://authority.example.com/",
- "jti": "wise-evt-010",
- "iat": 1700000000,
- "aud": "https://rp.partner.example.net/wise",
- "events": {
- "https://schemas.openid.net/secevent/wise/event-type/bound-key-issued": {
- "subject": {
- "format": "uri",
- "uri": "wimse://trust.example.com/workload/payment-service"
- },
- "key_type": "cnf",
- "key_id": "kid:wpt-key-2024-11",
- "credential_id": "jti:wit-2024-q4-002",
- "key_storage": "hardware",
- "key_storage_ecosystem": "AWS Nitro Enclave"
- }
- }
-}
-
-Event Type URI: https://schemas.openid.net/secevent/wise/event-type/bound-key-rotated¶
The bound-key-rotated event signals that the bound key associated with a workload credential was rotated.¶
Attributes:¶
-key_type - REQUIRED. The type of key binding.¶
-previous_key_id - OPTIONAL. Identifier of the key being replaced.¶
-new_key_id - OPTIONAL. Identifier of the new key.¶
-credential_id - OPTIONAL. Identifier of the associated credential.¶
-key_storage - OPTIONAL. Where the new key is stored (hardware or software).¶
key_storage_ecosystem - OPTIONAL. Free-text description of the environment protecting the new key.¶
-grace_period_end - OPTIONAL. Time until which the previous key remains accepted for proof-of-possession validation.¶
-event_timestamp - OPTIONAL. Time of rotation.¶
-Event Type URI: https://schemas.openid.net/secevent/wise/event-type/bound-key-revoked¶
The bound-key-revoked event signals that a bound key was revoked. The associated credential MAY still be valid, but proof-of-possession using the revoked key MUST be rejected.¶
Attributes:¶
-key_type - REQUIRED. The type of key binding.¶
-key_id - OPTIONAL. Identifier of the revoked key.¶
-credential_id - OPTIONAL. Identifier of the associated credential.¶
-reason - OPTIONAL. Why the key was revoked. Possible values:¶
- -event_timestamp - OPTIONAL. Time of revocation.¶
-The following example is non-normative.¶
-
-{
- "iss": "https://authority.example.com/",
- "jti": "wise-evt-012",
- "iat": 1700000000,
- "aud": "https://rp.partner.example.net/wise",
- "events": {
- "https://schemas.openid.net/secevent/wise/event-type/bound-key-revoked": {
- "subject": {
- "format": "uri",
- "uri": "wimse://trust.example.com/workload/payment-service"
- },
- "key_type": "cnf",
- "key_id": "kid:wpt-key-2024-11",
- "credential_id": "jti:wit-2024-q4-002",
- "reason": "compromise"
- }
- }
-}
-
-These events signal changes to the state of a workload identity as managed by the trust domain authority.¶
+These events signal changes to the lifecycle state of a workload as managed by the trust domain authority.¶
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 identity. The authority will no longer issue credentials for this workload. Existing credentials MAY still be valid until their natural expiry unless explicitly revoked.¶
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:¶
Event Type URI: https://schemas.openid.net/secevent/wise/event-type/workload-enabled¶
The workload-enabled event signals that a previously disabled workload identity is active again. The trust domain authority will resume issuing credentials for this workload.¶
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 Type URI: https://schemas.openid.net/secevent/wise/event-type/workload-purged¶
The workload-purged event signals that a workload identity has been permanently removed from the trust domain. This is irreversible. The identity will not be re-issued. All credentials previously issued for this workload MUST be considered invalid.¶
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:¶
change_type - REQUIRED. The nature of the change. Possible values:¶
key-added - A new key or CA was added to the trust bundle.¶
key_added - A new key or CA was added to the trust bundle.¶
key-rotated - An existing key or CA was replaced.¶
key_rotated - An existing key or CA was replaced.¶
key-revoked - A key or CA was revoked and MUST no longer be trusted.¶
key_revoked - A key or CA was revoked and MUST no longer be trusted.¶
key-expired - A key or CA has expired.¶
key_expired - A key or CA has expired.¶
full-replacement - The entire trust bundle was replaced.¶
full_replacement - The entire trust bundle was replaced.¶
reason - OPTIONAL. Why the change was made. Possible values:¶
scheduled-rotation - Routine key rotation.¶
scheduled_rotation - Routine key rotation.¶
compromise - A key or CA is believed compromised.¶
policy-change - Changed due to updated security policy.¶
policy_change - Changed due to updated security policy.¶
expiry - Proactive rotation before scheduled expiry.¶
The following example is non-normative.¶
{
@@ -2227,25 +2094,25 @@
"uri": "wimse://trust.example.com"
},
"anchor_type": "jwks",
- "change_type": "key-rotated",
+ "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"
+ "reason": "scheduled_rotation"
}
}
}
The following example is non-normative.¶
{
@@ -2260,7 +2127,7 @@
"uri": "wimse://trust.example.com"
},
"anchor_type": "x509_ca",
- "change_type": "key-revoked",
+ "change_type": "key_revoked",
"trust_domain": "trust.example.com",
"key_id": "serial:CA-ROOT-2023-001",
"reason": "compromise"
@@ -2269,7 +2136,7 @@
}
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 Identity Server 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.¶
+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.¶
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 Identity Server determined that the workload's runtime environment, software integrity, or deployment context did not meet the requirements for credential issuance.¶
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:¶
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 Identity Server's requirements and that a credential was or will be issued.¶
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:¶
redeployment - Workload was redeployed (same identity, new instance).¶
image-update - Runtime image or binary was updated.¶
image_update - Runtime image or binary was updated.¶
config-change - Configuration affecting identity posture changed.¶
config_change - Configuration affecting identity posture changed.¶
node-reassignment - Underlying compute node changed.¶
node_reassignment - Underlying compute node changed.¶
The following example is non-normative.¶
{
@@ -2539,7 +2406,7 @@
}
detection_method - OPTIONAL. How the compromise was detected.¶
reason_admin - OPTIONAL. Description for administrators.¶
+reason_admin - OPTIONAL. Localizable administrative description, as defined in the Common Optional Claims (Section 2.1).¶
event_timestamp - OPTIONAL. Time of detection.¶
@@ -2596,7 +2463,7 @@reason_admin - OPTIONAL. Description for administrators.¶
+reason_admin - OPTIONAL. Localizable administrative description, as defined in the Common Optional Claims (Section 2.1).¶
event_timestamp - OPTIONAL. Time of detection.¶
@@ -2606,6 +2473,158 @@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.¶
+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:¶
+ +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"
+ }
+ }
+ }
+}
+
+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"
+ }
+ }
+}
+
+WISE events MAY contain sensitive information about workload infrastructure topology, credential identifiers, and security posture. Transmitters and Receivers MUST use encrypted transport (TLS 1.2 or later) for all event delivery. Events SHOULD be encrypted using JSON Web Encryption (JWE) [RFC7516] when transmitted across trust domain boundaries.¶
+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.¶
Upon receiving a credential-compromise, bound-key-revoked (with reason 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.¶
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.¶
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.¶
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.¶
-00¶
+-02¶
Initial draft.¶
+Removed the Bound Key Lifecycle Events (bound-key-issued, bound-key-rotated, bound-key-revoked); key compromise and rotation are now handled through the credential events, and a key_compromise reason was added to credential-revoked. The key_storage and key_storage_ecosystem attributes moved to credential-issued.¶
Aligned terminology with the WIMSE architecture: replaced "Identity Server" with "Credential Service", and "machine identity lifecycle" with "workload identity lifecycle".¶
+Softened the single-authority language and aligned it with WIMSE (a trust domain maps to one or more trust anchors).¶
+Renamed "Workload Identity State Events" to "Workload Lifecycle Events" and clarified that credential cancellation and issuance are conveyed by separate companion events.¶
+Added a "Common Optional Claims" section aligning reason_admin, reason_user, and initiating_entity with CAEP as localizable objects.¶
Promoted RISC to a normative reference and refreshed the RISC, CAEP, and SSF references to their final 1.0 versions.¶
+Added normative references for WPT, RFC 5646, RFC 7523, RFC 8705, and RFC 9325, and cited RFC 7517 for the JWK Set.¶
+Replaced the TLS 1.2 requirement with a normative reference to the TLS recommendations in RFC 9325.¶
+Normalized enum values to use underscores while keeping event type names hyphenated.¶
+-01¶
+Added Supply Chain Events¶
+-00¶
+Initial draft.¶