[WIMSE] Re: Condition-bounded credential profile for WIMSE — no rotation, no cert lifecycle

[Thi Nguyen-Huu <[e-mail]>]

Karthik, Songbo, all,

To Morgan on the weekend I said I would state the possession-side rows in Songbo's template, and here they are.

The possession row is one of four that belong together. Possession is what a verifier checks, but it is not self-supporting: Row 1 says why the key means anything; Row 3 says why its continued existence is an assertion and not an assumption; Row 4 says what happens when the condition is decided somewhere the endpoint cannot see. Together they are one substrate — they establish who is present and sound, and they authorize nothing. Rows five through seven authorize, join on the action digest per Songbo's framing, and no row inherits another's guarantees.
Row 2 is stated below for continuity with the three that surround it. Where it differs from the reconciled text you have already recorded, yours stands.

Row 1 — Enrollment binding (key, actor, workload, environment).
Claim: this key was built inside this hardware anchor, for this actor and workload, with the required conditions as inputs to the build — the key exists, therefore the inputs existed at mint.
Carrier: attestation evidence at enrollment; the platform key endorsed, the public key registered with the verifier — as a raw public key (RFC 7250) or in a certificate where one is wanted.
Verifier and rule: the credential service appraises the attestation at issuance and pins the key. The binding is proven by attestation, not asserted by the workload.
Binding and freshness: established at mint; re-appraisal per policy. Attestation proves construction and custody at mint — it does not prove future soundness. That is Rows 2–4.
Failure behavior: failed appraisal, no enrollment; nothing exists to present later.
Dependency: the hardware anchor (TPM, secure element, vTPM) and its endorsement chain.
Evidence: the attestation record at enrollment.

Row 2 — Live key possession at connection.
Claim: the presenter on this connection holds and can use the enrolled key now. The key exists in exactly one place; validity is the successful use.
Carrier: the mTLS handshake itself. No new wire format.
Verifier and rule: standard TLS client authentication against the enrolled key.
Binding and freshness: fresh per handshake, channel-bound; nothing bearer, nothing replayable.
Failure behavior: key absent or unusable, the handshake fails. Fails closed with no signal.
Dependency: Row 1 for what the key means. Nothing else — this row leans on no other row.
Evidence: the connection itself; none retained, by design. Durable evidence of a decision is Row 7's job, not this row's.

Row 3 — Local condition failure / key unavailability.
Claim: the key's continued existence is itself the assertion that the mint conditions still hold. When a locally visible condition fails — the user departs, posture drops, protection is disabled in place, the workload ends — the platform erases the key in real time.
Carrier: none. Absence is the carrier; no message is sent.
Verifier and rule: the verifier observes nothing except that Row 2 stops succeeding. There is nothing to fetch and no list to distribute.
Binding and freshness: real-time at the endpoint; enforcement lands at the key's next use. An established connection can outlive a mid-session failure — bounding connection lifetime is the fix, and it is the same fix rotation needs for the same gap.
Failure behavior: fail-stop by absence. Zero-message revocation for the locally visible class.
Dependency: Row 1's anchor, and the property that the key is available nowhere else — hardware holds that property for the key's life; software holds it only briefly.
Evidence: none, by design; the diagnostic is possession ceasing. The condition inputs are software-observed posture readings feeding hardware-held keys — deterministic cryptography on sensor-grade inputs, stated here so the cell is honest.

Row 4 — External lifecycle events.
Claim: conditions decided where the endpoint cannot see them — a role removed, a workload no longer trusted, quarantine, retirement — are carried as an event to the platform, which erases the key. An external decision becomes Row 3's local absence: one event per device, and the fan-out to relying parties happens by absence rather than by notification.
Carrier: a continuous-evaluation event (CAEP / Shared Signals); one event type, aligned with the naming in Iman's drafts.
Verifier and rule: the relying party's check remains Row 2; nothing is distributed per relying party.
Binding and freshness: bound at delivery. Where the device is unreachable, the key's liveness requirement fails closed — no re-assessment within the window, no key.
Failure behavior: fail closed on non-delivery.
Dependency: a signals channel to the platform, and Row 3's erasure mechanism.
Evidence: the event record at the transmitter.
Two seams to the authorizing rows, offered rather than claimed: Row 2 is the possession dependency the mapping's R4 names, and the endpoint platform is a candidate for the trusted display surface Row 7's rendering residual asks for. Test vectors for Rows 2 and 3 to follow to the list.

Cheers

Thi

From: KARTHIK RAMPALLI <[e-mail]>
Sent: Monday, July 6, 2026 6:13 AM
To: Thi Nguyen-Huu <[e-mail]>
Cc: Songbo Bu <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [WIMSE] Re: Condition-bounded credential profile for WIMSE — no rotation, no cert lifecycle

CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.

Thi, Songbo, all:

Reconciled row is in, verbatim, and -05 is posted. Section 3.3 now carries it as reconciled, including the relying-party-acceptance non-claim Songbo asked to keep explicit and the key-agreement-versus-connection granularity distinction, which is the sharpest freshness statement on the list. The workload-path negative vector is recorded in the evidence cell in the shape the thread set, so when it publishes it drops in as this row's analogue to the composition negative the root layer already ships.

Two composition-section additions come with it. Application acceptance now sits as a separate relying-party input alongside the rows, which is where the final conjunctive verdict lives. And the three cross-row boundaries this list produced are recorded together as one discipline: presence versus approval, attribution versus approval, may versus did, all the same shape, same action digest, different claims, independent failure. That paragraph is the reason the rows can be conjunctive in the final decision without inheriting each other's guarantees, and it is now in the document rather than only in the threads.

With this, every row of the composed stack is stated and reconciled by its supplier. Thank you both.

Karthik Rampalli
Glyphzero, Inc.

On Mon, Jul 6, 2026 at 7:04 PM Thi Nguyen-Huu <[e-mail]<mailto:[e-mail]>> wrote:
All,

Confirming the reconciled possession row (Nguyen-Huu / Bu) that Songbo put on-list. I've folded in the one boundary he asked to keep explicit — relying-party acceptance stays separate from possession — directly in the Claim, so nothing further is needed to carry it. Songbo, if you'd word the acceptance clause differently, change it; I put in what I understood.

The only change from the version Songbo posted is the added clause in the Claim's non-claims sentence ("...or relying-party acceptance of the action"). Everything else stands as reconciled.

Possession under condition — reconciled row (Nguyen-Huu / Bu)

- Claim: the presenter is the genuine attested actor or workload at this hop, and its signing key exists only while its attested release conditions currently hold — right user present, platform sound, workload genuine. This proves live possession under configured conditions; it does not by itself prove delegated authority, human authorization, operation scope, action sufficiency, or relying-party acceptance of the action. Not "a key answered the handshake," but "a key whose continued existence is those conditions answered."

