| wiseset | September 2026 | |
| Lombardo, et al. | Standards Track | [Page] |
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].¶
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 [AIMS], 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.¶
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.¶
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:¶
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.¶
The base URI for WISE event types is:¶
https://schemas.openid.net/secevent/wise/event-type/¶
Every WISE event payload MUST include the following common mandatory claim. Mandatory common claims are omitted from the per-event attribute lists in the following sections to avoid repetition.¶
event_timestamp - REQUIRED. A JSON number containing a NumericDate, as defined in [RFC7519], that identifies when the event occurred. For an event that reports a decision or detection, it identifies when the decision was made or the condition was detected, respectively. event_timestamp is a member of the individual event payload, not a top-level SET claim. Its value can differ from the containing SET's top-level iat value and from the optional effective_at value.¶
Unless stated otherwise, any WISE event MAY include the common optional claims listed below. The reason_admin, reason_user, and initiating_entity claims are defined in Section 2 of [CAEP]. The effective_at claim is defined by this specification.¶
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.¶
effective_at - OPTIONAL. A JSON number containing a NumericDate, as defined in [RFC7519], that identifies when the change described by the event takes effect. effective_at is a member of the individual event payload, not a top-level SET claim. Its value MAY be earlier than, equal to, or later than the iat value of the containing SET. If effective_at is omitted, the change MUST be treated as effective as of the containing SET's iat value. A Receiver processing the SET at or after that time MUST apply the event-specific processing requirements immediately upon receipt. This claim does not override event-specific processing requirements.¶
To avoid repetition, these common claims are not listed in the per-event attribute definitions in the following sections; any event MAY carry them, and some examples include them for illustration.¶
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 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 signaled 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:¶
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_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. A Receiver MAY use this to inform its trust decision, for example whether to require additional assurance before relying on the credential. Possible values:¶
software - Key is held in software with no additional at-rest protection (filesystem, process memory, or an application-managed keystore).¶
software_encrypted - Key is held in software but encrypted at rest (for example, an OS keychain or an encrypted keystore) rather than in tamper-resistant hardware.¶
hardware_tpm - Key is protected by a Trusted Platform Module (TPM).¶
hardware_hsm - Key is protected by a Hardware Security Module (HSM).¶
hardware_secure_enclave - Key is protected by a secure enclave or an equivalent platform trusted-execution environment (for example, a mobile secure element or a TEE-backed keystore).¶
vaulted - Key is held by a secrets manager or vault and is never released to the workload in plaintext; the workload calls the vault to perform key operations.¶
unknown - The storage mechanism is not known to the Transmitter.¶
Additional values MAY be defined by profiling specifications or private agreement between Transmitter and Receiver.¶
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".¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-001",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/credential-issued": {
"credential_type": "wic",
"credential_id": "serial:ABC123DEF456",
"expiry": 1700086400,
"event_timestamp": 1700000000
}
}
}
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.4.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).¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-002",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/credential-rotated": {
"credential_type": "wit",
"previous_credential_id": "jti:wit-2024-q4-001",
"new_credential_id": "jti:wit-2024-q4-002",
"grace_period_end": 1700003600,
"event_timestamp": 1700000000
}
}
}
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:¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-003",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/credential-revoked": {
"credential_type": "wic",
"credential_id": "serial:ABC123DEF456",
"reason": "compromise",
"event_timestamp": 1700000000
}
}
}
Event Type URI: https://schemas.openid.net/secevent/wise/event-type/credential-compromised¶
The credential-compromised 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.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-004",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/credential-compromised": {
"credential_type": "wit",
"credential_id": "jti:wit-signing-key-2024-q4",
"reason_admin": {
"en": "Private key material detected in public repository"
},
"event_timestamp": 1700000000
}
}
}
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.¶
This event reports the operational outcome of a failed renewal, which can have several causes (see failure_reason below) — the Credential Service being unreachable, a policy denial, an internal error, or a failed posture evaluation. It is distinct from posture-evaluation-failed, which reports a posture failure as a security signal in its own right. Failed posture evaluation is only one possible cause of a renewal failure, and a renewal failure is only one possible consequence of a posture failure. When a renewal fails specifically because of posture evaluation, a Transmitter emits credential-renewal-failure with failure_reason posture_evaluation_failed and MAY also emit posture-evaluation-failed, correlated using the txn claim (see Section 2.1).¶
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.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-005",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/credential-renewal-failure": {
"credential_type": "wit",
"current_expiry": 1700003600,
"failure_reason": "posture_evaluation_failed",
"event_timestamp": 1700000000
}
}
}
These events signal changes to the lifecycle state of a workload as managed by the trust domain authority.¶
Each of these events conveys only the lifecycle state change; the corresponding credential effect is carried by a separate companion event (credential-revoked or credential-issued), correlated using the txn claim as described in Section 2.1.¶
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 signaled 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:¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-010",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/workload-disabled": {
"reason": "compromise",
"event_timestamp": 1700000000
}
}
}
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 signaled separately through an accompanying credential-issued event.¶
Attributes:¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-011",
"iat": 1700003600,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/workload-enabled": {
"event_timestamp": 1700003600
}
}
}
Event Type URI: https://schemas.openid.net/secevent/wise/event-type/workload-degraded¶
The workload-degraded event signals that the trust domain authority has intentionally reduced a workload's trust level without suspending or purging it, so the workload can keep operating with fewer privileges. This supports adaptive resilience: gracefully degrading a workload (for example, revoking database write access or enforcing network quarantine) rather than executing a catastrophic shutdown during an active threat or compliance drift.¶
This event is advisory. It conveys a reduced trust level; each Receiver maps that level to concrete privilege changes according to its own policy. WISE does not prescribe the enforcement actions a Receiver takes.¶
Attributes:¶
trust_level - REQUIRED. The workload's current trust level after degradation, on a coarse graduated scale (from highest to lowest):¶
previous_trust_level - OPTIONAL. The trust level before this change, using the same scale, plus full for a workload previously at full trust. If omitted, the Receiver MUST NOT assume a particular prior level.¶
reason - OPTIONAL. Why the workload was degraded. Possible values:¶
anomaly_detected - Anomalous behavior was observed for the workload.¶
policy_drift - The workload drifted from its required policy or configuration.¶
missing_provenance - Required provenance was missing or could not be verified.¶
posture_degraded - Posture evaluation indicated a degraded but non-failing state.¶
compliance_drift - The workload drifted from a compliance requirement.¶
This event is complementary to, and does not overlap with, the related runtime and lifecycle events. anomalous-behavior-detected reports an observation (something unusual was seen) and is purely advisory; workload-degraded reports a decision by the authority to reduce trust, which may follow such an observation. workload-compromised and workload-disabled represent the fully-untrusted end of the range — a believed compromise or a suspension — whereas workload-degraded keeps the workload operational at a reduced trust level between full trust and suspension. A workload returns to full trust through workload-restored.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-013",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/workload-degraded": {
"trust_level": "restricted",
"previous_trust_level": "full",
"reason": "anomaly_detected",
"event_timestamp": 1700000000
}
}
}
Event Type URI: https://schemas.openid.net/secevent/wise/event-type/workload-restored¶
The workload-restored event signals that a previously degraded workload has been returned to full trust. It is the reverse of workload-degraded. Like workload-degraded, it is advisory: Receivers restore privileges according to their own policy.¶
Attributes:¶
previous_trust_level - OPTIONAL. The trust level the workload held before restoration (reduced, restricted, or minimal), using the scale defined for workload-degraded.¶
reason - OPTIONAL. Why trust was restored. Possible values:¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-014",
"iat": 1700003600,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/workload-restored": {
"previous_trust_level": "restricted",
"reason": "remediated",
"event_timestamp": 1700003600
}
}
}
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 signaled separately through accompanying credential-revoked events.¶
Attributes:¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-012",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/workload-purged": {
"event_timestamp": 1700000000
}
}
}
These events signal changes to the trust material and federation relationships that federated peers and relying parties use to validate workload identity credentials from a trust domain.¶
Two related lifecycles are covered, each modeled with explicit create, update, and delete events. The trust anchors (keys and CAs) that validate a trust domain's credentials are managed through trust-anchor-added, trust-anchor-rotated, and trust-anchor-revoked. The federation relationship between trust domains, which determines whether one domain accepts credentials issued by another, is managed through trust-domain-federation-established, trust-domain-federation-updated, and trust-domain-federation-revoked. Replacing an entire trust bundle in a single operation is conveyed as the corresponding set of trust-anchor-added and trust-anchor-revoked events.¶
Event Type URI: https://schemas.openid.net/secevent/wise/event-type/trust-anchor-added¶
The trust-anchor-added event signals that a new trust anchor was added for a trust domain, alongside any existing anchors. Examples include pre-staging a new signing key ahead of a rotation, or bringing online a new data center, region, or cloud provider that operates under the same trust domain. Relying parties and federated peers MUST add the new material to the set they accept for the domain.¶
Attributes:¶
anchor_type - REQUIRED. The type of trust material. Possible values:¶
trust_domain - REQUIRED. The FQDN of the trust domain the anchor belongs to.¶
key_id - OPTIONAL. Identifier of the added anchor. For JWKS, the kid value. For X.509, the certificate serial number or Subject Key Identifier.¶
key_details - OPTIONAL. A JSON object carrying selected JSON Web Key (JWK) parameters that describe the added key, so a Receiver can act (for example, recognize support for a new signature algorithm such as ECDSA alongside RSA) without fetching and comparing the bundle. The object is not itself a complete JWK. When present, key_details MUST contain kty and MAY contain alg, use, and crv. These members use the names and semantics of the corresponding JWK parameters defined in [RFC7517] and [RFC7518], and their values SHOULD be taken from the applicable JSON Object Signing and Encryption (JOSE) registries [IANA.JOSE]:¶
kty - REQUIRED. The JWK Key Type value identifying the cryptographic algorithm family used with the key (e.g., EC, RSA, OKP, or oct).¶
alg - OPTIONAL. The JWK Algorithm value identifying the algorithm intended for use with the key (e.g., RS256, ES256, or EdDSA).¶
use - OPTIONAL. The JWK Public Key Use value identifying the intended use of the public key (e.g., sig or enc).¶
crv - OPTIONAL. The JWK Curve value identifying the cryptographic curve used with an EC or OKP key (e.g., P-256 or Ed25519). This member is applicable only to key types for which a crv parameter is defined.¶
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.¶
reason - OPTIONAL. Why the anchor was added. Possible values:¶
new_environment - A new environment (data center, region, or cloud provider) under the same trust domain was brought online.¶
additional_key - An additional concurrent anchor was introduced (for example, to support a new signature algorithm alongside an existing one).¶
scheduled_rotation - A new key was pre-staged ahead of a scheduled rotation.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-020",
"iat": 1700000000,
"aud": "https://federation-peer.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/trust-anchor-added": {
"anchor_type": "jwks",
"trust_domain": "trust.example.com",
"jwks_uri": "https://authority.example.com/.well-known/jwks.json",
"key_id": "kid:ecdsa-2026",
"key_details": {
"kty": "EC",
"alg": "ES256",
"use": "sig",
"crv": "P-256"
},
"effective_at": 1700000000,
"reason": "additional_key",
"event_timestamp": 1700000000
}
}
}
Event Type URI: https://schemas.openid.net/secevent/wise/event-type/trust-anchor-rotated¶
The trust-anchor-rotated event signals that an existing trust anchor for a trust domain was replaced by new material. Relying parties and federated peers MUST begin accepting the new anchor and SHOULD stop accepting the previous one once any grace period ends.¶
Attributes:¶
anchor_type - REQUIRED. The type of trust material. Same values as in Section 2.6.1.¶
trust_domain - REQUIRED. The FQDN of the trust domain whose anchor was rotated.¶
previous_key_id - OPTIONAL. Identifier of the anchor being replaced.¶
new_key_id - OPTIONAL. Identifier of the replacement anchor.¶
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.¶
old_material_expiry - OPTIONAL. When the previous material ceases to be valid (grace period end). JSON number (NumericDate).¶
reason - OPTIONAL. Why the rotation occurred. Possible values:¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-021",
"iat": 1700000000,
"aud": "https://federation-peer.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/trust-anchor-rotated": {
"anchor_type": "jwks",
"trust_domain": "trust.example.com",
"previous_key_id": "kid:signing-2024-q4",
"new_key_id": "kid:signing-2025-q1",
"jwks_uri": "https://authority.example.com/.well-known/jwks.json",
"effective_at": 1700000000,
"old_material_expiry": 1700604800,
"reason": "scheduled_rotation",
"event_timestamp": 1700000000
}
}
}
Event Type URI: https://schemas.openid.net/secevent/wise/event-type/trust-anchor-revoked¶
The trust-anchor-revoked event signals that a trust anchor for a trust domain was withdrawn and MUST no longer be used to validate credentials. This covers both explicit revocation (for example, a compromised CA) and removal of an anchor that has reached end of life.¶
Attributes:¶
anchor_type - REQUIRED. The type of trust material. Same values as in Section 2.6.1.¶
trust_domain - REQUIRED. The FQDN of the trust domain whose anchor was revoked.¶
key_id - OPTIONAL. Identifier of the revoked anchor. For JWKS, the kid value. For X.509, the certificate serial number or Subject Key Identifier.¶
jwks_uri - OPTIONAL. When anchor_type is jwks, the URI to fetch the JWK Set reflecting the removal.¶
x509_bundle_uri - OPTIONAL. When anchor_type is x509_ca, the URI to fetch the CA bundle reflecting the removal.¶
reason - OPTIONAL. Why the anchor was revoked. Possible values:¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-022",
"iat": 1700000000,
"aud": "https://federation-peer.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/trust-anchor-revoked": {
"anchor_type": "x509_ca",
"trust_domain": "trust.example.com",
"key_id": "serial:CA-ROOT-2023-001",
"reason": "compromise",
"event_timestamp": 1700000000
}
}
}
Event Type URI: https://schemas.openid.net/secevent/wise/event-type/trust-domain-federation-established¶
The trust-domain-federation-established event signals that a new trust domain has been federated. Relying parties and federated peers MAY begin accepting workload credentials originating from the specified trust domain, validated against the associated trust anchors. This is the counterpart to trust-domain-federation-revoked, and typically accompanies the trust material for the new domain (either inline via jwks_uri / x509_bundle_uri or through subsequent trust-anchor-added events).¶
Attributes:¶
trust_domain - REQUIRED. The FQDN of the newly federated trust domain.¶
anchor_type - OPTIONAL. The type of trust material used to validate credentials from the new domain. Same values as in Section 2.6.1: x509_ca or jwks.¶
jwks_uri - OPTIONAL. When anchor_type is jwks, the URI to fetch the JWK Set [RFC7517] for the federated domain.¶
x509_bundle_uri - OPTIONAL. When anchor_type is x509_ca, the URI to fetch the CA bundle for the federated domain.¶
reason - OPTIONAL. Why federation was established. Possible values:¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-023",
"iat": 1700000000,
"aud": "https://federation-peer.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://newpartner.example.org"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/trust-domain-federation-established": {
"trust_domain": "newpartner.example.org",
"anchor_type": "jwks",
"jwks_uri": "https://authority.newpartner.example.org/.well-known/jwks.json",
"effective_at": 1700000000,
"reason": "onboarding",
"event_timestamp": 1700000000
}
}
}
Event Type URI: https://schemas.openid.net/secevent/wise/event-type/trust-domain-federation-updated¶
The trust-domain-federation-updated event signals that the terms of an existing federation with a trust domain changed without revoking it. Examples include a change to the set of workloads or name constraints that are trusted, or a change to which trust anchors validate the federated domain. Relying parties MUST update their federation configuration accordingly while continuing to trust the domain.¶
Attributes:¶
trust_domain - REQUIRED. The FQDN of the federated trust domain whose federation terms changed.¶
reason - OPTIONAL. Why the federation was updated. Possible values:¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-024",
"iat": 1700000000,
"aud": "https://federation-peer.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://newpartner.example.org"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/trust-domain-federation-updated": {
"trust_domain": "newpartner.example.org",
"reason": "anchor_update",
"effective_at": 1700000000,
"event_timestamp": 1700000000
}
}
}
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:¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-025",
"iat": 1700000000,
"aud": "https://federation-peer.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://partner.example.org"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/trust-domain-federation-revoked": {
"trust_domain": "partner.example.org",
"reason": "administrative",
"effective_at": 1700604800,
"event_timestamp": 1700000000
}
}
}
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.¶
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.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-050",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/issuance-policy-changed": {
"policy_id": "policy:issuance-v3",
"effective_at": 1700000000,
"event_timestamp": 1700000000
}
}
}
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.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-051",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/posture-evaluation-policy-changed": {
"policy_id": "policy:posture-eval-v2",
"effective_at": 1700000000,
"event_timestamp": 1700000000
}
}
}
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.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-052",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/validation-policy-changed": {
"policy_id": "policy:validation-v5",
"effective_at": 1700000000,
"event_timestamp": 1700000000
}
}
}
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.¶
Posture evaluation is a security-critical checkpoint, so its failure warrants a dedicated event rather than being buried inside another outcome. It may occur at initial issuance, at renewal, or during continuous re-evaluation, and this event reports the posture failure itself independently of any particular credential operation. A posture failure does not necessarily cause a credential-renewal-failure (for example, it may occur outside a renewal), and a credential-renewal-failure may occur for reasons unrelated to posture. When a renewal fails because of posture evaluation, the two events are emitted together and correlated using the txn claim (see Section 2.1).¶
Attributes:¶
evaluation_type - OPTIONAL. The scope of evaluation that failed. Possible values:¶
reason - OPTIONAL. Why the evaluation failed. Possible values:¶
platform_integrity_failed - Platform integrity or TEE verification did not pass.¶
attestation_invalid - Attestation evidence was missing, malformed, or could not be verified.¶
image_mismatch - The workload's binary or image did not match the expected measurement.¶
configuration_noncompliant - The runtime configuration did not meet policy.¶
policy_denied - Posture evaluation policy denied the workload.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-053",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/posture-evaluation-failed": {
"evaluation_type": "platform",
"reason": "platform_integrity_failed",
"event_timestamp": 1700000000
}
}
}
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.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-054",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/posture-evaluation-succeeded": {
"evaluation_type": "workload",
"event_timestamp": 1700000000
}
}
}
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. A JSON object describing the prior runtime environment. See the guidance below on the interoperable key set and on limiting sensitive detail.¶
current_context - OPTIONAL. A JSON object describing the new runtime environment, using the same keys as previous_context so the two can be compared.¶
posture_evaluation_status - OPTIONAL. Whether posture re-evaluation has occurred. Possible values:¶
For interoperability, when previous_context or current_context is present it MAY include the following keys. Each is OPTIONAL, because the corresponding notion may not exist in every deployment:¶
region - The geographic or cloud region.¶
zone - The availability or fault-isolation zone.¶
platform - The runtime platform type (for example, kubernetes, ecs, vm, or serverless).¶
cluster - An identifier for the orchestration cluster or scheduling domain.¶
image - A reference or digest for the workload image or binary.¶
This set is the minimum interoperable capability: where a Receiver understands these keys, it can compare the prior and new environment without prior agreement. Both objects SHOULD use the same keys so they can be compared. The schema MAY be extended with additional deployment- or profile-specific topology information where a Transmitter sees fit; in that case the Transmitter is responsible for ensuring the Receiver can understand the added fields, and how such understanding is established is out of scope for this profile.¶
These fields can reveal workload infrastructure topology; see Section 5 for guidance on limiting the detail disclosed.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-030",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/workload-baseline-changed": {
"reason": "migration",
"previous_context": {
"region": "us-east-1",
"platform": "kubernetes"
},
"current_context": {
"region": "eu-west-1",
"platform": "kubernetes"
},
"posture_evaluation_status": "succeeded",
"event_timestamp": 1700000000
}
}
}
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. Where the Transmitter is also the credential authority for the workload, it SHOULD emit an accompanying credential-revoked event (with reason compromise), correlated using the txn claim as described in Section 2.1.¶
Attributes:¶
detection_method - OPTIONAL. How the compromise was detected.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-060",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/workload-compromised": {
"detection_method": "runtime-anomaly-detection",
"event_timestamp": 1700000000
}
}
}
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:¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-061",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/anomalous-behavior-detected": {
"anomaly_type": "unexpected-egress",
"severity": "medium",
"event_timestamp": 1700000000
}
}
}
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.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-040",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/workload-provenance-changed": {
"change_type": "revoked",
"provenance_uri": "https://provenance.example.com/payment-service/attestation",
"reason_admin": {
"en": "Build provenance attestation revoked by source repository owner"
},
"event_timestamp": 1700000000
}
}
}
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 prioritize. Possible values: low, medium, high, critical.¶
advisory_uri - OPTIONAL. A URI at which a full advisory or VEX statement can be retrieved.¶
The following example is non-normative.¶
{
"iss": "https://authority.example.com/",
"jti": "wise-evt-041",
"iat": 1700000000,
"aud": "https://rp.partner.example.net/wise",
"sub_id": {
"format": "uri",
"uri": "wimse://trust.example.com/workload/payment-service"
},
"events": {
"https://schemas.openid.net/secevent/wise/event-type/workload-vulnerability-status-changed": {
"vulnerability_id": "CVE-2026-12345",
"status": "affected",
"severity": "critical",
"advisory_uri": "https://advisories.example.com/CVE-2026-12345",
"event_timestamp": 1700000000
}
}
}
Following the Shared Signals Framework [SSF], every WISE event conveys its subject in a top-level sub_id claim — a sibling of iss, jti, iat, aud, and events, not a member of the event-specific payload. The value of sub_id is a Subject Identifier as defined in [RFC9493]. WISE uses the uri format, carrying a Workload Identifier expressed as a URI following [WIMSE-ID].¶
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"
}
¶
Deployments identifying workloads primarily by their immutable cryptographic artifacts, such as a compiled binary hash or container image digest, MAY express the workload subject using the Named Information (ni) URI scheme defined in [RFC6920]. This lets relying parties cryptographically bind security events directly to a workload's build provenance or artifact registry digest, and is particularly useful for supply-chain events and for external monitoring or intelligence platforms that key off artifact hashes rather than the full trust-domain context.¶
A digest identifies an artifact — and therefore potentially every instance built from it — rather than a single running workload or its Workload Identifier. The ni form is therefore best suited to artifact-scoped signals and as a correlation aid; the Workload Identifier uri form remains the primary subject for per-workload and credential events.¶
The following example is non-normative.¶
{
"format": "uri",
"uri": "ni://trust.example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk"
}
¶
For events that apply to an entire trust domain rather than to a single workload — the trust-anchor-* and trust-domain-federation-* events, and the policy events (issuance-policy-changed, posture-evaluation-policy-changed, validation-policy-changed) — the sub_id 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"
}
¶
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.¶
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.¶
Several WISE events indicate that a credential, key, trust anchor, federation, or workload can no longer be trusted. This is signaled either by an event whose purpose is to report compromise (credential-compromised, workload-compromised) or by any event carrying a reason of compromise or key_compromise. Upon receiving any such event — regardless of event type, including events defined by future revisions or profiling specifications — Receivers SHOULD take immediate action appropriate to the affected object (for example, reject the affected credentials, keys, or trust material, or isolate the affected workload) without waiting for additional confirmation.¶
Events in this document that carry such a signal include credential-compromised; credential-revoked (with reason compromise or key_compromise); trust-anchor-rotated and trust-anchor-revoked (with reason compromise); trust-domain-federation-revoked (with reason compromise); workload-disabled (with reason compromise); and workload-compromised.¶
Rejecting credentials only takes effect at the next credential check or proof-of-possession step; neither short credential lifetime nor condition-liveness severs a connection that is already established. A Receiver that holds active connections with, or is actively serving, the affected workload SHOULD therefore also terminate those connections rather than waiting for the next operation. This is best-effort and applies to Receivers, such as gateways or service mesh components, that are able to correlate the workload identifier to live connections.¶
Deployments use different mechanisms to limit the exposure window of a compromised or deprovisioned workload:¶
Issuer-side status signaling, 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 signaling 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.¶
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.¶
Several fields in this specification carry free-form or descriptive values — for example key_storage_ecosystem on credential-issued, and previous_context / current_context on workload-baseline-changed. Such fields can inadvertently disclose fine-grained infrastructure or device detail, such as node or host names, IP addresses, internal network identifiers, device models, or software versions. For any such field, a Transmitter SHOULD avoid including detail beyond what the Receiver needs, based on its own evaluation of the privacy risk, particularly for events that may cross a trust-domain boundary. For example, a coarse region is preferable to a specific node or host name.¶
Events SHOULD NOT include personally identifiable information. Workload identifiers SHOULD NOT encode information about the humans who manage or operate the workloads.¶
This document requests IANA to establish a new registry titled "WISE Event Types". This registry records the Security Event Token (SET) event types defined by the WISE profile and by future extensions, so that such extensions are discoverable and their identifiers do not collide.¶
The full Event Type URI of a registered entry is formed by appending its registered Event Type value to the WISE event type base URI:¶
https://schemas.openid.net/secevent/wise/event-type/¶
Registration follows the Specification Required policy defined in Section 4.6 of [RFC8126]. The Designated Expert verifies that a registration references a permanent, publicly available specification, that the Event Type value is unique within the registry and consists of lowercase ASCII letters, digits, and hyphens, and that its meaning does not overlap an existing entry.¶
Each entry has the following fields:¶
Event Type: The path segment appended to the base URI to form the full Event Type URI.¶
Description: A brief description of the event type.¶
Change Controller: For entries in this document, the OpenID Foundation. For other entries, the party responsible for the registration.¶
Reference: The specification defining the event type.¶
The Change Controller for every entry below is the OpenID Foundation, and the Reference for every entry is this document. IANA is requested to register the following Event Type values:¶
credential-issued¶
A new credential was issued to a workload.¶
credential-rotated¶
A workload's credential was rotated.¶
credential-revoked¶
A workload's credential was revoked before its natural expiry.¶
credential-compromised¶
A workload credential is believed to be compromised.¶
credential-renewal-failure¶
Renewal of a workload's credential failed.¶
workload-disabled¶
A workload was suspended by the trust domain authority.¶
workload-enabled¶
A previously disabled workload is active again.¶
workload-purged¶
A workload was permanently removed from the trust domain.¶
workload-degraded¶
A workload's trust level was intentionally reduced without suspending it.¶
workload-restored¶
A previously degraded workload was returned to full trust.¶
trust-anchor-added¶
A new trust anchor was added for a trust domain.¶
trust-anchor-rotated¶
An existing trust anchor was replaced.¶
trust-anchor-revoked¶
A trust anchor was withdrawn and must no longer be used.¶
trust-domain-federation-established¶
A new trust domain was federated.¶
trust-domain-federation-updated¶
The terms of an existing federation changed.¶
trust-domain-federation-revoked¶
A previously federated trust domain is no longer trusted.¶
issuance-policy-changed¶
The credential issuance policy changed.¶
posture-evaluation-policy-changed¶
The posture evaluation policy changed.¶
validation-policy-changed¶
The credential validation policy changed.¶
posture-evaluation-failed¶
A workload did not pass posture evaluation.¶
posture-evaluation-succeeded¶
A workload passed posture evaluation.¶
workload-baseline-changed¶
A workload's runtime environment or deployment context changed.¶
workload-compromised¶
A workload is believed to be compromised based on runtime detection.¶
anomalous-behavior-detected¶
Unusual behavior was observed for a workload.¶
workload-provenance-changed¶
The provenance of a workload changed.¶
workload-vulnerability-status-changed¶
The vulnerability status of a workload changed.¶
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.¶
The authors want to recognize the contributions and reviews of the following individuals (in alphabetical order):¶
-03¶
Updated the WIMSE Architecture, AIMS, and OAuth Client ID Metadata Document references to their current rolling Internet-Draft URLs and author metadata.¶
Standardized the draft on American English spelling.¶
Made effective_at a Common Optional Claim available to any WISE event, removed the redundant per-event definitions, and clarified that, when omitted, a change is effective as of the containing SET's iat value and is processed immediately upon receipt.¶
Made event_timestamp a Common Mandatory Claim, removed the redundant per-event definitions, and updated all event examples to include it.¶
Completed the trust and federation lifecycle. Split the omnibus trust-anchor-changed event into explicit trust-anchor-added, trust-anchor-rotated, and trust-anchor-revoked events, and added trust-domain-federation-established and trust-domain-federation-updated to complement trust-domain-federation-revoked.¶
Added an optional key_details object using the standard JWK parameter names kty, alg, use, and crv, with values from the applicable JOSE registries, to trust-anchor-added, supporting the addition of a new algorithm (e.g., ECDSA alongside RSA) without rotation.¶
Added an informative reference for condition-bounded credentials and cited it in the credential freshness models discussion.¶
Corrected the description of condition-liveness to state that it removes (rather than reduces) the local deprovisioning window for conditions the endpoint can evaluate itself.¶
Noted in Compromise Response that credential rejection only takes effect at the next operation, so Receivers holding active connections with an affected workload should also terminate them (best-effort).¶
Added a general "Correlating Related Events" rule: a Transmitter SHOULD set a shared txn claim across all SETs describing one underlying occurrence, regardless of event type (replacing the per-event guidance). Added conditional pairing guidance to workload-compromised.¶
Generalized the Compromise Response rule to apply to any event carrying a compromise or key_compromise signal, rather than an enumerated list of event types.¶
Defined a minimal interoperable key set (region, zone, platform, cluster, image, each optional) for the previous_context/current_context fields of workload-baseline-changed, and allowed profile-specific extension.¶
Expanded the key_storage values on credential-issued from the binary hardware/software to software, software_encrypted, hardware_tpm, hardware_hsm, hardware_secure_enclave, vaulted, and unknown, so a Receiver can distinguish key-protection strength when making a trust decision.¶
Added a single Privacy Considerations note covering over-disclosure in all free-form/descriptive fields (key_storage_ecosystem, previous_context, current_context), replacing per-field guidance.¶
Clarified the distinction between credential-renewal-failure (operational outcome, multiple causes) and posture-evaluation-failed (a security-critical signal in its own right), and how the two relate when posture is the cause of a renewal failure.¶
Made reason_admin/reason_user usage consistent: removed the redundant per-event listings and rely on the Common Optional Claims section, which now states the claims are not repeated per event and any event MAY carry them.¶
Replaced the free-text reason on posture-evaluation-failed with an enum (platform_integrity_failed, attestation_invalid, image_mismatch, configuration_noncompliant, policy_denied), matching the enum style of sibling events.¶
Renamed the credential-compromise event to credential-compromised for tense consistency with the other credential events (-issued, -rotated, -revoked) and workload-compromised.¶
Added a non-normative example to every event that lacked one, so all event types now have consistent example coverage (and confirmed policy events use the trust-domain subject).¶
Established a "WISE Event Types" IANA registry (Specification Required) with all defined event types as initial registrations, replacing the "no new registrations" statement.¶
Added workload-degraded and workload-restored events for adaptive resilience: an advisory, coarse graduated trust_level signal for intentionally reducing a workload's trust without suspension, and its reverse. Clarified their complementarity with anomalous-behavior-detected, workload-compromised, and workload-disabled.¶
Added the Named Information (ni) URI scheme (RFC 6920) as an optional subject identifier for identifying workloads by build/image digest, with a note that a digest identifies an artifact rather than a single workload instance.¶
Replaced the free-form change_description field on trust-domain-federation-updated and the policy-change events with the localizable reason_admin/reason_user common claims, for consistency with the CAEP-aligned pattern.¶
Carried the subject in the top-level sub_id claim (RFC 9493 format, per SSF) instead of a nonstandard nested subject member, updating every example; and specified that policy events take the trust-domain subject.¶
-02¶
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.¶