Handling comment from reviewers by identitymonk · Pull Request #18 · openid/ssf-wise-profile

identitymonk · 2026-07-28T14:30:22Z

handling Is a trust-anchor-added or trust-anchor-issued event needed? #17

identitymonk · 2026-07-28T14:58:18Z

Second commit is about openid/sharedsignals#345

identitymonk · 2026-07-28T16:24:42Z

Las t commit handle comments from openid/sharedsignals#344

identitymonk · 2026-07-29T12:12:36Z

last commit is solving #22

identitymonk · 2026-07-29T12:19:04Z

Last commit solves #23

@appdesh

…torage for broader usecases (#19) Contribution from @appdesh

PieterKas · 2026-09-14T15:10:51Z

+        name: Sergei Nikitin
+      - ins: J. O'Leary
+        name: John O'Leary
+    date: 2026


Remove reference to this draft. It is not an official WIMSE document. Taking a dependency on a document that is not working group adopted, nor received much in terms of support is inappropriate at this point.

Suggested change

date: 2026

PieterKas · 2026-09-14T15:11:09Z

    target: https://www.cisa.gov/resources-tools/resources/minimum-requirements-vulnerability-exploitability-exchange-vex
    date: 2023
+  WIMSE-CBC:
+    title: "Condition-Bounded Credentials for Workload and Agent Identity: Non-Exfiltratable Keys and Validity by Presence"


Suggested change

title: "Condition-Bounded Credentials for Workload and Agent Identity: Non-Exfiltratable Keys and Validity by Presence"

PieterKas · 2026-09-14T15:11:15Z

    date: 2023
+  WIMSE-CBC:
+    title: "Condition-Bounded Credentials for Workload and Agent Identity: Non-Exfiltratable Keys and Validity by Presence"
+    target: https://datatracker.ietf.org/doc/draft-winmagic-wimse-condition-bounded-credentials/


Suggested change

target: https://datatracker.ietf.org/doc/draft-winmagic-wimse-condition-bounded-credentials/

PieterKas · 2026-09-14T15:11:20Z

+  WIMSE-CBC:
+    title: "Condition-Bounded Credentials for Workload and Agent Identity: Non-Exfiltratable Keys and Validity by Presence"
+    target: https://datatracker.ietf.org/doc/draft-winmagic-wimse-condition-bounded-credentials/
+    author:


Suggested change

author:

PieterKas · 2026-09-14T15:11:26Z

+    title: "Condition-Bounded Credentials for Workload and Agent Identity: Non-Exfiltratable Keys and Validity by Presence"
+    target: https://datatracker.ietf.org/doc/draft-winmagic-wimse-condition-bounded-credentials/
+    author:
+      - ins: T. Nguyen-Huu


Suggested change

- ins: T. Nguyen-Huu

PieterKas · 2026-09-14T15:11:32Z

+    target: https://datatracker.ietf.org/doc/draft-winmagic-wimse-condition-bounded-credentials/
+    author:
+      - ins: T. Nguyen-Huu
+        name: Thi Nguyen-Huu


Suggested change

name: Thi Nguyen-Huu

PieterKas · 2026-09-14T15:11:37Z

+    author:
+      - ins: T. Nguyen-Huu
+        name: Thi Nguyen-Huu
+      - ins: S. Nikitin


Suggested change

- ins: S. Nikitin

PieterKas · 2026-09-14T15:11:42Z

+      - ins: T. Nguyen-Huu
+        name: Thi Nguyen-Huu
+      - ins: S. Nikitin
+        name: Sergei Nikitin


Suggested change

name: Sergei Nikitin

PieterKas · 2026-09-14T15:11:47Z

+        name: Thi Nguyen-Huu
+      - ins: S. Nikitin
+        name: Sergei Nikitin
+      - ins: J. O'Leary


Suggested change

- ins: J. O'Leary

PieterKas · 2026-09-14T15:11:52Z

+      - ins: S. Nikitin
+        name: Sergei Nikitin
+      - ins: J. O'Leary
+        name: John O'Leary


Suggested change

name: John O'Leary

PieterKas · 2026-09-14T15:11:56Z

+        name: Sergei Nikitin
+      - ins: J. O'Leary
+        name: John O'Leary
+    date: 2026


Suggested change

date: 2026

PieterKas · 2026-09-14T15:45:46Z

 - Issuer-side status signalling, where the trust domain authority communicates lifecycle changes to relying parties through an event channel. The events defined in this specification serve this purpose.
 - Short credential lifetime, where the remaining validity period bounds the exposure window. In the WIMSE model, credentials are intentionally short-lived to force posture evaluation before re-issuance.
- Condition-liveness, where a locally observable condition (hardware release policy, TEE state, platform integrity measurement) gates each key operation. Failure of the condition prevents the next presentation or handshake step without requiring a remote signal.
+- Condition-liveness, as realised by condition-bounded credentials {{WIMSE-CBC}}, 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.


This can be misread as an endorsement of a WIMSE spec that has not received working group review, support or adoption..

Suggested change

- Condition-liveness, as realised by condition-bounded credentials {{WIMSE-CBC}}, 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.

- 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.

PieterKas · 2026-09-14T15:48:02Z

+- Condition-liveness, as realised by condition-bounded credentials {{WIMSE-CBC}}, where a locally observable condition (hardware release policy, TEE state, platform integrity measurement) gates each key operation. Failure of the condition prevents the next presentation or handshake step without requiring a remote signal.

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


This can be misread as an endorsement of a WIMSE spec that has not received working group review, support or adoption.

Suggested change

These mechanisms are complementary, not mutually exclusive. Condition-bounded credentials {{WIMSE-CBC}} remove the local deprovisioning window for conditions the endpoint can evaluate itself, 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.

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.

PieterKas · 2026-09-14T15:49:33Z

    title: "Minimum Requirements for Vulnerability Exploitability eXchange (VEX)"
    target: https://www.cisa.gov/resources-tools/resources/minimum-requirements-vulnerability-exploitability-exchange-vex
    date: 2023
+  WIMSE-CBC:


Suggested change

WIMSE-CBC:

PieterKas · 2026-09-14T15:57:51Z


+## Correlating Related Events {#correlating-related-events}
+
+A single underlying occurrence may cause a Transmitter to emit more than one SET — for example, a lifecycle change and its companion credential event, a runtime compromise and a resulting credential revocation, a posture failure and a resulting renewal failure, or a new federation and the trust anchors that accompany it. When a Transmitter emits multiple SETs that describe the same underlying occurrence, it SHOULD set the same value in the OPTIONAL `txn` (transaction identifier) claim {{RFC8417}} on each of them, so that a Receiver can recognise that the events share a cause. This applies regardless of event type.


I struggled parsing this on the first read - perhaps a rephrase may help?

Suggested change

A single underlying occurrence may cause a Transmitter to emit more than one SET — for example, a lifecycle change and its companion credential event, a runtime compromise and a resulting credential revocation, a posture failure and a resulting renewal failure, or a new federation and the trust anchors that accompany it. When a Transmitter emits multiple SETs that describe the same underlying occurrence, it SHOULD set the same value in the OPTIONAL `txn` (transaction identifier) claim {{RFC8417}} on each of them, so that a Receiver can recognise that the events share a cause. This applies regardless of event type.

A single underlying occurrence may cause a Transmitter to emit more than one SET. For example, when a workload is disabled, the Transmitter emits a `workload-disabled` event together with an accompanying `credential-revoked` event for each credential the disablement invalidates.

A Transmitter SHOULD set the same value in the OPTIONAL `txn` (transaction identifier) claim {{RFC8417}} on all SETs arising from the same occurrence, whatever their event types, so that a Receiver can recognise that they share a cause.

yes, sorry it was supposed to be cleaned before I asked for your review. I had the same stance on this. It comes from a loose merging of the other PR proposal into this one

PieterKas

Overall looks good with one major recommendation (remove WIMSE-CBC dependency) and some minor ones (combine otwo of the events as status change) and some text changes.

dagdagdag83

Misc suggestions

dagdagdag83 · 2026-09-17T13:43:15Z

+    - `type` - The key type, using a value from the "JSON Web Key Types" registry (e.g., `EC`, `RSA`, `OKP`, `oct`).
+    - `name` - The algorithm, using an "Algorithm Name" from the "JSON Web Signature and Encryption Algorithms" registry (e.g., `RS256`, `ES256`, `EdDSA`).
+    - `use` - The public key use, using a value from the "JSON Web Key Use" registry (e.g., `sig`, `enc`).


Should these not follow names defined in RFC 7517 and RFC 7518?

Standard parameter names are: kty (Key Type), alg (Algorithm), use (Public Key Use) and optional crv (Curve for EC/OKP keys, e.g., P-256, Ed25519).

Add the Refrences into Informative

dagdagdag83 · 2026-09-17T13:47:04Z

+    - `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.
+- **event_timestamp** - OPTIONAL. Time the degradation took effect.


The claim event_timestamp is duplicated across all event definitions.

I suggest we move this to section 2.2, as I think there are only subtle differences between how the event is described in each event, and I think these can be inferred from the event context.

PS: This change isn't only related to this line, but for simplicity sake I only add it here once.

Agreed. Would be a global attribute and then the definition would be "Time the event took detected."

dagdagdag83 · 2026-09-17T13:51:22Z

-    - `compromise` - A key or CA is believed compromised.
-    - `policy_change` - Changed due to updated security policy.
-    - `expiry` - Proactive rotation before scheduled expiry.
+- **effective_at** - OPTIONAL. When the new anchor becomes active. JSON number (NumericDate).


We are introducing the claim effective_at to several events in this MR (Trust Anchor, Federation, and Policy events). The claim is optional, which can lead to confusion as to what it means when it's missing.

My suggestion is to add to section 2.2, something like: "If effective_at is omitted, the change MUST be treated as effective immediately upon receipt (or from iat)."

Ok and move it as a Global OPTIONAL attribute

… adopted by WIMSE WG

…nsure RFC 7518 is referenced correctly in the document

handling openid-wise/issues/17

454428b

identitymonk marked this pull request as draft July 28, 2026 14:30

Handling issue sharedsignals/issues/345

556bcc3

handling Tom Sato and sharedsignals/issues/344 feedback

ab74d7d

Jeff Lombardo added 11 commits July 28, 2026 16:56

correlation is under-generalized.

5c1709a

Subject carried as nested , not SSF top-level .

4ed2227

Subject carried as nested , not SSF top-level

1677341

free-text is the same over-disclosure risk as the context fields

95494be

uses a free-text reason and overlaps

09e5493

reason_user and reason_admin as global parameter

4cd6c78

is using enum for reason

01f83ef

moved to credential-compromised for consistency in nanming

e2998fa

uneven examples coverage remediation

ce788d3

IANA registry

116e8a4

New event and

8f82c9e

add support for build/image digest

6718a74

appsdesh and others added 2 commits July 29, 2026 14:21

Additional values for key_storage enum - Expanding the enum for key_s…

b0667f4

…torage for broader usecases (#19) Contribution from @appdesh

add recognition

4261c0b

identitymonk changed the title ~~Hsandling comment from reviewers~~ Handling comment from reviewers Aug 20, 2026

identitymonk requested review from PieterKas, dag-dendro and iamseanodentity September 10, 2026 13:49

identitymonk marked this pull request as ready for review September 10, 2026 13:49