- Carrier: the mTLS possession proof — the CertificateVerify signature over the handshake, on a hardware-bound key registered with the relying party (raw public key or certificate / X.509-SVID, immaterial to this row) — together with the enrollment and attestation material binding the actor/workload/environment tuple, the protected key, and the key-release policy. The signature is producible only if the release policy is satisfied at that instant.

- Verifier and rule: the relying party, sidecar, gateway, or verifier, offline, per connection: validate the key against the enrolled trust bundle it already holds — no per-connection issuer call — and take a completed handshake as possession under the current condition. The attestation and enrollment evidence, bound at enrollment and re-attestation, explains why that key is usable only while the stated conditions hold. A cryptographic fact prepared ahead of time, not a policy claim made in the moment.

- Binding and freshness: bound to the platform (the key cannot exist outside its boundary), to the enrolled actor/workload/environment tuple and release policy, and, where present, to the verified human at that platform — distinct from the approving human in the human-authorization row: one is present, the other approved the action. Freshness is condition-liveness, not a validity window: the entity that assesses the condition and the entity that withdraws the key are the same — the endpoint — so validity ends by absence, with no revocation message to travel or go stale. The condition is re-proven at every key agreement, and this is airtight at key-agreement granularity: key erasure guarantees the next key agreement fails. At connection granularity it must be stated, not assumed — an in-flight connection is not torn down by key absence alone, the same boundary a rotated certificate has, so immediate termination of a long-lived connection after a condition change is a separately specified behavior, delivered by bounding connection lifetime or driven from the event channel.

- Failure behavior: missing or invalid enrollment or attestation evidence, stale lifecycle state beyond the configured bound, local condition failure that makes the key unavailable, or failure to prove possession, all fail as a possession/condition failure — independent of delegation-chain failure and of human-authorization failure. For locally detectable failure no message travels; absence enforces. Distrust of a still-sound platform decided elsewhere rides a CAEP-class channel, as the other rows' external inputs do.

- Dependency: the hardware or protected key-release mechanism enforcing "cannot exist outside its boundary"; the attestation verifier or enrollment authority; and any lifecycle or event channel used for externally originated change. The row makes no authority claim of its own: it supplies the holder proof the delegation-chain and human-authorization rows depend on at the transport, and nothing more.

- Evidence: reference implementation at github.com/WinMagic/LIT<http://github.com/WinMagic/LIT>. The verified-human presence-bound path is demonstrated. The workload path is not yet implemented, and this cell says so. When the workload vectors publish they will carry this row's negative analogue in the shape the thread set — transport attempted, required condition unmet, possession fails closed — the possession-layer counterpart to the composition negative EMILIA already ships.

For -05 if it clears tonight's cutoff; otherwise it folds into the next revision after Vienna and this stands alongside -04.

Thank you,
Thi
[e-mail]<mailto:[e-mail]> |  www.winmagic.com<http://www.winmagic.com>

WinMagic Corp. | 11-80 Galaxy Blvd.
Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<http://www.winmagic.com>

-----Original Message-----
From: Songbo Bu <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 6, 2026 2:34 AM
To: Thi Nguyen-Huu <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [WIMSE] Re: Condition-bounded credential profile for WIMSE — no rotation, no cert lifecycle

CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.


Hi Thi,

Your merged row is right to me, with one wording boundary I would keep explicit.

I would record it as a possession-under-condition row, not as an
authorization row. The accepted result should be narrow: the relying
party has verified live possession of the enrolled hardware-bound key
under the attested release policy for this connection. It should not
imply delegated authority, human approval, terminal scope, action
sufficiency, or relying-party policy acceptance.

The strongest part of the row is the freshness model. It is not a time
window; it is condition-liveness. The assessor and the stopper are the
same endpoint component, so locally detectable failure removes the key
before the next key operation. I agree with the long-lived-connection
carve-out: key absence guarantees the next key agreement fails, but
immediate termination of an already established connection is a
separate session-management behavior and should be specified
separately if a profile depends on it.

I would also keep the evidence cell exactly as honest as you wrote it:
the verified-human presence-bound path is demonstrated in
WinMagic/LIT; the workload path is not yet implemented. That is a
useful example of why these rows need explicit evidence status rather
than making every row look equally mature.

For my own verifier-matrix draft, I will treat this as a supplied
possession row and fold the same structure into the next revision:
condition-live freshness, separate authorization and acceptance rows,
explicit long-lived-connection behavior, and evidence status for
partial or open implementation paths.

If you post it, I support the merged row with the boundary above preserved.

Best,
Songbo

