[WIMSE] Re: New draft: Cross-Organizational Delegation for Workload and Agent Identity

[KARTHIK RAMPALLI <[e-mail]>]

Thanks Iman.

On Tue, Jul 7, 2026 at 5:42 AM Iman Schrock <[e-mail]> wrote:

> Karthik, Morgan,
>
> The gradient as a field each row states and each artifact declares is the
> right move, and it is the one that turns this from prose a reader has to
> reconstruct into something a verifier reads directly. EP already carries
> it, which is why I can offer a populated column rather than a promise.
> Every EP acceptance declares two things: where its root sits, general
> infrastructure for verification and a pinned root for acceptance, reported
> as separate fields so the position between first encounter and established
> relationship is never hidden inside one boolean; and the consequence tier
> it operates at, an explicit required_assurance level (software, a Class-A
> device key with user verification, or an M-of-N human quorum) plus, for
> evidence sufficiency, a relying-party-pinned admissibility-profile hash
> whose bar rises with consequence. A minimal shape for the field is in the
> crosswalk I posted, offered as input to the definition you would put in the
> requirements rather than something to fix here.
>
> On continuity, Morgan's framing is the precise one: the first-contact pin
> is paid once and amortized across rotations, not eliminated, and it stays a
> genuine prior arrangement for the initial high-consequence interaction.
> Karthik's honest gap is worth separating by layer. At the root-anchor level
> the amortization is already carried:
> draft-schrock-ep-authority-introduction serves a hash-chained authority
> document with continuity signatures from the organization's origin, so the
> root anchor's pin survives key rotation with no new leap. The per-hop
> version, carrying that continuity down the delegation chain, is the
> PEDIGREE provisioning item you name, and it sits a layer below the root
> pin, not in place of it.
>
> On sequencing, that works. I will keep the WHO and human-authorization
> rows citing R2 as written in reece-00 and point them at the
> acquisition-and-binding framing, the first-contact security consideration,
> and the gradient definition once your revised requirements draft posts
> after Vienna, rather than race it.
>
> Iman
>
> On Mon, Jul 06, 2026 10:24 AM, morganLR <[e-mail]> wrote:
>
>> Iman,
>>
>> Thank you, and agreed on the split reading and on leaving R2 as it
>> stands. Your continuity point is the right refinement to the security
>> consideration, and I would like to fold it in. It bounds the cost of the
>> residual rather than changing R2: once the first-contact pin is taken, a
>> hash-chained authority document with continuity signatures carries the
>> binding across key rotation with no new leap and no new arrangement, so the
>> residual is paid once and amortized across subsequent interactions rather
>> than renewed. That places a repeated relationship lower on the gradient
>> than a first encounter, which is a more precise statement than my current
>> wording. I will note it next to the security consideration, with the
>> qualification that the first-contact pin, though paid only once, remains a
>> genuine prior arrangement for that initial high-consequence interaction, so
>> the residual is amortized rather than eliminated.
>>
>> Morgan
>> On Monday, July 6th, 2026 at 10:37 AM, Iman Schrock <
>> [e-mail]> wrote:
>>
>> Morgan, Karthik,
>>
>> This reads right. Splitting acquisition of the anchor from binding of the
>> anchor to the organization, and moving the irreducible part into a security
>> consideration, turns R2 from a bar every construction appears to miss into
>> a clean pass or fail. Authority-introduction-00 lands on that gradient
>> exactly as you frame it: general infrastructure for the channel, since it
>> harvests the roots that already exist with no mandatory apex and no
>> bilateral gate, and for high-consequence actions the relying party pins the
>> originating anchor itself, which is the stronger root your security
>> consideration names.
>>
>> One companion worth a line where the residual lives, because it bounds
>> the residual's cost rather than changing R2: continuity. Once the
>> first-contact pin is taken, the hash-chained authority document and the
>> continuity signatures carry the binding across key rotation with no new
>> leap and no new bilateral arrangement. The prior arrangement is paid once
>> at first contact, not re-paid per interaction. So a repeated relationship
>> sits lower on the gradient than "tends toward a prior relationship" reads:
>> the residual is amortized to a single pin, not renewed. I would leave R2 as
>> you have it and note this next to the security consideration.
>>
>> Iman
>>
>> On Mon, Jul 06, 2026 08:08 AM, morganLR <[e-mail]> wrote:
>>
>>> Karthik, Iman, all,
>>>
>>> The mapping exercise has surfaced something about R2 worth making
>>> explicit in the requirement itself, rather than leaving to each cell to
>>> rediscover. Three different constructions now reduce to the same shape: a
>>> general channel for anchor acquisition, and a first-contact binding that
>>> roots in some shared general infrastructure and does not go to zero. That
>>> convergence is not a coincidence of the mechanisms; it is a property of
>>> first-contact trust. Two parties with no shared prior root of any kind
>>> cannot bootstrap authenticated trust between them. So R2 was never going to
>>> forbid all prior trust; what it forbids, and should say it forbids, is the
>>> bespoke bilateral arrangement specific to the interaction. General
>>> infrastructure that each party joined independently is not only permitted,
>>> it is necessary.
>>>
>>> I would like to tighten R2 to say exactly that, and to move the
>>> irreducible part into a security consideration where it belongs. This does
>>> not weaken R2; it makes it a clean pass/fail line instead of a bar every
>>> construction appears to miss. Proposed text below, offered for the list per
>>> the usual discipline.
>>>
>>> Proposed R2 (replacement):
>>>
>>> R2 (Cross-organizational verification). A relying party in one
>>> organization MUST be able to verify authority that originated under another
>>> organization's trust anchor without any arrangement specific to the
>>> interaction or specific to the counterparty. Verification MAY rely on
>>> general trust infrastructure that each party adopts independently of the
>>> other, such as a public key infrastructure, an open transparency log, a
>>> permissionless verifiable data registry, or a credential from a recognized
>>> issuer. A mechanism satisfies R2 when the relying party can obtain and
>>> verify the originating anchor, and can establish that anchor's binding to
>>> the originating organization, through such general mechanisms alone, with
>>> no bilateral or consortium arrangement negotiated for or admitting the two
>>> parties to the specific interaction. A mechanism does not satisfy R2 when
>>> either the acquisition of the anchor or the binding of the anchor to the
>>> originating organization requires a prior arrangement between the two
>>> parties, or admission to a governance framework that gates the interaction,
>>> since such an arrangement is the bilateral agreement R2 excludes, relocated
>>> into provisioning or membership.
>>>
>>> Explanatory note (for the row, not the requirement text):
>>>
>>> R2 separates two things a relying party needs on first contact:
>>> acquisition of the originating anchor (the channel), and binding of that
>>> anchor to the originating organization (the binding). The channel is met by
>>> any general, non-gatekept mechanism, and current constructions meet it. The
>>> binding always roots in some shared general infrastructure, which is
>>> permitted; what is excluded is a root that is bilateral or that admits the
>>> two parties to the specific interaction. Reliance on general infrastructure
>>> is not a failure of R2, it is how R2 is met, because some shared general
>>> root is a precondition for authenticated first contact and cannot be
>>> removed.
>>>
>>> Proposed new Security Consideration (the residual):
>>>
>>> Irreducibility of the first-contact root. No mechanism establishes trust
>>> between two parties who share no prior root of any kind. Authenticated
>>> verification of a stranger's anchor requires that both parties
>>> independently rely on some common general infrastructure, and the assurance
>>> of the binding is bounded by the assurance of that infrastructure: a domain
>>> binding is worth what the public key infrastructure and naming system are
>>> worth, a transparency-log inclusion is worth what the log operator is
>>> worth, an endorsement is worth nothing until the relying party has
>>> independently pinned the endorser. This residual cannot be discharged to
>>> zero. Its consequence is that assurance SHOULD be graded by the consequence
>>> of the action: a relying party MAY accept general-infrastructure binding
>>> alone for low-consequence actions, and SHOULD require a stronger root, such
>>> as a pre-pinned endorsement or a pre-established credential, for
>>> high-consequence actions, accepting that such a stronger root is itself a
>>> mild prior arrangement. The more consequential the action, the closer
>>> first-contact trust tends toward a prior relationship. This tension is a
>>> property of trust, not a deficiency of any particular mechanism, and a
>>> conforming solution documents where on this gradient it operates rather
>>> than claiming to eliminate the residual.
>>> Morgan
>>> On Sunday, July 5th, 2026 at 11:12 AM, Iman Schrock <
>>> [e-mail]> wrote:
>>>
>>> Morgan, Karthik, all,
>>>
>>> Morgan, thank you for re-reading the draft before writing the row. Your
>>> R2 text is a more precise statement of what authority-introduction-00 does
>>> than our own summary language was, and the residual sentence is the one I
>>> want carried forward: first contact made checkable, not eliminated. Section
>>> 7 stays that plain as the draft evolves. If a future revision ever reads as
>>> claiming more than that, treat it as a bug and say so here.
>>>
>>> The maintenance split works for me: you keep R1 through R9 responsive,
>>> Karthik keeps the table, and I keep the human-authorization row honest,
>>> corrections through this list.
>>>
>>> Glad to be building this with you both as well.
>>>
>>> Iman Schrock
>>> EMILIA Protocol
>>>
>>> On Sun, Jul 05, 2026 05:38 AM, KARTHIK RAMPALLI <
>>> [e-mail]> wrote:
>>>
>>>> Hi Morgan, thank you.
>>>>
>>>> Your row text is in verbatim: -03 is posted, with your three cells and
>>>> the row note superseding the interim wording, marked as contributed by the
>>>> requirements author. The one edit is citation formatting: the draft-name
>>>> token was too wide for the table column, so the cell says "the
>>>> authority-introduction companion draft" and the formal citation lives in
>>>> the row note. Everything else is your text, word for word.
>>>>
>>>> Your residual sentence is now the most useful line in the document:
>>>> first contact made checkable, not eliminated. It gives both layers the same
>>>> honest target for their next revisions, and it gives a verifier a one-line
>>>> answer to what the table does and does not promise. Iman, Section 7 saying
>>>> it plainly is what made it recordable at all.
>>>>
>>>> On maintenance: agreed on the division of labor. You keep R1 through R9
>>>> responsive as the mechanisms evolve, the suppliers keep their layers
>>>> honest, and I keep the table current through this list, with each revision
>>>> naming who contributed what. If the chairs grant the PEDIGREE slot at 126,
>>>> this table and its two named residuals (the first-contact bootstrap on R2,
>>>> fail-closed-on-stale on R7 until pedigree-02 posts) are what I intend to
>>>> put in front of the room.
>>>>
>>>> Karthik Rampalli
>>>> Glyphzero, Inc.
>>>>
>>>> On Sun, Jul 5, 2026 at 8:28 PM morganLR <[e-mail]> wrote:
>>>>
>>>>> Karthik, Iman, all,
>>>>>
>>>>> Thank you both. I re-read draft-schrock-ep-authority-introduction-00
>>>>> before sending this to confirm my thoughts, and it specifies what the
>>>>> thread described: a signed, hash-chained authority document served from the
>>>>> organization's origin and registrable to a transparency log, normative
>>>>> continuity on rotation, keys resolved at time of issuance, and acceptance
>>>>> graded per action class over introduction evidence. That is the right kind
>>>>> of move. It takes the load-bearing part of R2, how a relying party comes to
>>>>> trust an originating anchor with no prior arrangement, and makes it
>>>>> checkable rather than assumed, through a general mechanism that needs no
>>>>> per-counterparty negotiation.
>>>>>
>>>>> It does not, and the draft says so plainly in Section 7, create trust
>>>>> from nothing. First contact remains a leap: domain binding is worth what
>>>>> Web PKI is worth, log consistency is worth what the log operator is worth,
>>>>> endorsements are worth nothing until the relying party has pinned one. So
>>>>> R2 is narrowed and made explicit on both layers, not discharged.
>>>>>
>>>>> Here is my proposed row text that records that honestly. It supersedes
>>>>> the interim wording in the chain and root cells and is subordinate to the
>>>>> mapping's discipline; if it reads as too strict, the open verdict stands,
>>>>> which is the column doing its job.
>>>>>
>>>>> R2 chain cell (PEDIGREE):
>>>>> Conditional: met only when the deployment pins a general anchor-trust
>>>>> mechanism usable by any party without per-counterparty negotiation. A
>>>>> general channel is named as one conforming way but not required, and static
>>>>> per-counterparty provisioning is admitted, which relocates rather than
>>>>> discharges R2. Same profile move as R1 inline conveyance.
>>>>>
>>>>> R2 root cell (EP):
>>>>> Conditional, mechanism specified
>>>>> (draft-schrock-ep-authority-introduction-00, Informational, public
>>>>> implementation with tests). Authority Document: signed, hash-chained,
>>>>> sequence-numbered key declaration served from the org origin and
>>>>> registrable to a transparency log; rotations carry a normative continuity
>>>>> signature (MUST be flagged if absent), and artifacts resolve the key valid
>>>>> at issuance. Acceptance is graded per action class over introduction
>>>>> evidence (chain consistency, domain binding, transparency-log inclusion and
>>>>> age, pinned-anchor endorsements), widening mechanically as history accrues
>>>>> with no relying-party reconfiguration. Residual, admitted in the draft:
>>>>> first contact is made checkable, not eliminated. Met for lower-consequence
>>>>> classes; high-consequence cross-org actions between parties with no shared
>>>>> pinned anchor or logged history remain open.
>>>>>
>>>>> R2 composition cell:
>>>>> Both layers name general, non-bilateral mechanisms, served from the
>>>>> org origin and transparency-logged, and state the assumption explicitly,
>>>>> narrowing R2. Shared residual: the first-contact bootstrap, coming to trust
>>>>> an originating anchor for an organization with no prior arrangement.
>>>>> Narrowed, explicit open item, not a satisfied assumption.
>>>>>
>>>>> Row note:
>>>>>
>>>>> R2, cross-organizational verification. Reframed per a correction from
>>>>> the requirements author: pinning the originating anchor relocates the
>>>>> assumption rather than discharging it; the load-bearing part is how the
>>>>> relying party comes to trust that anchor. R2 is met only when the anchor
>>>>> arrives through a general mechanism any party can use without
>>>>> per-counterparty negotiation (public transparency log, open federation,
>>>>> verifiable credential from a recognized issuer, or trust-domain discovery),
>>>>> and the row names the mechanism. An anchor arranged in advance between the
>>>>> two organizations moves the forbidden bilateral agreement into the
>>>>> provisioning step.
>>>>>
>>>>> Both layers have moved from bare open items toward explicit
>>>>> mechanisms. The chain layer names a general channel but does not require it
>>>>> and admits static provisioning, so its verdict is conditional on pinning a
>>>>> general mechanism. The root layer specifies one
>>>>> (draft-schrock-ep-authority-introduction-00): a signed, hash-chained
>>>>> authority document served from the org origin and transparency-logged, with
>>>>> normative continuity on rotation, keys resolved at issuance, and graded
>>>>> per-action-class acceptance in which un-pinned issuers never receive full
>>>>> acceptance and high-consequence actions still require a pinned anchor.
>>>>>
>>>>> Both narrow R2 honestly and make the residual explicit. The shared
>>>>> residual is the first-contact bootstrap: domain binding is worth what Web
>>>>> PKI is worth, log consistency is worth what the log operator is worth, and
>>>>> endorsements are worth nothing until the relying party pins one, so trust
>>>>> is not created from nothing. R2 is therefore conditional and narrowed, met
>>>>> for lower-consequence classes when a general channel is pinned, with the
>>>>> high-consequence cross-org bootstrap an explicit open item, not a satisfied
>>>>> assumption.
>>>>> Lastly, thank you for the authorship credit and for keeping the
>>>>> requirements framing central to how this table reads. Having R1 through R9
>>>>> serve as the shared test the candidates are measured against, with
>>>>> corrections folded in through this list, is exactly the collaboration I
>>>>> hoped for when I put the requirements forward. I am glad to be building
>>>>> this with both of you, and I will keep the requirements maintained and
>>>>> responsive as the mechanisms on both layers evolve.
>>>>>
>>>>>
>>>>> Morgan
>>>>>
>>>>> On Saturday, July 4th, 2026 at 11:49 PM, KARTHIK RAMPALLI <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>
>>>>> Iman, thank you, and the correction is accepted with the mapping's own
>>>>> verification step applied first: I read the companion draft before
>>>>> crediting the edge, and the bytes back it. The continuity rule is normative
>>>>> ("a rotation without valid continuity MUST be flagged, never silently
>>>>> accepted"), keys resolve at time of issuance so rotation never invalidates
>>>>> previously issued evidence, acceptance is graded per action class rather
>>>>> than boolean, and the reference implementation and test suite are public.
>>>>> The cell you propose is a fair statement of what the draft specifies.
>>>>>
>>>>> One precision that makes the symmetry exact rather than rhetorical:
>>>>> the residual you state plainly is also admitted in the draft itself, which
>>>>> calls the genesis-digest channel its one leap of faith and leaves it
>>>>> unspecified. That lands the root cell in precisely the same shape as the
>>>>> chain cell: each layer is conditional on the deployment pinning one general
>>>>> channel for one initial digest, and the shared open item narrows to that
>>>>> channel. Morgan's test is still doing the work; it just now has a named
>>>>> mechanism to test on both sides.
>>>>>
>>>>> So the next revision carries your cell, trimmed to table width with
>>>>> the full statement in the row note, marked as recorded per the supplier's
>>>>> correction and subordinate to Morgan's row text where they overlap. Morgan,
>>>>> R2 is your requirement: if your row text or a verdict on this mechanism
>>>>> arrives before Monday's cutoff, the revision posts before Vienna with both
>>>>> folded in; otherwise it follows after the meeting, and the -02 text stands
>>>>> in front of the room with the open verdict, which, as Iman says, the column
>>>>> exists to be able to say.
>>>>>
>>>>> Karthik Rampalli
>>>>> Glyphzero, Inc.
>>>>>
>>>>> On Sun, Jul 5, 2026 at 1:23 PM Iman Schrock <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Karthik, Morgan, all,
>>>>>>
>>>>>> The -02 reframe is right, and Morgan's test is the one to keep:
>>>>>> pinning relocates the assumption, and the load-bearing part is how the
>>>>>> relying party comes to trust the pinned anchor. No dispute with any of that.
>>>>>>
>>>>>> Here is the correction the -02 root cell invites. The provisioning
>>>>>> mechanism is out of scope for the binding draft as posted, deliberately. It
>>>>>> is supplied by a different draft in the same cluster:
>>>>>> draft-schrock-ep-authority-introduction-00, posted alongside the binding
>>>>>> draft.
>>>>>>
>>>>>> What it specifies, against Morgan's test:
>>>>>>
>>>>>> 1. The anchor is a hash-chained authority document with continuity
>>>>>> signatures. The chain is self-authenticating from its genesis digest, so
>>>>>> any party can obtain it through any general channel (the issuer, a mirror,
>>>>>> a transparency log, a federation directory) and verify continuity offline,
>>>>>> with keys resolved at time of issuance. No step is negotiated per
>>>>>> counterparty.
>>>>>>
>>>>>> 2. An issuer the relying party has not pinned does not become trusted
>>>>>> by being introduced. Introduction is evidence, not a bypass: it enters the
>>>>>> decision under the relying party's own policy, graded by who endorses it
>>>>>> and graded per action class. Introduced-level trust can clear a
>>>>>> low-consequence operation while a wire transfer still requires a pinned
>>>>>> anchor. Reference implementation and tests are public.
>>>>>>
>>>>>> The residual, stated plainly: the genesis digest still has to reach
>>>>>> the relying party through some general channel, and no mechanism discharges
>>>>>> that to zero. The claim is narrower than solved: the assumption is
>>>>>> explicit, the channel is general rather than bilateral, and acceptance is
>>>>>> graded rather than binary, so per-counterparty provisioning becomes
>>>>>> optional.
>>>>>>
>>>>>> Suggested root cell for the next revision, entirely your call and
>>>>>> subordinate to Morgan's row text where they overlap: "Conditional,
>>>>>> mechanism specified: anchor provisioning via hash-chained authority
>>>>>> documents with continuity signatures plus graded introduction evidence
>>>>>> (draft-schrock-ep-authority-introduction-00, individual draft, implemented
>>>>>> with public tests). Met when the deployment pins a general channel for the
>>>>>> genesis digest, the same profile move as the chain side; introduced, not
>>>>>> pinned, issuers receive graded acceptance per relying-party policy and
>>>>>> action class, never full acceptance. Residual assumption stated, bilateral
>>>>>> provisioning optional."
>>>>>>
>>>>>> If that satisfies neither the requirements author nor the mapping's
>>>>>> discipline, the open verdict stands and should. The point of the column is
>>>>>> that it can say so.
>>>>>>
>>>>>> Dr. I
>>>>>>
>>>>>> On Thu, Jul 02, 2026 03:07 PM, morganLR <morganLR=
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> Agreed: this is squarely the kind of concrete candidate the
>>>>>>> requirements are meant to let us evaluate, so I'm glad it's being put
>>>>>>> forward that way.
>>>>>>>
>>>>>>> On the second point, I want to make sure I engage the right concern
>>>>>>> rather than guess. If you're flagging that leaning on Security Event Tokens
>>>>>>> to satisfy the revocation and audit requirements (R7, R8) would amount to
>>>>>>> importing a specific defined architecture, that's a fair thing to hold the
>>>>>>> requirements to. The intent is the opposite: R7 and R8 are meant to be
>>>>>>> satisfiable without mandating SET, or any single mechanism — a SET-based
>>>>>>> approach should be one conforming way to meet them, not a presupposition
>>>>>>> baked into the requirement text. If any of the wording reads as smuggling
>>>>>>> in an architecture, I'd genuinely like to fix that, since
>>>>>>> mechanism-neutrality is the whole point of framing it as requirements.
>>>>>>>
>>>>>>> Is that the tension you're pointing at, or did you mean something
>>>>>>> more specific by "defined architecture"? Happy to go deeper once I'm sure
>>>>>>> I've got your actual point.
>>>>>>>
>>>>>>> -Morgan
>>>>>>>
>>>>>>> On Thursday, July 2nd, 2026 at 4:35 PM, Michael Debus <
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>> Iman,
>>>>>>> More "exactly" the kind of canidate than ~Morgan can understand.
>>>>>>> Perhaps...
>>>>>>> A+ Iman -On your logic. But the SET additional requirement equate
>>>>>>> "defined architecture" I suppose...
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 2, 2026, 3:06 PM morganLR <morganLR=
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>>> Thanks, Iman — this is exactly the kind of concrete candidate the
>>>>>>>> requirements framing was meant to invite, and I appreciate you scoping the
>>>>>>>> claim so precisely rather than asserting general coverage.
>>>>>>>>
>>>>>>>> I want to take you up on the offer to map it against R1-R9, with
>>>>>>>> one framing I'd like to keep in place: I'd rather run this as "how does
>>>>>>>> this candidate satisfy each requirement" than as a conclusion that any
>>>>>>>> single receipt design settles the requirements it touches. Concretely, I
>>>>>>>> believe it would be beneficial if the mapping were explicit about which
>>>>>>>> requirements are met *offline and unconditionally* versus which depend on
>>>>>>>> additional assumptions (issuer key distribution, validity-window semantics,
>>>>>>>> observed-evidence freshness). Surfacing those conditions per-requirement is
>>>>>>>> most of the value the requirements draft is trying to provide.
>>>>>>>>
>>>>>>>> On the architecture point: I agree with the separation, and I think
>>>>>>>> it's worth stating carefully. Keeping "which workload is calling" distinct
>>>>>>>> from "did a named human authorize this exact action" is a real and useful
>>>>>>>> distinction, and the requirements should reflect that these are different
>>>>>>>> trust roots. Where I'd want to be careful is not collapsing the
>>>>>>>> human-authorization layer into a single design prematurely — the
>>>>>>>> requirements should hold for that layer independent of whether a given
>>>>>>>> receipt format is the one that fills it.
>>>>>>>>
>>>>>>>> The dimension I'd most like to see reflected in any candidate
>>>>>>>> mapping is cross-domain independence — the case where the verifying
>>>>>>>> organization and the issuing organization are genuinely distinct trust
>>>>>>>> domains, with no shared operator. Several of the requirements (R3 on local
>>>>>>>> verification, R7 on cross-domain revocation/freshness, R8 on composable
>>>>>>>> audit) behave differently once the second party isn't run by the issuer,
>>>>>>>> and that boundary is where I think the interesting requirements pressure
>>>>>>>> actually lives. It would be useful to map the candidate against those
>>>>>>>> requirements specifically under a no-shared-operator assumption.
>>>>>>>>
>>>>>>>> I'd also welcome the same requirements-mapping treatment of other
>>>>>>>> approaches in this space — e.g., the delegation-receipt work addressing the
>>>>>>>> user-to-operator layer — so the group can compare coverage and gaps across
>>>>>>>> candidates rather than evaluating any one in isolation. If you produce the
>>>>>>>> R1-R9 mapping as a proof-of-concept, I'm happy to fold it into the
>>>>>>>> requirements discussion in that comparative frame.
>>>>>>>>
>>>>>>>> -Morgan
>>>>>>>> On Tuesday, June 30th, 2026 at 12:57 AM, Iman Schrock <team=
>>>>>>>> [e-mail]> wrote:
>>>>>>>>
>>>>>>>> Morgan — thanks for framing this requirements-first; it makes the
>>>>>>>> gaps legible without prejudging a solution.
>>>>>>>>
>>>>>>>> Several of the requirements line up closely with an artifact we've
>>>>>>>> been building, and I wanted to offer it as a concrete candidate rather than
>>>>>>>> abstract agreement — specifically:
>>>>>>>>
>>>>>>>> - local verification without a real-time callback to the source org
>>>>>>>> - binding to the originating principal
>>>>>>>> - cross-domain revocation / freshness
>>>>>>>> - composable audit
>>>>>>>>
>>>>>>>> When the originating principal is a *human* authorizing an
>>>>>>>> *irreversible* action, an offline-verifiable authorization receipt
>>>>>>>> satisfies these directly: an Ed25519 signature over RFC 8785 (JCS)
>>>>>>>> canonical JSON binding the named principal to the exact action. A relying
>>>>>>>> org verifies it with the issuer's public key alone — no callback to the
>>>>>>>> source domain (local verification); the signature itself is the binding to
>>>>>>>> the originating principal; a validity window plus observed-evidence
>>>>>>>> freshness covers revocation/freshness offline; and because each receipt is
>>>>>>>> a self-contained signed object, chaining them gives composable audit across
>>>>>>>> domains.
>>>>>>>>
>>>>>>>> We've published this as an individual I-D,
>>>>>>>> draft-schrock-ep-authorization-receipts (Apache-2.0; reference verifiers in
>>>>>>>> JavaScript, Python, and Go that agree on shared conformance vectors). I'm
>>>>>>>> not putting it forward as the answer to the whole delegation problem — it's
>>>>>>>> specifically the human-authorization-of-an-irreversible-action slice,
>>>>>>>> designed to compose with workload identity rather than replace it. If it's
>>>>>>>> useful to the requirements discussion, I'm happy to map it explicitly
>>>>>>>> against R1–R9 as a proof-of-concept.
>>>>>>>>
>>>>>>>> One framing note that may help keep scope clean: it's worth
>>>>>>>> treating that human-authorization slice as a separable layer above workload
>>>>>>>> identity — it keeps "which workload is calling" and "did a named human
>>>>>>>> authorize this exact action" from being conflated, which are different
>>>>>>>> trust roots.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Iman Schrock
>>>>>>>> EMILIA Protocol · [e-mail]
>>>>>>>> draft-schrock-ep-authorization-receipts
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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]
>>>>>>>
>>>>>>
>>>>>
>>>
>>