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

[morganLR <[e-mail]>]

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]