On Mon, 6 Jul 2026 02:23:12 +0000, Thi Nguyen-Huu <[e-mail]<mailto:[e-mail]>> wrote:
> Hi Songbo,
>
> (I don’t have enough time to check thoroughly. If mistakes, please let me know. Thanks).
>
> Karthik asked for a single reconciled possession row from the two of us
> — your verifier restatement and my -04 row merged, with your three sharpenings folded in explicitly (the non-claims sentence inside the claim, the long-lived-connection carve-out, and the vector shape). Here is
> my proposed merge. It reads to me as your row and mine at two levels of specificity, made one. If it's right to you — or right with your tweaks — either of us can post it before tonight's cutoff for -05; if we miss the cutoff it folds into the next revision
> after Vienna, and the thread stands as the interim record alongside -04. No pressure either way; -04 already carries the row.
>
> One cell only I can set, and I've set it honestly: the workload path is not implemented, so the Evidence cell says so. I did not claim a workload vector we don't ship.
>
> Proposed reconciled row:
>
> Possession under condition — reconciled row (Nguyen-Huu / Bu)
>
> - Claim: the presenter is the genuine attested actor or workload at this hop, and its signing key exists only while its attested release conditions currently hold — right user present, platform sound, workload
> genuine. This proves live possession under configured conditions; it does not by itself prove delegated authority, human authorization, operation scope, or action sufficiency. Not "a key answered the handshake," but "a key whose continued existence is those
> conditions answered."
>
> - Carrier: the mTLS possession proof — the CertificateVerify signature over the handshake, on a hardware-bound key registered with the relying party (raw public key or certificate / X.509-SVID, immaterial to
> this row) — together with the enrollment and attestation material binding the actor/workload/environment tuple, the protected key, and the key-release policy. The signature is producible only if the release policy is satisfied at that instant.
>
> - Verifier and rule: the relying party, sidecar, gateway, or verifier, offline, per connection: validate the key against the enrolled trust bundle it already holds — no per-connection issuer call — and take
> a completed handshake as possession under the current condition. The attestation and enrollment evidence, bound at enrollment and re-attestation, explains why that key is usable only while the stated conditions hold. A cryptographic fact prepared ahead of
> time, not a policy claim made in the moment.
>
> - Binding and freshness: bound to the platform (the key cannot exist outside its boundary), to the enrolled actor/workload/environment tuple and release policy, and, where present, to the verified human at that
> platform — distinct from the approving human in the human-authorization row: one is present, the other approved the action. Freshness is condition-liveness, not a validity window: the entity that assesses the condition and the entity that withdraws the key
> are the same — the endpoint — so validity ends by absence, with no revocation message to travel or go stale. The condition is re-proven at every key agreement, and this is airtight at key-agreement granularity: key erasure guarantees the next key agreement
> fails. At connection granularity it must be stated, not assumed — an in-flight connection is not torn down by key absence alone, the same boundary a rotated certificate has, so immediate termination of a long-lived connection after a condition change is a
> separately specified behavior, delivered by bounding connection lifetime or driven from the event channel.
>
> - Failure behavior: missing or invalid enrollment or attestation evidence, stale lifecycle state beyond the configured bound, local condition failure that makes the key unavailable, or failure to prove possession,
> all fail as a possession/condition failure — independent of delegation-chain failure and of human-authorization failure. For locally detectable failure no message travels; absence enforces. Distrust of a still-sound platform decided elsewhere rides a CAEP-class
> channel, as the other rows' external inputs do.
>
> - Dependency: the hardware or protected key-release mechanism enforcing "cannot exist outside its boundary"; the attestation verifier or enrollment authority; and any lifecycle or event channel used for externally
> originated change. The row makes no authority claim of its own: it supplies the holder proof the delegation-chain and human-authorization rows depend on at the transport, and nothing more.
>
> - Evidence: reference implementation at github.com/WinMagic/LIT<http://github.com/WinMagic/LIT>. The verified-human presence-bound path is demonstrated. The workload path is not yet implemented, and this cell says so. When the workload vectors
> publish they will carry this row's negative analogue in the shape the thread set — transport attempted, required condition unmet, possession fails closed — the possession-layer counterpart to the composition negative EMILIA already ships.
>
> If you want your own statement of the row preserved as the verifier-facing view rather than merged, say so and I'll keep both, marked. Otherwise, confirm or mark it up and let's get it posted.
>
> Thank you
> 😊
>
> Thi
>
> From: KARTHIK RAMPALLI <[e-mail]<mailto:[e-mail]>>
>
> Sent: Sunday, July 5, 2026 5:51 PM
>
> To: Iman Schrock <[e-mail]<mailto:[e-mail]>>
>
> Cc: Thi Nguyen-Huu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
>
> Subject: Re: [WIMSE] Re: Condition-bounded credential profile for WIMSE — no rotation, no cert lifecycle
>
> CAUTION:This email originated from outside of the organization. Do
> not click links, open attachments or respond unless you recognize the sender and know that the content is safe.
>
> Songbo, Iman, Thi, all,
>
> >> Songbo, preserved as exactly that. The -04 row is titled and framed as possession under condition, it claims no authority of its own, and its dependency cell says it supplies the holder proof the chain and human-authorization rows depend
> on at the transport, and nothing more. Your restatement and Thi's read to me as the same row at two levels of specificity, with three additions of yours worth folding in explicitly.
>
> First, the non-claims sentence: possession does not by itself prove delegated authority, human authorization, operation scope, or action sufficiency. Putting the boundary inside the claim itself, rather than only in the dependency cell,
> is the stronger form.
>
> Second, the long-lived-connection carve-out. Key erasure guarantees the next key agreement fails; termination of an in-flight connection after a condition change is separate behavior that needs specifying separately. That is a real sharpening:
> condition-bound validity is airtight at key-agreement granularity, and at connection granularity it must be stated, not assumed.
>
> Third, the vector shapes. Iman's note that the composition negative already runs as a public vector class on the EP side (transport passes, required receipt absent or consumed, guarded action refuses) raises the bar in the right way: the
> cross-row negative is not a thought experiment, it is a test one supplier already ships. I would like every supplied row to carry its analogue, the chain row included when its vectors publish.
>
> >> Iman, the boundary sentence is the one the composition section has been missing: often the same person, never the same row. It joins two others this list has produced in the past week: attribution versus approval (your note on the AGTP
> thread) and may versus did (the capsule binding). Three boundaries, one shape: same action digest, different claims, independent failure. The next revision collects them in the composition section as the discipline that lets the rows be conjunctive without
> inheritance.
>
> Also adopting from Songbo: application acceptance as a separate relying-party decision alongside the rows. That is where the final conjunctive verdict lives, and it belongs in the composition section rather than in any single row.
>
> On the row itself: since its supplier is one organization, the cleanest path is a single reconciled row text from Songbo and Thi. If it reaches the list before tonight's cutoff, -05 posts before Vienna carrying it; otherwise the amendments fold into the next
> revision after the meeting, and this thread stands as the interim record alongside -04.
>
> Karthik Rampalli
>
> Glyphzero, Inc.
>
> On Mon, Jul 6, 2026 at 1:11 AM Iman Schrock <[e-mail]<mailto:[e-mail]>> wrote:
>
> Thi, Songbo, Karthik, all,
>
> Thi, from the supplier of the human-authorization row: your reading of it is correct, including the distinction that matters most. The verified human present at the platform and the named human who approved this operation are different claims. Often the same
> person, never the same row. A receipt names the approver and the exact action digest, so a verifier can check whether the two coincide without either row inheriting the other. Presence at the wire never substitutes for approval of the action, and approval
> never substitutes for presence.
>
> Songbo, your last evidence bullet already exists as a public vector class in our suite: transport-level checks pass, the required receipt is absent or already consumed, and the guarded action refuses. That is the cross-row negative case stated as running code,
> and it is exactly why the rows can be conjunctive in the final decision without inheriting each other's guarantees.
>
> The condition-bound freshness discipline in Thi's row, where the assessor of the condition and the stopper of the grant are the same place, is the sharpest statement of that property on this list so far.
>
> Iman Schrock
>
> EMILIA Protocol
>
> On Sun, Jul 05, 2026 06:06 AM, Songbo Bu <[e-mail]<mailto:[e-mail]>> wrote:
>
> Hi Karthik, Thi, Iman, all,
>
> Thank you. The -04 direction sounds right to me. For the record, the Live Key / condition-bounded credential row I would want preserved is a possession-under-conditions row, not an authorization row.
>
> Stated in the same template vocabulary:
>
> - Claim: the presenter possesses an enrolled protected key whose use is gated by an attested key-release policy. This proves live possession under configured conditions; it does not by itself prove delegated authority, human
> authorization, operation scope, or action sufficiency.
>
> - Carrier: the mTLS / X.509-SVID or equivalent transport proof, plus the enrollment and attestation material that binds the actor, workload or node environment, protected key, and key-release policy.
>
> - Verifier and rule: the relying party, sidecar, gateway, or trusted verifier checks the key identity, the enrollment or attestation binding, the relevant trust anchors, and the freshness or lifecycle state required by the
> profile. The TLS handshake or equivalent proof shows possession of the enrolled key; the attestation/enrollment evidence explains why that key is usable only while the stated conditions hold.
>
> - Binding and freshness: bound to the enrolled actor/workload/environment tuple, the protected key, and the release policy. Re-attestation, lifecycle withdrawal, posture change, device retirement, or incident response is carried
> by CAEP or an equivalent event channel where the deployment relies on external state. If a long-lived connection must be terminated immediately after a condition change, that behavior needs to be specified separately from the possession proof.
>
> - Failure behavior: missing or invalid enrollment evidence, stale attestation or lifecycle state beyond the configured bound, local condition failure that makes the key unavailable, or failure to prove possession fails as a
> possession/condition failure. That failure remains independent of delegation-chain failure and independent of human-authorization failure.
>
> - Dependency: the hardware or protected key-release mechanism, the attestation verifier or enrollment authority, and any lifecycle/event channel used for external changes. Authorization scope, delegation-chain validity, and
> human authorization remain separate rows and separate dependencies.
>
> - Evidence: useful vectors should include at least one positive case where the key can sign only under valid conditions, and negative cases where the local condition fails and the next key use fails, where lifecycle state is
> stale or withdrawn, and where possession succeeds but required authorization evidence is absent.
>
> That keeps the composed stack diagnostically clean: possession at the wire, attenuation along the chain, human authorization at the root, and application acceptance as a separate relying-party decision. The rows can be conjunctive in the final decision without
> inheriting each other’s guarantees.
>
> Best,
>
> Songbo
>
> On Sun, 5 Jul 2026 21:42:17 +0900, KARTHIK RAMPALLI [e-mail]<mailto:[e-mail]> wrote:
>
> Thi, thank you
>
> The row is in verbatim, and -04 is posted with it, so the document in front of Vienna carries all three rows of the composed stack stated by their suppliers: possession under condition at the wire (yours), attenuation along the chain (mine), human authorization
> at the root (Iman’s), each failing independently, all joined on the same action digest. Your framing sentence is recorded above the row as the split the rows sit on: one authentication anchor, several authorization inputs decided above the key.
>
> Two things in your row that improve the whole table. First, the freshness discipline: condition-bound validity rather than time-bound, because the assessor of the condition and the stopper of the grant are the same place, so absence enforces and no revocation
> message has to travel. That is a sharper statement of the property the other rows approximate with lifetimes and feeds, and I recorded your sentence about it verbatim.
>
> Second, the evidence cell that says the workload path is not yet implemented: the chain row’s evidence cell is open too, and a table where empty cells say so is worth more than one where they don’t.
>
> One small correction to your note: the revisions moved quickly this weekend, so your row landed in -04 rather than -01; the changelog names each contribution and contributor per revision.
>
> Karthik Rampalli
>
> Glyphzero, Inc.
>
> On Sun, Jul 5, 2026 at 8:58 PM Thi Nguyen-Huu
> [e-mail]<mailto:[e-mail]> wrote:
>
> Songbo, Karthik, Iman, all,
>
> I probably won’t have every piece of this thread right — correct me where I’m mistaken. Thanks.
>
> The diagnostically-separate rows are the right structure, and the split underneath them is the one we’d draw too: one authentication anchor, several authorization inputs. Possession-under-condition
>
> is the authentication row — the genuine, present principal at the wire. Attenuation along the chain, human authorization at the root, external lifecycle, terminal scope — those are authorization, decided above the key. They lean on the possession row for holder
>
> proof and otherwise fail on their own. So Karthik’s composed line reads, to us, as one anchor plus its authorizations, joined on the action digest.
>
> Here is the possession row in the template’s form, as the supplier:
>
> - Claim: the principal at this hop is the genuine attested actor/workload,
>
> and its signing key exists only while its release conditions currently hold — right user present, platform sound, workload genuine. Not “a key answered the handshake,” but “a key whose continued existence is those conditions answered.”
>
> - Carrier: mTLS with a hardware-bound key registered with the relying
>
> party; the CertificateVerify signature is the possession proof, producible only if the release policy is satisfied at that instant. (Raw public key or certificate — immaterial to this row.)
>
> - Verifier and rule: relying party, offline, per connection — validate
>
> the key against the trust bundle it already holds, no per-connection issuer call, and take a completed handshake as possession-under-current-condition. The condition-gating is made verifier-observable by attestation (RATS evidence binding the key’s release
>
> policy to the platform measurement) at enrollment and re-attestation; the handshake then proves possession under that attested policy for the session. A cryptographic fact prepared ahead of time, not a policy claim made in the moment.
>
> - Binding and freshness: bound to the platform — the key cannot
>
> exist outside its boundary — and, where present, to the verified human at that platform (distinct from the approving human in Iman’s row: one is present, the other approved this operation). Freshness is not a validity window. Whoever assesses the condition
>
> also stops the grant, in the same place: the endpoint erases the key the instant the condition fails, so no revocation message travels and there is no gap for the key to outlive the condition. A workload session is a stream of mTLS connections, each needing
>
> the key, so the condition is re-proven every connection. Condition-bound validity, not time-bound.
>
> - Failure behavior: local condition failure — lock, posture loss,
>
> user absent, measurement change — removes the key at the source; the next key agreement cannot complete. A possession/presentation failure, independent of chain attenuation and of human authorization. No message travels for what the endpoint can see itself;
>
> absence enforces. Distrust of a still-sound platform, decided elsewhere, is the authorization case — it rides a CAEP-class channel, the same complement the other rows use.
>
> - Dependency: a hardware root of trust enforcing “cannot exist
>
> outside its boundary” — a TPM for users, a confidential-computing-anchored vTPM with anti-rollback for workloads; enrollment-time attestation binding the release policy to the measurement; the RP’s enrolled trust bundle. The row makes no authority claim of
>
> its own; it supplies the holder proof the chain and human-authorization rows depend on at the transport, and nothing more.
>
> - Evidence: reference implementation at [github.com/WinMagic/LIT](http://github.com/WinMagic/LIT)<http://github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT)>.
>
> The verified-human presence-bound path is demonstrated. We haven’t implemented anything for the workload yet, though. An empty evidence cell should be allowed to say so, as Karthik noted for the chain row.
>
> Net: possession-under-condition at the wire, attenuation along the chain, human authorization at the root — each failing independently, all joined on the same action digest.
>
> Ours is the row where freshness is liveness rather than a window, because the assessor and the stopper are the same place. If it lands before Monday it can go into -01 with the others; otherwise it folds to the next revision.
>
> Best,
>
> Thi
>
> From: KARTHIK RAMPALLI [e-mail]<mailto:[e-mail]>
>
> Sent: Sunday, July 5, 2026 12:09 AM
>
> To: Iman Schrock [e-mail]<mailto:[e-mail]>
>
> Cc: [e-mail]<mailto:[e-mail]>; Thi Nguyen-Huu
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
>
> Subject: Re: [WIMSE] Re: Condition-bounded credential profile for WIMSE — no rotation, no cert lifecycle
>
> You don’t often get email from
>
> [e-mail]<mailto:[e-mail]>.
> [Learn why this is important](https://aka.ms/LearnAboutSenderIdentification)
>
> CAUTION:This email originated from outside of the organization. Do
>
> not click links, open attachments or respond unless you recognize the sender and know that the content is safe.
>
> Uploaded it here - https://datatracker.ietf.org/doc/draft-rampalli-cross-org-delegation-mapping/
>
> On Sun, Jul 5, 2026 at 1:07 PM KARTHIK RAMPALLI
> [e-mail]<mailto:[e-mail]> wrote:
>
> Dr. Iman, thank you.
>
> The row is stated in exactly the discipline, and it will go in verbatim, credited, not trimmed. The two parts I would least want trimmed are the ones only the supplier could have written: the one-time-use split, offline-verifiable versus enforcement-point
>
> state with the state holder named in the dependency, so the two stay visible separately; and the machine-readable refusal, because a refusal that names the missing evidence is itself audit material, which is the composable-audit property arriving through the
>
> failure path.
>
> Given the draft cutoff on Monday, I intend to post the mapping -01 before it, so the document in front of Vienna already carries the row. One asymmetry the revision states rather than papers over: the chain row does not yet cite public
>
> evidence vectors, and its evidence entry reads as open until vectors are published. An evidence column is only useful if an empty cell is allowed to say so.
>
> Songbo, that makes the possession row the remaining supplied-by-name row. If you want to state the Live Key row in the same form and it arrives before the cutoff, -01 can carry it too; otherwise it folds into the next revision, as would a session-binding
>
> entry from Ramki’s thread.
>
> Karthik Rampalli
>
> Glyphzero, Inc.
>
> On Sun, Jul 5, 2026 at 1:00 PM Iman Schrock
> [e-mail]<mailto:[e-mail]> wrote:
>
> Karthik, Songbo, Thi, all,
>
> The chain row stated in template terms is the way to do it, and the mapping draft posting is noted with thanks: the R5 and R4 corrections read right, and pinning verdicts to cited revisions with this list as the canonical venue is the discipline that keeps
>
> the document trustworthy.
>
> So the standalone table can carry it in the same form, here is the human-authorization row, stated the way you stated the chain row:
>
> - Claim: a named, accountable human (or an M-of-N quorum of distinct humans, optionally ordered) authorized this exact operation before execution. Asserted as human authority, not organizational policy; the row names which,
> per the -02 direction on Songbo’s
>
> template.
>
> - Carrier: the authorization receipt (EP-RECEIPT-v1, or EP-QUORUM-v1 for multi-party), a self-contained signed JSON artifact conveyed inline or referenced by digest from the host record.
>
> - Verifier and rule: the relying party, offline, no account: Ed25519 over the RFC 8785 canonical action bytes against a pinned issuer key. For a quorum: threshold met by distinct principals over the same digest, order enforced
> when declared. Verified and accepted
>
> stay separate results, and neither implies sufficiency.
>
> - Binding and freshness: bound to the action digest (the shared join key; digest equality is a join key, never authorization) and to the named principal. Validity window on the artifact. One-time use is enforcement-point state,
> not offline-verifiable; the state
>
> holder is named in the dependency, so the offline part and the enforcement part stay visible separately.
>
> - Failure behavior: missing, invalid, stale, replayed, or out-of-scope fails the request as a human-authorization failure, independently of key possession and of chain attenuation. The refusal is machine-readable (HTTP 428
> challenge naming the missing evidence),
>
> so a refusal is itself evidence, not silence.
>
> - Dependency: relying-party key pinning (a binding from an unpinned issuer must not be accepted); an enforcement point for one-time consumption, deployed by the resource owner; and holder proof at presentation rides the possession
> row at the transport, the
>
> same shared dependency your mapping records at R4. The row makes no possession claim of its own.
>
> - Evidence: public vectors, positive and negative (receipts and quorum suites in the reference repo); reproducible in one line with npx -y ep-verify or pip install ep-verify.
>
> Your composed-stack sentence is the one I would keep: possession at the wire, attenuation along the chain, human authorization at the root, each failing independently, all joined on the same action digest. Use this row verbatim or trimmed, whichever serves
>
> the document.
>
> Iman
>
> On Sat, Jul 04, 2026 08:39 PM, KARTHIK RAMPALLI [e-mail]<mailto:[e-mail]> wrote:
>
> Hello Songbo, Iman, Thi, all,
>
> The diagnostically separate rows are the structure I would want as a verifier too, and Iman’s human-authorization row belongs in the set: it is an input class that fails independently of the key and the chain, and it joins on the same action
>
> digest the other rows use.
>
> Taking the framing seriously for the row Songbo labeled “inherited delegation-chain input”: under the matrix rules of draft-bu-agentproto-security-principal-binding-01, an inherited mechanism is not a current guarantee unless its dependency
>
> and failure behavior are stated. So here is that row stated in the template’s own terms, with PEDIGREE as the supplier:
>
> - Claim: authority for this exact operation was conveyed from the root principal and narrowed at every hop; the terminal scope covers the operation.
>
> - Carrier: the per-hop delegation tokens, conveyed inline with the request.
>
> - Verifier and rule: the relying party, offline: re-verify each hop’s signature against its issuer key, check per-hop scope subsetting and mandate narrowing, take effective expiry as the minimum over hops, and require the operator-ceiling
> conjunct.
>
> - Binding and freshness: bound to the root principal and to the holder’s key; staleness bounded by chain lifetime; cascade revocation rides a CAEP-class channel where one exists.
>
> - Failure behavior: any hop signature failure, subset violation, or expiry fails the request as an authorization failure, independently of key possession and of human authorization. A revocation feed older than the configured
> bound must
>
> fail closed; making that normative is the pedigree-02 item already flagged on Morgan’s thread.
>
> - Dependency: the originating organization’s trust anchor (root only; intermediate hops use self-certifying identifiers), inline conveyance of parent tokens, and the possession row at the transport for holder proof.
>
> Stated that way, nothing is inherited implicitly: the chain row supplies the authority path and its attenuation, and it explicitly depends on the possession row rather than assuming it. The Live Key profile keeps its guarantees, the chain
>
> keeps its own, and a verifier gets a distinct failure class from each.
>
> With Iman’s row added, the composed stack has clean names and clean failure classes: possession at the wire, attenuation along the chain, human authorization at the root, each failing independently, all joined on the same action digest.
>
> That is the same discipline the combined R1-R9 table on Morgan’s thread converged on, so when I cut that table as a standalone doc I will state the chain row in exactly this form, and the two threads can reference one artifact.
>
> Karthik Rampalli
>
> Glyphzero, Inc.
>
> On Sun, Jul 5, 2026 at 11:22 AM Iman Schrock
> [e-mail]<mailto:[e-mail]> wrote:
>
> Songbo, Karthik, Thi,
>
> The diagnostically separate rows are the right structure. One addition: some operations are human-gated by policy, so there is an input class that is neither possession nor delegation:
>
> -
> pre-execution human authorization: a named human, or an M-of-N quorum of distinct humans, authorized this exact operation, bound to the same action digest the other rows join on.
>
> It fails independently of the chain and the key. A live key with a valid, sufficiently scoped chain still fails closed if the required human authorization is absent, stale, or bound to different action bytes. EMILIA supplies this row today (draft-schrock-ep-human-authorization-binding-00,
>
> draft-schrock-ep-receipts-05), and it composes with the Live Key profile and PEDIGREE by digest without inheriting or granting either layer’s guarantees, per Songbo’s framing.
>
> Dr. I,
>
> On Sat, Jul 4, 2026 at 7:09 PM Songbo Bu
> [e-mail]<mailto:[e-mail]> wrote:
>
> Hi Karthik, Thi, all,
>
> Yes — this is the separation I intended.
>
> For a verifier, the condition-bounded credential and the delegation
>
> chain are two different inputs to the decision:
>
> -
> the condition-bounded credential proves possession of a stable key
>
> whose use is gated by an attested key-release policy;
>
> -
> the delegation chain proves that authority was conveyed and narrowed
>
> across hops;
>
> -
> the authorization decision still needs audience, scope, operation,
>
> time bounds, and relying-party policy to be checked explicitly.
>
> Those inputs should be conjunctive for the final decision, but
>
> diagnostically separate. If the key is live but the terminal scope
>
> does not cover the operation, the request fails as an authorization
>
> failure. If the chain is valid but the holder cannot prove possession
>
> at the transport layer, the request fails as a possession/presentation
>
> failure. If the local release condition fails and the key disappears,
>
> the next key use or handshake fails independently of the delegation
>
> chain.
>
> For the condition-bounded profile, I would therefore keep a small
>
> verifier-facing table with separate rows for:
>
> - enrolled key / actor / workload / environment binding;
>
> - live key possession at connection time;
>
> - local condition failure and key unavailability;
>
> - external lifecycle or policy events, such as CAEP or an equivalent channel;
>
> - authorization inputs: audience, scope, operation, and time bounds;
>
> - inherited delegation-chain input, where PEDIGREE or another chain
>
> mechanism supplies the authority path.
>
> That framing lets the Live Key profile and PEDIGREE compose without
>
> one inheriting guarantees from the other implicitly. It also gives
>
> WIMSE reviewers a clean failure path for each row.
>
> Best,
>
> Songbo
>
> On Sun, 5 Jul 2026 05:39:39 +0900, KARTHIK RAMPALLI
>
> [e-mail]<mailto:[e-mail]> wrote:
>
> Hi Songbo, Thi, all,
>
> Songbo’s verifier-processing model draws a line I want to build on: authorization stays separate from key possession. Audience, scope, operation, and time bounds are authorization inputs, not properties inferred from the key.
>
> For agentic actors, that authorization input is often not a single grant but a delegation chain. An orchestrator spawns sub-agents, a sub-agent calls a tool in another trust domain, and each hop is supposed to carry equal or narrower authority than its parent.
>
> Key possession proves which workload is at the wire. It says nothing about whether the chain behind the request is intact, whether any hop widened its scope, or whether a parent grant was swapped after issuance.
>
> We published an individual draft in April that profiles exactly this layer above WIMSE credentials, and refreshed it this week as -01 with a section positioning it against WIMSE-ARCH and the workload credentials document:
>
> https://datatracker.ietf.org/doc/draft-rampalli-pedigree/
>
> It defines per-hop delegation tokens with monotonic scope attenuation checked both at mint and at verify, strict re-verification of the parent token at each hop (which catches parent-swap attacks that append-only chains miss), and a dual enforcement model:
>
> an operator ceiling plus per-parent narrowing. The workload identity underneath is deliberately not redefined. The draft assumes a SPIFFE or WIMSE credential and layers delegation on top.
>
> Three connections to threads on this list:
>
> -
> To Thi’s profile: keeping the actor slot generic is the right call, and a delegation chain is one concrete instance of the authorization input the Live Key profile deliberately keeps separate from possession. A hardware-bound possession proof plus a verifiable
>
> attenuation chain compose cleanly; neither replaces the other.
>
> -
> To Yuning’s heterogeneous-credential work: a delegation token is one more typed input to the set-level processing, and its verification result normalizes the same way (chain validity, terminal scope, expiry of the narrowest hop).
>
> -
> To the SCITT Agent Action Capsule work (draft-mih-scitt-agent-action-capsule): AAC records what an agent actually did and carries the authority that permitted it as an opaque reference. A delegation chain is one natural resolution target for that reference,
>
> closing the loop between “was permitted” and “was done.” We posted a short binding profile on that composition this week: draft-rampalli-scitt-capsule-provenance-binding-00.
>
> If the comparative requirements mapping Morgan invited goes ahead, we would be glad to map PEDIGREE against it alongside the others.
>
> Feedback welcome, on-list or off.
>
> Karthik Rampalli
>
> Glyphzero, Inc.
>
> On Wed, Jun 24, 2026 at 12:09 AM Songbo Bu
> [e-mail]<mailto:[e-mail]> wrote:
>
> Hi Thi, all,
>
> Thanks, that framing works for me.
>
> I took a first pass at turning the PDF and the list discussion into an
>
> I-D-shaped outline. The main edit is to keep the document framed as a
>
> condition-bounded workload-credential profile, with “Live Key” as the
>
> mechanism inside it.
>
> I also adjusted the verifier model around the point you clarified: the
>
> trust is prepared at enrollment and refreshed by
>
> attestation/re-attestation over time; the handshake then proves live
>
> key presence under that prepared binding. That is cleaner than making
>
> it sound like the verifier needs a fresh condition-evidence exchange
>
> on every key use.
>
> I will send you the working skeleton off-list so we can fill in the
>
> hardware release / condition-gating details before bringing a cleaner
>
> -00 outline back to WIMSE.
>
> Best,
>
> Songbo
>
> On Tue, 23 Jun 2026 13:20:38 +0000, Thi Nguyen-Huu [e-mail]<mailto:[e-mail]> wrote:
>
> Hi Songbo,
>
> This is genuinely helpful. You know WIMSE well and I’d be glad for you to take the first pass at shaping this into a draft. Our substance is in the PDF to draw from, and your
>
> verifier-processing subsection is the most WG-native part of it. I’ll bring the mechanism detail (the hardware key-derivation and condition-gating) and the reference implementation as you need them.
>
> On your line “the verifier also needs evidence, or a trusted policy assertion, that the key is released only while the conditions hold”: in our model that’s not an extra check
>
> at use time. The trust is prepared. At registration, the key is bound - hardware-based, non-exfiltratable - to its release conditions, and that binding is attested, and re-attested over time. After that, presence is the condition-check: the key can only
>
> produce
>
> the handshake signature if its conditions currently hold. The binding prepared at enrollment, the presence proven live in the handshake — rather than the verifier needing separate evidence each time.
>
> And I take your naming point “condition-bounded credential” as the framing, with “Live Key” as the name of the mechanism inside. The subject already goes that way: draft-winmagic-wimse-condition-bounded-credentials.
>
> I’ll be glad to have a short call whenever useful. Thank you, this really helps.
>
> Thi
>
> WinMagic Corp.
>
> From: Songbo Bu [e-mail]<mailto:[e-mail]>
>
> Sent: Monday, June 22, 2026 9:22 PM
>
> To: Thi Nguyen-Huu [e-mail]<mailto:[e-mail]>;
>
> [e-mail]<mailto:[e-mail]>
>
> Subject: Re: [WIMSE] Re: Condition-bounded credential profile for WIMSE — no rotation, no cert lifecycle
>
> CAUTION:This email originated from outside of the organization. Do
>
> not click links, open attachments or respond unless you recognize the sender and know that the content is safe.
>
> Hi Thi, all,
>
> Thanks, that works for me.
>
> I would keep the next revision small and implementation-facing.
>
> Here is a candidate verifier-processing subsection that you can use, edit, or reject:
>
> Verifier processing model
>
> For this profile, the verifier should treat key possession, attested key-release conditions, and authorization scope as separate inputs to the decision.
>
> At enrollment, the verifier or its trusted enrollment component records the binding between the workload actor, the protected key, the key-release policy, the node/environment identity, and the attestation evidence that supports those conditions.
>
> During an mTLS connection, the TLS handshake proves possession of the enrolled key.
>
> That proof alone is not the complete condition check.
>
> The verifier also needs evidence, or a trusted policy assertion, that the key is released only while the configured actor, node, workload measurement, and posture conditions hold.
>
> If a local condition fails, the key-release mechanism should make the key unavailable.
>
> The next use of the key, including a subsequent mTLS handshake or other key operation, fails.
>
> If the deployment requires immediate termination of an already established long-lived connection, that behavior should be specified as an additional session-management rule or driven by a continuous-evaluation signal.
>
> Externally originated lifecycle changes, such as device retirement, policy withdrawal, attestation-root change, or incident response, remain lifecycle events.
>
> They can be carried to the verifier through CAEP or an equivalent event channel.
>
> This is why the profile reduces rotation pressure for the anti-exfiltration property but does not eliminate lifecycle management.
>
> Authorization remains separate from possession of the stable hardware-bound key.
>
> Audience, scope, operation, and time bounds should be checked as authorization inputs rather than inferred from key possession.
>
> I would also suggest avoiding “no lifecycle” as the main headline.
>
> “Condition-bounded stable credential” or “live-key-bound workload credential” may be easier for WIMSE readers to accept.
>
> Best,
>
> Songbo
>
> On Mon, 22 Jun 2026 17:12:41 +0000, Thi Nguyen-Huu [e-mail]<mailto:[e-mail]> wrote:
>
> Hi Songbo, and you know wimse much better than I do too, I think. Your help would be very good for me. Thanks.
>
> Get
>
> [Outlook for iOS](https://aka.ms/o0ukef)
>
> From: Thi Nguyen-Huu thi.nh=[e-mail]<mailto:[e-mail]>
>
> Sent: Monday, 22 June 2026 12:12:35
>
> To: Songbo Bu [e-mail]<mailto:[e-mail]>;
>
> [e-mail]<mailto:[e-mail]> [e-mail]<mailto:[e-mail]>
>
> Subject: [WIMSE] Re: Condition-bounded credential profile for WIMSE — no rotation, no cert lifecycle
>
> You don’t often get email from thi.nh=[e-mail]<mailto:[e-mail]>.
>
> [Learn why this is important](https://aka.ms/LearnAboutSenderIdentification)
>
> CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.
>
> Thx Songbo. I’m travelling and this will be short.
>
> Yes, if you can help sketch next revision it will be better than mine with my bias. And yes, your 5 statements are all correct. Thanks a lot.
>
> Thi
>
> Get
>
> [Outlook for iOS](https://aka.ms/o0ukef)
>
> From: Songbo Bu [e-mail]<mailto:[e-mail]>
>
> Sent: Monday, 22 June 2026 11:31:57
>
> To: Thi Nguyen-Huu [e-mail]<mailto:[e-mail]>;
>
> [e-mail]<mailto:[e-mail]> [e-mail]<mailto:[e-mail]>
>
> Subject: RE: [WIMSE] Condition-bounded credential profile for WIMSE — no rotation, no cert lifecycle
>
> [You don’t often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important at
>
> https://aka.ms/LearnAboutSenderIdentification ]
>
> CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.
>
> Hi Thi, all,
>
> Thanks — this clarifies the profile quite a bit.
>
> The “Live Key” / key-disappearance mechanism is the part I would make
>
> very explicit, because it is the piece that makes the profile
>
> different from ordinary long-lived workload identity.
>
> For reviewability, I think the next useful artifact is a small
>
> verifier-facing state model rather than more prose about rotation.
>
> Something like:
>
> -
>
> enrollment binds the key-release policy to the actor, node,
>
> workload measurement, and posture conditions;
>
> -
>
> each mTLS connection proves possession of the same stable key under
>
> that policy;
>
> -
>
> if a local condition fails, the key disappears and the next key use
>
> or handshake fails;
>
> -
>
> if an external condition changes, CAEP or an equivalent channel
>
> carries that policy/lifecycle event to the verifier;
>
> -
>
> authorization scope, audience, and time bounds remain separate from
>
> key possession.
>
> That would keep the profile implementable: the verifier can ask what
>
> state was checked, what event changes that state, and what exact
>
> failure behavior follows.
>
> I also agree that the right claim is not “no lifecycle”, but "lower
>
> rotation pressure for the anti-exfiltration property, with
>
> event-driven lifecycle for the remaining cases".
>
> If useful, I can help sketch this as a short verifier-processing
>
> section or checklist for the next revision.
>
> Best,
>
> Songbo
>
> On Mon, 22 Jun 2026 14:05:18 +0000, Thi Nguyen-Huu [e-mail]<mailto:[e-mail]> wrote:
>
> Hi Songbo,
>
> Thank you very much — all your points are correct, and your email is exactly what I’d hoped for
>
> 😊.
>
> The non-exfiltrable key removes one rotation reason: limiting exposure after theft. But there are more, as you said, and those are handled event-driven. When a device retires or a defect surfaces, the IdP/OP informs the verifier via push/pull — which is
>
> what
>
> CAEP (the OpenID Continuous Access Evaluation Protocol) does. In effect, that channel can carry the lifecycle changes a CA’s reissue-and-revoke cycle carries today —rarely, in years, not minutes or hours.
>
> A bit more on each point:
>
> Verifier-observable binding. Agreed — CertificateVerify proves possession, not conditions. The gating is made observable by attestation: RATS evidence binding the key’s release policy to the workload measurement, established at enrollment and re-attestation.
>
> The handshake then proves possession-under-that-policy for this session. The profile has to carry both.
>
> Mid-session. A workload session is a stream of mTLS connections, each needing the key — so key-disappearance is the live mid-session control: the instant a condition fails, the key is gone and the next mTLS key agreement can’t complete. That disappearance
>
> is the novelty here. I would be glad to elaborate more in a meeting. The key is released only while actor, node, and posture all hold (attached doc last time, §4 Validity), and it can be the same key across connections, not just once. CAEP complements it
>
> for
>
> what the node can’t see itself — an externally-originated change, or killing a single long-lived connection at once rather than waiting for its next handshake.
>
> Key vs authorization lifetime. Fully agreed — §4 (Authorization) keeps these separate: the hardware key is the stable identity; audience, scope, and time bounds stay on the authorization.
>
> So yes — an optional profile for stable, attestable deployments, where non-exfiltration reduces the rotation cadence rather than abolishing lifecycle. That’s the right frame, and I’ll write it that way.
>
> Happy to walk through the key-disappearance mechanism in more detail, on the list or a quick call — whatever’s easiest for you.
>
> As we go deeper and broader: everything here is the workload actor. The same key — a “Live Key,” whose identity is actor + environment + conditions and which disappears when that identity disappears — applies equally to humans, machines, and IoT. We have
>
> an article in Cyber Defense Magazine on this identity if it’s useful: https://www.cyberdefensemagazine.com/newsletters/march-2026/mobile/index.html#p=259.
>
> Thi
>
> Cheers
>
> Thi Nguyen-Huu | CEO
>
> Tel: [phone] x 3288 | Toll Free: 888.879.5879
>
> [e-mail]<mailto:[e-mail]> |
>
> [[[www.winmagic.com<http://www.winmagic.com>](http://www.winmagic.com)](http://www.winmagic.com)](http://www.winmagic.com)
>
> WinMagic Corp. | 11-80 Galaxy Blvd.
>
> Toronto, ON | M9W 4Y8 | Canada | [[[www.winmagic.com<http://www.winmagic.com>](http://www.winmagic.com)](http://www.winmagic.com)](http://www.winmagic.com)
>
> -----Original Message-----
>
> From: Songbo Bu [e-mail]<mailto:[e-mail]>
>
> Sent: Sunday, June 21, 2026 11:33 PM
>
> To: [e-mail]<mailto:[e-mail]>
>
> Subject: [WIMSE] Condition-bounded credential profile for WIMSE — no rotation, no cert lifecycle
>
> [You don’t often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important at
>
> https://aka.ms/LearnAboutSenderIdentification ]
>
> CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.
>
> Hi Thi, all,
>
> Thanks for sharing this. I think the profile is worth discussing, especially as a hardware-bound mTLS/X.509-SVID profile for stable workloads.
>
> The boundary I would tighten is the “no rotation / no cert lifecycle”
>
> claim. A non-exfiltratable key removes one important reason for short
>
> rotation: limiting exposure after key theft. It does not remove every reason for credential lifecycle management.
>
> A few implementation-facing points seem important to me:
>
> -
>
> The verifier needs a fresh, verifier-observable binding between the TLS key, the workload measurement/posture, and the current session.
>
> CertificateVerify proves possession of the private key, but the relying party also needs to know that the key is currently usable only under the stated conditions.
>
> -
>
> Credential expiry and revocation may no longer carry the primary anti-exfiltration property, but they still help with algorithm agility, attestation-root changes, device retirement, policy withdrawal, incident response, and recovery from implementation
>
> defects.
>
> -
>
> “Validity by presence” needs clear semantics after a session has started. If a posture condition fails mid-session, the profile should say whether the next operation fails, the TLS session is terminated, or an external continuous-evaluation signal is required.
>
> -
>
> Key protection and authorization lifetime should stay separate. A long-lived hardware identity key can authenticate the workload, but task authorization may still need audience, scope, and time bounds.
>
> So I would frame this as an optional WIMSE profile where hardware non-exfiltration reduces the need for frequent key rotation in stable, attestable deployments, rather than as a profile with no credential lifecycle. That framing keeps the useful idea while
>
> avoiding a claim that lifecycle controls are unnecessary.
>
> Best,
>
> Songbo
>
> On Sun, 21 Jun 2026 15:22:34 +0000, Thi Nguyen-Huu thi.nh=[e-mail]<mailto:[e-mail]> wrote:
>
> Hello all,
>
> I’m Thi Nguyen-Huu of WinMagic; Deb Cooley suggested I bring this here
>
> — thanks, Deb.
>
> My understanding is that WIMSE leaves credential lifetime to the
>
> implementation: currently short-lived with rotation, because a
>
> software key can be copied. I’d like to contribute one conforming
>
> profile on the mTLS / X.509-SVID path: a binding key generated in
>
> hardware, non-retrievable, and usable only while attested posture
>
> holds. It can’t be exfiltrated, so it needn’t be rotated; its presence
>
> becomes its validity — proven live by possession in the handshake,
>
> with
>
> no certificate lifetime or revocation check doing the work.
>
> The profile is attached. Happy to refine toward a draft and present at IETF 127 if useful.
>
> Thi
>
> Thi Nguyen-Huu
>
> Founder & CEO, WinMagic Corp.
>
> [e-mail]<mailto:[e-mail]>
>
> Reference implementation: [[[github.com/WinMagic/LIT](http://github.com/WinMagic/LIT)]([http://github.com/WinMagic/LIT%5D(http://github.com/WinMagic/LIT))](http://github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT)%5D(http:/github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT))](http://github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT))%5D(http:/github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT)%5D(http:/github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT))))<http://github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT)%5D(%5Bhttp:/github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT))%5D(http:/github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT)%5D(http:/github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT))%5D(http:/github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT))%5D(http:/github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT)%5D(http:/github.com/WinMagic/LIT%5D(http:/github.com/WinMagic/LIT))))>
>
> –
>
> WIMSE mailing list – [e-mail]<mailto:[e-mail]>
>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>
> –
>
> WIMSE mailing list – [e-mail]<mailto:[e-mail]>
>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>
> –
>
> WIMSE mailing list – [e-mail]<mailto:[e-mail]>
>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>
> –
>
> Iman Schrock
>
> Founder
>
> EMILIA Protocol
>
> [emiliaprotocol.ai<http://emiliaprotocol.ai>](http://emiliaprotocol.ai/) | [e-mail]<mailto:[e-mail]>