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

[KARTHIK RAMPALLI <[e-mail]>]

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]> 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]> 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] 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] 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.
>>    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]
>>
>> Sent: Sunday, July 5, 2026 12:09 AM
>>
>> To: Iman Schrock [e-mail]
>>
>> Cc: [e-mail]; Thi Nguyen-Huu [e-mail];
>> [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]. 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]
>> 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] 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]
>> 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]
>> 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] 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] 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] 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]
>> 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]
>>
>> Sent: Monday, June 22, 2026 9:22 PM
>>
>> To: Thi Nguyen-Huu [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.
>>
>> 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]
>> 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]
>>
>> Sent: Monday, 22 June 2026 12:12:35
>>
>> To: Songbo Bu [e-mail];
>>
>> [e-mail] [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].
>>
>> 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]
>>
>> Sent: Monday, 22 June 2026 11:31:57
>>
>> To: Thi Nguyen-Huu [e-mail];
>>
>> [e-mail] [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]. 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]
>> 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] |
>>
>> [[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)
>>
>> -----Original Message-----
>>
>> From: Songbo Bu [e-mail]
>>
>> Sent: Sunday, June 21, 2026 11:33 PM
>>
>> To: [e-mail]
>>
>> Subject: [WIMSE] Condition-bounded credential profile for WIMSE — no
>> rotation, no cert lifecycle
>>
>> [You don’t often get email from [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] 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]
>>
>> Reference implementation: [[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))>
>> )
>>
>> –
>>
>> WIMSE mailing list – [e-mail]
>>
>> To unsubscribe send an email to [e-mail]
>>
>> –
>>
>> WIMSE mailing list – [e-mail]
>>
>> To unsubscribe send an email to [e-mail]
>>
>> –
>>
>> WIMSE mailing list – [e-mail]
>>
>> To unsubscribe send an email to [e-mail]
>>
>> –
>>
>> Iman Schrock
>>
>> Founder
>>
>> EMILIA Protocol
>>
>> emiliaprotocol.ai | [e-mail]
>>
>>