MIME-Version: 1.0
References: 
 <CAOfgHgoZ98F_io1dqn+72JZwtD1VcBDo1tbrAuVKBfQAJ84v5A@mail.gmail.com>
 <W6TEUjyOhl62tzh7JCxTqSpO0hxtJ0JjqR84sKct12X9AwguTvYw9gNPsxLmsI2VUCuXmW7rr3B6C2o1_iOXiN5QrFrOrr0S1u3cY0qGlPs=@proton.me>
 <CAOfgHgo5N-722WG3wasROXSce7iF8cJhuCWLbaq6ko3dFkgJ+A@mail.gmail.com>
 <CAGVw8=00YqWuGScq6jyn2q0+7yyPay-CzU7bSkj_xd_FchYBFw@mail.gmail.com>
 <3TX2HtZNlZ34E85PcMbDaSEEBLMDPYzbIo1byl3AQ96G_tNfxVcyFnj261bOVimio5dZHagLmIeRUGXLFcpzgMEYXYd9QSY-2pK2wBdDq_0=@proton.me>
 <CAGVw8=3JfgXN636LdK=bmFwaB5K_cr5i-g4VTGW1tCv5xuFq0w@mail.gmail.com>
 <CAOfgHgrimB+RDQ0JMG+bv68W_+M5gucFZYvoo2w3EXbVefCzWQ@mail.gmail.com>
 <cx0RccrvLQxCoukoBSNGy0ySYUwSY3PaSvTp7cwa07V6xVqY26UkRalwdIpWKzM4xA7F1RMkysdCNnbxPnTeJWk2PrMTBaUYGix8vbXc4Ew=@proton.me>
 <CAOfgHgpPsYLFfW2uNtLD+J3TLCL9qsum0AB_TefMPs6-vCRRaw@mail.gmail.com>
 <wG_8_C6tuTuyvx1jNvO8NX1dQVafPR6N8ly5V4nPWh5TZ5GiOmN24k68tHxm1GDLuDY8Vdo5sbUkOfV_PdNAI7DeZY7BvVA4yfeKQc8qIEg=@proton.me>
 <CAOfgHgokv2XPkA08hWcLJjehgUFqsfK0ib6cmUDZE0BgYDjVyQ@mail.gmail.com>
In-Reply-To: 
 <CAOfgHgokv2XPkA08hWcLJjehgUFqsfK0ib6cmUDZE0BgYDjVyQ@mail.gmail.com>
From: KARTHIK RAMPALLI <karthik@glyphzerolabs.com>
Date: Tue, 7 Jul 2026 06:13:59 +0900
Message-ID: 
 <CAGVw8=10HW4dMgZkU=3VY=a10r_0bQKNZUEGiXUU6i4n9mjmSA@mail.gmail.com>
To: Iman Schrock <team@emiliaprotocol.ai>
Content-Type: multipart/alternative; boundary="0000000000006b5b8a0655f7c106"
Message-ID-Hash: DCQUGRV65SH2HJ2OPQCL3NW2CGNNE7PU
CC: morganLR@proton.me, wimse@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BWIMSE=5D_Re=3A_New_draft=3A_Cross-Organizational_Delegation_for?=
 =?utf-8?q?_Workload_and_Agent_Identity?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/wimse/zdoj59f7U7uaDSXfWcNQw69NRVs>

--0000000000006b5b8a0655f7c106
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Iman.

On Tue, Jul 7, 2026 at 5:42=E2=80=AFAM Iman Schrock <team@emiliaprotocol.ai=
> 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, reporte=
d
> as separate fields so the position between first encounter and establishe=
d
> 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 t=
he
> 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 lev=
el
> 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 th=
e
> 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 <morganLR@proton.me> 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 rathe=
r
>> than renewed. That places a repeated relationship lower on the gradient
>> than a first encounter, which is a more precise statement than my curren=
t
>> 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 <
>> team@emiliaprotocol.ai> wrote:
>>
>> Morgan, Karthik,
>>
>> This reads right. Splitting acquisition of the anchor from binding of th=
e
>> anchor to the organization, and moving the irreducible part into a secur=
ity
>> consideration, turns R2 from a bar every construction appears to miss in=
to
>> a clean pass or fail. Authority-introduction-00 lands on that gradient
>> exactly as you frame it: general infrastructure for the channel, since i=
t
>> 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 onc=
e
>> at first contact, not re-paid per interaction. So a repeated relationshi=
p
>> sits lower on the gradient than "tends toward a prior relationship" read=
s:
>> 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 <morganLR@proton.me> 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 tha=
t
>>> roots in some shared general infrastructure and does not go to zero. Th=
at
>>> 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 goin=
g 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 permitt=
ed,
>>> 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 d=
oes
>>> not weaken R2; it makes it a clean pass/fail line instead of a bar ever=
y
>>> 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 ano=
ther
>>> 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 th=
e
>>> other, such as a public key infrastructure, an open transparency log, a
>>> permissionless verifiable data registry, or a credential from a recogni=
zed
>>> 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, wi=
th
>>> no bilateral or consortium arrangement negotiated for or admitting the =
two
>>> parties to the specific interaction. A mechanism does not satisfy R2 wh=
en
>>> either the acquisition of the anchor or the binding of the anchor to th=
e
>>> originating organization requires a prior arrangement between the two
>>> parties, or admission to a governance framework that gates the interact=
ion,
>>> since such an arrangement is the bilateral agreement R2 excludes, reloc=
ated
>>> 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 tha=
t
>>> anchor to the originating organization (the binding). The channel is me=
t 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 infrastruc=
ture
>>> is not a failure of R2, it is how R2 is met, because some shared genera=
l
>>> 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 trus=
t
>>> 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 assur=
ance
>>> of the binding is bounded by the assurance of that infrastructure: a do=
main
>>> binding is worth what the public key infrastructure and naming system a=
re
>>> 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 t=
o
>>> zero. Its consequence is that assurance SHOULD be graded by the consequ=
ence
>>> of the action: a relying party MAY accept general-infrastructure bindin=
g
>>> 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 <
>>> team@emiliaprotocol.ai> 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 d=
oes
>>> than our own summary language was, and the residual sentence is the one=
 I
>>> want carried forward: first contact made checkable, not eliminated. Sec=
tion
>>> 7 stays that plain as the draft evolves. If a future revision ever read=
s 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 <
>>> karthik@glyphzerolabs.com> 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-na=
me
>>>> 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 sa=
ying
>>>> it plainly is what made it recordable at all.
>>>>
>>>> On maintenance: agreed on the division of labor. You keep R1 through R=
9
>>>> responsive as the mechanisms evolve, the suppliers keep their layers
>>>> honest, and I keep the table current through this list, with each revi=
sion
>>>> 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=E2=80=AFPM morganLR <morganLR@proton.me> w=
rote:
>>>>
>>>>> 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 fr=
om the
>>>>> organization's origin and registrable to a transparency log, normativ=
e
>>>>> continuity on rotation, keys resolved at time of issuance, and accept=
ance
>>>>> 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 co=
mes 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 w=
hat
>>>>> Web PKI is worth, log consistency is worth what the log operator is w=
orth,
>>>>> 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 supersede=
s
>>>>> 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 sta=
nds,
>>>>> 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 tha=
n
>>>>> 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 contin=
uity
>>>>> 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 inclusi=
on and
>>>>> age, pinned-anchor endorsements), widening mechanically as history ac=
crues
>>>>> with no relying-party reconfiguration. Residual, admitted in the draf=
t:
>>>>> first contact is made checkable, not eliminated. Met for lower-conseq=
uence
>>>>> classes; high-consequence cross-org actions between parties with no s=
hared
>>>>> 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 explicit=
ly,
>>>>> 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 t=
he
>>>>> relying party comes to trust that anchor. R2 is met only when the anc=
hor
>>>>> arrives through a general mechanism any party can use without
>>>>> per-counterparty negotiation (public transparency log, open federatio=
n,
>>>>> verifiable credential from a recognized issuer, or trust-domain disco=
very),
>>>>> and the row names the mechanism. An anchor arranged in advance betwee=
n 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 requ=
ire it
>>>>> and admits static provisioning, so its verdict is conditional on pinn=
ing 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 grad=
ed
>>>>> 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 t=
rust
>>>>> 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 sat=
isfied
>>>>> assumption.
>>>>> Lastly, thank you for the authorship credit and for keeping the
>>>>> requirements framing central to how this table reads. Having R1 throu=
gh 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 buildi=
ng
>>>>> this with both of you, and I will keep the requirements maintained an=
d
>>>>> responsive as the mechanisms on both layers evolve.
>>>>>
>>>>>
>>>>> Morgan
>>>>>
>>>>> On Saturday, July 4th, 2026 at 11:49 PM, KARTHIK RAMPALLI <
>>>>> karthik@glyphzerolabs.com> wrote:
>>>>>
>>>>>
>>>>> Iman, thank you, and the correction is accepted with the mapping's ow=
n
>>>>> verification step applied first: I read the companion draft before
>>>>> crediting the edge, and the bytes back it. The continuity rule is nor=
mative
>>>>> ("a rotation without valid continuity MUST be flagged, never silently
>>>>> accepted"), keys resolve at time of issuance so rotation never invali=
dates
>>>>> previously issued evidence, acceptance is graded per action class rat=
her
>>>>> than boolean, and the reference implementation and test suite are pub=
lic.
>>>>> 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 g=
eneral
>>>>> channel for one initial digest, and the shared open item narrows to t=
hat
>>>>> channel. Morgan's test is still doing the work; it just now has a nam=
ed
>>>>> 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 suppli=
er's
>>>>> correction and subordinate to Morgan's row text where they overlap. M=
organ,
>>>>> R2 is your requirement: if your row text or a verdict on this mechani=
sm
>>>>> arrives before Monday's cutoff, the revision posts before Vienna with=
 both
>>>>> folded in; otherwise it follows after the meeting, and the -02 text s=
tands
>>>>> 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=E2=80=AFPM Iman Schrock <team@emiliaproto=
col.ai>
>>>>> 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 t=
he
>>>>>> 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, deliberat=
ely. It
>>>>>> is supplied by a different draft in the same cluster:
>>>>>> draft-schrock-ep-authority-introduction-00, posted alongside the bin=
ding
>>>>>> 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 m=
irror,
>>>>>> a transparency log, a federation directory) and verify continuity of=
fline,
>>>>>> 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 truste=
d
>>>>>> by being introduced. Introduction is evidence, not a bypass: it ente=
rs the
>>>>>> decision under the relying party's own policy, graded by who endorse=
s it
>>>>>> and graded per action class. Introduced-level trust can clear a
>>>>>> low-consequence operation while a wire transfer still requires a pin=
ned
>>>>>> 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 dis=
charges
>>>>>> that to zero. The claim is narrower than solved: the assumption is
>>>>>> explicit, the channel is general rather than bilateral, and acceptan=
ce 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 eviden=
ce
>>>>>> (draft-schrock-ep-authority-introduction-00, individual draft, imple=
mented
>>>>>> with public tests). Met when the deployment pins a general channel f=
or the
>>>>>> genesis digest, the same profile move as the chain side; introduced,=
 not
>>>>>> pinned, issuers receive graded acceptance per relying-party policy a=
nd
>>>>>> action class, never full acceptance. Residual assumption stated, bil=
ateral
>>>>>> provisioning optional."
>>>>>>
>>>>>> If that satisfies neither the requirements author nor the mapping's
>>>>>> discipline, the open verdict stands and should. The point of the col=
umn is
>>>>>> that it can say so.
>>>>>>
>>>>>> Dr. I
>>>>>>
>>>>>> On Thu, Jul 02, 2026 03:07 PM, morganLR <morganLR=3D
>>>>>> 40proton.me@dmarc.ietf.org> 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 p=
ut
>>>>>>> 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 Even=
t Tokens
>>>>>>> to satisfy the revocation and audit requirements (R7, R8) would amo=
unt to
>>>>>>> importing a specific defined architecture, that's a fair thing to h=
old the
>>>>>>> requirements to. The intent is the opposite: R7 and R8 are meant to=
 be
>>>>>>> satisfiable without mandating SET, or any single mechanism =E2=80=
=94 a SET-based
>>>>>>> approach should be one conforming way to meet them, not a presuppos=
ition
>>>>>>> baked into the requirement text. If any of the wording reads as smu=
ggling
>>>>>>> in an architecture, I'd genuinely like to fix that, since
>>>>>>> mechanism-neutrality is the whole point of framing it as requiremen=
ts.
>>>>>>>
>>>>>>> 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 <
>>>>>>> nocluemike17@gmail.com> 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=E2=80=AFPM morganLR <morganLR=3D
>>>>>>> 40proton.me@dmarc.ietf.org> wrote:
>>>>>>>
>>>>>>>> Thanks, Iman =E2=80=94 this is exactly the kind of concrete candid=
ate the
>>>>>>>> requirements framing was meant to invite, and I appreciate you sco=
ping 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. Concret=
ely, I
>>>>>>>> believe it would be beneficial if the mapping were explicit about =
which
>>>>>>>> requirements are met *offline and unconditionally* versus which de=
pend on
>>>>>>>> additional assumptions (issuer key distribution, validity-window s=
emantics,
>>>>>>>> observed-evidence freshness). Surfacing those conditions per-requi=
rement is
>>>>>>>> most of the value the requirements draft is trying to provide.
>>>>>>>>
>>>>>>>> On the architecture point: I agree with the separation, and I thin=
k
>>>>>>>> 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 di=
fferent
>>>>>>>> trust roots. Where I'd want to be careful is not collapsing the
>>>>>>>> human-authorization layer into a single design prematurely =E2=80=
=94 the
>>>>>>>> requirements should hold for that layer independent of whether a g=
iven
>>>>>>>> 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 =E2=80=94 the case where the =
verifying
>>>>>>>> organization and the issuing organization are genuinely distinct t=
rust
>>>>>>>> domains, with no shared operator. Several of the requirements (R3 =
on local
>>>>>>>> verification, R7 on cross-domain revocation/freshness, R8 on compo=
sable
>>>>>>>> audit) behave differently once the second party isn't run by the i=
ssuer,
>>>>>>>> and that boundary is where I think the interesting requirements pr=
essure
>>>>>>>> actually lives. It would be useful to map the candidate against th=
ose
>>>>>>>> requirements specifically under a no-shared-operator assumption.
>>>>>>>>
>>>>>>>> I'd also welcome the same requirements-mapping treatment of other
>>>>>>>> approaches in this space =E2=80=94 e.g., the delegation-receipt wo=
rk addressing the
>>>>>>>> user-to-operator layer =E2=80=94 so the group can compare coverage=
 and gaps across
>>>>>>>> candidates rather than evaluating any one in isolation. If you pro=
duce 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=3D
>>>>>>>> 40emiliaprotocol.ai@dmarc.ietf.org> wrote:
>>>>>>>>
>>>>>>>> Morgan =E2=80=94 thanks for framing this requirements-first; it ma=
kes 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 ra=
ther than
>>>>>>>> abstract agreement =E2=80=94 specifically:
>>>>>>>>
>>>>>>>> - local verification without a real-time callback to the source or=
g
>>>>>>>> - 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 =E2=80=94 no ca=
llback to the
>>>>>>>> source domain (local verification); the signature itself is the bi=
nding to
>>>>>>>> the originating principal; a validity window plus observed-evidenc=
e
>>>>>>>> freshness covers revocation/freshness offline; and because each re=
ceipt is
>>>>>>>> a self-contained signed object, chaining them gives composable aud=
it across
>>>>>>>> domains.
>>>>>>>>
>>>>>>>> We've published this as an individual I-D,
>>>>>>>> draft-schrock-ep-authorization-receipts (Apache-2.0; reference ver=
ifiers in
>>>>>>>> JavaScript, Python, and Go that agree on shared conformance vector=
s). I'm
>>>>>>>> not putting it forward as the answer to the whole delegation probl=
em =E2=80=94 it's
>>>>>>>> specifically the human-authorization-of-an-irreversible-action sli=
ce,
>>>>>>>> designed to compose with workload identity rather than replace it.=
 If it's
>>>>>>>> useful to the requirements discussion, I'm happy to map it explici=
tly
>>>>>>>> against R1=E2=80=93R9 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 =E2=80=94 it keeps "which workload is calling" and "did a=
 named human
>>>>>>>> authorize this exact action" from being conflated, which are diffe=
rent
>>>>>>>> trust roots.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Iman Schrock
>>>>>>>> EMILIA Protocol =C2=B7 team@emiliaprotocol.ai
>>>>>>>> draft-schrock-ep-authorization-receipts
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> WIMSE mailing list -- wimse@ietf.org
>>>>>>>> To unsubscribe send an email to wimse-leave@ietf.org
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> WIMSE mailing list -- wimse@ietf.org
>>>>>>> To unsubscribe send an email to wimse-leave@ietf.org
>>>>>>>
>>>>>>
>>>>>
>>>
>>

--0000000000006b5b8a0655f7c106
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks Iman.=C2=A0</div><br><div class=3D"gmail_quote gmai=
l_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 7, 202=
6 at 5:42=E2=80=AFAM Iman Schrock &lt;<a href=3D"mailto:team@emiliaprotocol=
.ai">team@emiliaprotocol.ai</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div><div dir=3D"auto">Karthik,=
 Morgan,<br><br>The gradient as a field each row states and each artifact d=
eclares is the right move, and it is the one that turns this from prose a r=
eader has to reconstruct into something a verifier reads directly. EP alrea=
dy carries it, which is why I can offer a populated column rather than a pr=
omise. Every EP acceptance declares two things: where its root sits, genera=
l infrastructure for verification and a pinned root for acceptance, reporte=
d as separate fields so the position between first encounter and establishe=
d 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 evi=
dence sufficiency, a relying-party-pinned admissibility-profile hash whose =
bar rises with consequence. A minimal shape for the field is in the crosswa=
lk I posted, offered as input to the definition you would put in the requir=
ements rather than something to fix here.<br><br>On continuity, Morgan&#39;=
s framing is the precise one: the first-contact pin is paid once and amorti=
zed across rotations, not eliminated, and it stays a genuine prior arrangem=
ent for the initial high-consequence interaction. Karthik&#39;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-chai=
ned authority document with continuity signatures from the organization&#39=
;s origin, so the root anchor&#39;s pin survives key rotation with no new l=
eap. The per-hop version, carrying that continuity down the delegation chai=
n, is the PEDIGREE provisioning item you name, and it sits a layer below th=
e root pin, not in place of it.<br><br>On sequencing, that works. I will ke=
ep the WHO and human-authorization rows citing R2 as written in reece-00 an=
d point them at the acquisition-and-binding framing, the first-contact secu=
rity consideration, and the gradient definition once your revised requireme=
nts draft posts after Vienna, rather than race it.<br><br>Iman</div></div><=
/div><br><div class=3D"gmail_extra"><div>On Mon, Jul 06, 2026 10:24 AM, mor=
ganLR &lt;<a href=3D"mailto:morganLR@proton.me" target=3D"_blank">morganLR@=
proton.me</a>&gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div>Iman,=C2=A0</div><div><br></div><div>Thank you, and agreed on the s=
plit reading and on leaving R2 as it stands. Your continuity point is the r=
ight 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 fi=
rst-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 subsequ=
ent interactions rather than renewed. That places a repeated relationship l=
ower on the gradient than a first encounter, which is a more precise statem=
ent than my current wording. I will note it next to the security considerat=
ion, with the qualification that the first-contact pin, though paid only on=
ce, remains a genuine prior arrangement for that initial high-consequence i=
nteraction, so the residual is amortized rather than eliminated. </div><div=
 style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);back=
ground-color:rgb(255,255,255)"><br></div><div style=3D"font-family:Arial,sa=
ns-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"=
>Morgan</div><div>
        On Monday, July 6th, 2026 at 10:37 AM, Iman Schrock &lt;<a href=3D"=
mailto:team@emiliaprotocol.ai" target=3D"_blank">team@emiliaprotocol.ai</a>=
&gt; wrote:<br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div><div dir=3D"auto">Morgan, Karthik,<br><br=
>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 exa=
ctly as you frame it: general infrastructure for the channel, since it harv=
ests the roots that already exist with no mandatory apex and no bilateral g=
ate, and for high-consequence actions the relying party pins the originatin=
g anchor itself, which is the stronger root your security consideration nam=
es.<br><br>One companion worth a line where the residual lives, because it =
bounds the residual&#39;s cost rather than changing R2: continuity. Once th=
e first-contact pin is taken, the hash-chained authority document and the c=
ontinuity signatures carry the binding across key rotation with no new leap=
 and no new bilateral arrangement. The prior arrangement is paid once at fi=
rst contact, not re-paid per interaction. So a repeated relationship sits l=
ower on the gradient than &quot;tends toward a prior relationship&quot; rea=
ds: the residual is amortized to a single pin, not renewed. I would leave R=
2 as you have it and note this next to the security consideration.<br><br>I=
man</div></div></div><br><div class=3D"gmail_extra"><div>On Mon, Jul 06, 20=
26 08:08 AM, morganLR &lt;<a href=3D"mailto:morganLR@proton.me" rel=3D"nore=
ferrer nofollow noopener" target=3D"_blank">morganLR@proton.me</a>&gt; wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-=
family:Arial,sans-serif;font-size:14px"><p>Karthik, Iman, all,</p><p>The ma=
pping 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 c=
oincidence of the mechanisms; it is a property of first-contact trust. Two =
parties with no shared prior root of any kind cannot bootstrap authenticate=
d 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 arrangemen=
t specific to the interaction. General infrastructure that each party joine=
d independently is not only permitted, it is necessary.</p><p>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 mi=
ss. Proposed text below, offered for the list per the usual discipline.</p>=
<p>Proposed R2 (replacement):</p><p>R2 (Cross-organizational verification).=
 A relying party in one organization MUST be able to verify authority that =
originated under another organization&#39;s trust anchor without any arrang=
ement specific to the interaction or specific to the counterparty. Verifica=
tion MAY rely on general trust infrastructure that each party adopts indepe=
ndently of the other, such as a public key infrastructure, an open transpar=
ency log, a permissionless verifiable data registry, or a credential from a=
 recognized issuer. A mechanism satisfies R2 when the relying party can obt=
ain and verify the originating anchor, and can establish that anchor&#39;s =
binding to the originating organization, through such general mechanisms al=
one, with no bilateral or consortium arrangement negotiated for or admittin=
g 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 tw=
o parties, or admission to a governance framework that gates the interactio=
n, since such an arrangement is the bilateral agreement R2 excludes, reloca=
ted into provisioning or membership.</p><p>Explanatory note (for the row, n=
ot the requirement text):</p><p>R2 separates two things a relying party nee=
ds on first contact: acquisition of the originating anchor (the channel), a=
nd binding of that anchor to the originating organization (the binding). Th=
e channel is met by any general, non-gatekept mechanism, and current constr=
uctions meet it. The binding always roots in some shared general infrastruc=
ture, which is permitted; what is excluded is a root that is bilateral or t=
hat 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 s=
hared general root is a precondition for authenticated first contact and ca=
nnot be removed.</p><p>Proposed new Security Consideration (the residual):<=
/p><p>Irreducibility of the first-contact root. No mechanism establishes tr=
ust between two parties who share no prior root of any kind. Authenticated =
verification of a stranger&#39;s anchor requires that both parties independ=
ently rely on some common general infrastructure, and the assurance of the =
binding is bounded by the assurance of that infrastructure: a domain bindin=
g 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 en=
dorsement 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 rely=
ing party MAY accept general-infrastructure binding alone for low-consequen=
ce actions, and SHOULD require a stronger root, such as a pre-pinned endors=
ement or a pre-established credential, for high-consequence actions, accept=
ing that such a stronger root is itself a mild prior arrangement. The more =
consequential the action, the closer first-contact trust tends toward a pri=
or relationship. This tension is a property of trust, not a deficiency of a=
ny particular mechanism, and a conforming solution documents where on this =
gradient it operates rather than claiming to eliminate the residual.</p>Mor=
gan</div><div>
        On Sunday, July 5th, 2026 at 11:12 AM, Iman Schrock &lt;<a href=3D"=
mailto:team@emiliaprotocol.ai" rel=3D"noreferrer nofollow noopener" target=
=3D"_blank">team@emiliaprotocol.ai</a>&gt; wrote:<br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div><div dir=3D"auto">Morgan, Karthik, all,<b=
r><br>Morgan, thank you for re-reading the draft before writing the row. Yo=
ur R2 text is a more precise statement of what authority-introduction-00 do=
es than our own summary language was, and the residual sentence is the one =
I want carried forward: first contact made checkable, not eliminated. Secti=
on 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.<br><br>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.<br><br>Glad to be building this with you both as well.<=
br><br>Iman Schrock<br>EMILIA Protocol</div></div></div><br><div class=3D"g=
mail_extra"><div>On Sun, Jul 05, 2026 05:38 AM, KARTHIK RAMPALLI &lt;<a hre=
f=3D"mailto:karthik@glyphzerolabs.com" rel=3D"noreferrer nofollow noopener"=
 target=3D"_blank">karthik@glyphzerolabs.com</a>&gt; wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Morgan, than=
k you. </div><div><br></div><div>Your row text is in verbatim: -03 is poste=
d, 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 &quot;the authority-introduction companion draft&quot; and the fo=
rmal citation lives in the row note. Everything else is your text, word for=
 word.</div><div><br></div><div>Your residual sentence is now the most usef=
ul line in the document: first contact made checkable, not eliminated. It g=
ives both layers the same honest target for their next revisions, and it gi=
ves a verifier a one-line answer to what the table does and does not promis=
e. Iman, Section 7 saying it plainly is what made it recordable at all.</di=
v><br><div>On maintenance: agreed on the division of labor. You keep R1 thr=
ough R9 responsive as the mechanisms evolve, the suppliers keep their layer=
s honest, and I keep the table current through this list, with each revisio=
n 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.</div><br>Karthik Rampalli<br>Glyphzero, Inc.</div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Su=
n, Jul 5, 2026 at 8:28=E2=80=AFPM morganLR &lt;<a href=3D"mailto:morganLR@p=
roton.me" rel=3D"noreferrer nofollow noopener" target=3D"_blank">morganLR@p=
roton.me</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px"></div><p=
>Karthik, Iman, all,</p><p>Thank you both. I re-read draft-schrock-ep-autho=
rity-introduction-00 before sending this to confirm my thoughts, and it spe=
cifies what the thread described: a signed, hash-chained authority document=
 served from the organization&#39;s origin and registrable to a transparenc=
y 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 relyin=
g party comes to trust an originating anchor with no prior arrangement, and=
 makes it checkable rather than assumed, through a general mechanism that n=
eeds no per-counterparty negotiation.</p><p>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 w=
orth what the log operator is worth, endorsements are worth nothing until t=
he relying party has pinned one. So R2 is narrowed and made explicit on bot=
h layers, not discharged. </p><p>Here is my proposed row text that records =
that honestly. It supersedes the interim wording in the chain and root cell=
s and is subordinate to the mapping&#39;s discipline; if it reads as too st=
rict, the open verdict stands, which is the column doing its job.</p><p>R2 =
chain cell (PEDIGREE):<br>
Conditional: met only when the deployment pins a general anchor-trust mecha=
nism usable by any party without per-counterparty negotiation. A general ch=
annel is named as one conforming way but not required, and static per-count=
erparty provisioning is admitted, which relocates rather than discharges R2=
. Same profile move as R1 inline conveyance.</p><p>R2 root cell (EP):<br>
Conditional, mechanism specified (draft-schrock-ep-authority-introduction-0=
0, Informational, public implementation with tests). Authority Document: si=
gned, hash-chained, sequence-numbered key declaration served from the org o=
rigin and registrable to a transparency log; rotations carry a normative co=
ntinuity signature (MUST be flagged if absent), and artifacts resolve the k=
ey valid at issuance. Acceptance is graded per action class over introducti=
on evidence (chain consistency, domain binding, transparency-log inclusion =
and age, pinned-anchor endorsements), widening mechanically as history accr=
ues 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.</p><p>R2 composition cell:<br=
>
Both layers name general, non-bilateral mechanisms, served from the org ori=
gin and transparency-logged, and state the assumption explicitly, narrowing=
 R2. Shared residual: the first-contact bootstrap, coming to trust an origi=
nating anchor for an organization with no prior arrangement. Narrowed, expl=
icit open item, not a satisfied assumption.</p><p>Row note:</p><p>R2, cross=
-organizational verification. Reframed per a correction from the requiremen=
ts author: pinning the originating anchor relocates the assumption rather t=
han 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 genera=
l 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 anc=
hor arranged in advance between the two organizations moves the forbidden b=
ilateral agreement into the provisioning step.</p><p>Both layers have moved=
 from bare open items toward explicit mechanisms. The chain layer names a g=
eneral channel but does not require it and admits static provisioning, so i=
ts verdict is conditional on pinning a general mechanism. The root layer sp=
ecifies one (draft-schrock-ep-authority-introduction-00): a signed, hash-ch=
ained authority document served from the org origin and transparency-logged=
, with normative continuity on rotation, keys resolved at issuance, and gra=
ded per-action-class acceptance in which un-pinned issuers never receive fu=
ll acceptance and high-consequence actions still require a pinned anchor.</=
p><p>Both narrow R2 honestly and make the residual explicit. The shared res=
idual 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 endo=
rsements are worth nothing until the relying party pins one, so trust is no=
t created from nothing. R2 is therefore conditional and narrowed, met for l=
ower-consequence classes when a general channel is pinned, with the high-co=
nsequence cross-org bootstrap an explicit open item, not a satisfied assump=
tion.</p><div style=3D"font-family:Arial,sans-serif;font-size:14px;margin-t=
op:14px;margin-bottom:14px;color:rgb(0,0,0);background-color:rgb(255,255,25=
5)">Lastly, thank you for the authorship credit and for keeping the require=
ments framing central to how this table reads. Having R1 through R9 serve a=
s the shared test the candidates are measured against, with corrections fol=
ded in through this list, is exactly the collaboration I hoped for when I p=
ut 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 mechani=
sms on both layers evolve.<br></div><p style=3D"font-family:Arial,sans-seri=
f;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></=
p><p style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);=
background-color:rgb(255,255,255)">Morgan</p><div style=3D"font-family:Aria=
l,sans-serif;font-size:14px"><br></div><div>
        On Saturday, July 4th, 2026 at 11:49 PM, KARTHIK RAMPALLI &lt;<a hr=
ef=3D"mailto:karthik@glyphzerolabs.com" rel=3D"noreferrer nofollow noopener=
" target=3D"_blank">karthik@glyphzerolabs.com</a>&gt; wrote:<br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div><br></div><div>Iman, thank you, and the c=
orrection is accepted with the mapping&#39;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 (&quot;a rotation without valid c=
ontinuity MUST be flagged, never silently accepted&quot;), keys resolve at =
time of issuance so rotation never invalidates previously issued evidence, =
acceptance is graded per action class rather than boolean, and the referenc=
e implementation and test suite are public. The cell you propose is a fair =
statement of what the draft specifies.</div><div><br></div><div>One precisi=
on that makes the symmetry exact rather than rhetorical: the residual you s=
tate 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 d=
igest, and the shared open item narrows to that channel. Morgan&#39;s test =
is still doing the work; it just now has a named mechanism to test on both =
sides.</div><div><br></div><div>So the next revision carries your cell, tri=
mmed to table width with the full statement in the row note, marked as reco=
rded per the supplier&#39;s correction and subordinate to Morgan&#39;s row =
text where they overlap. Morgan, R2 is your requirement: if your row text o=
r a verdict on this mechanism arrives before Monday&#39;s cutoff, the revis=
ion 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 verdic=
t, which, as Iman says, the column exists to be able to say.</div><br>Karth=
ik Rampalli<br>Glyphzero, Inc.</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sun, Jul 5, 2026 at 1:23=E2=80=AFPM Iman S=
chrock &lt;<a href=3D"mailto:team@emiliaprotocol.ai" rel=3D"noreferrer nofo=
llow noopener" target=3D"_blank">team@emiliaprotocol.ai</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v><div dir=3D"auto">Karthik, Morgan, all,<br><br>The -02 reframe is right, =
and Morgan&#39;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 pinn=
ed anchor. No dispute with any of that.<br><br>Here is the correction the -=
02 root cell invites. The provisioning mechanism is out of scope for the bi=
nding draft as posted, deliberately. It is supplied by a different draft in=
 the same cluster: draft-schrock-ep-authority-introduction-00, posted along=
side the binding draft.<br><br>What it specifies, against Morgan&#39;s test=
:<br><br>1. The anchor is a hash-chained authority document with continuity=
 signatures. The chain is self-authenticating from its genesis digest, so a=
ny party can obtain it through any general channel (the issuer, a mirror, a=
 transparency log, a federation directory) and verify continuity offline, w=
ith keys resolved at time of issuance. No step is negotiated per counterpar=
ty.<br><br>2. An issuer the relying party has not pinned does not become tr=
usted by being introduced. Introduction is evidence, not a bypass: it enter=
s the decision under the relying party&#39;s own policy, graded by who endo=
rses 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.<br><br>The residual, state=
d plainly: the genesis digest still has to reach the relying party through =
some general channel, and no mechanism discharges that to zero. The claim i=
s 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.<br><br>Suggested root cell for =
the next revision, entirely your call and subordinate to Morgan&#39;s row t=
ext where they overlap: &quot;Conditional, mechanism specified: anchor prov=
isioning via hash-chained authority documents with continuity signatures pl=
us 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 th=
e chain side; introduced, not pinned, issuers receive graded acceptance per=
 relying-party policy and action class, never full acceptance. Residual ass=
umption stated, bilateral provisioning optional.&quot;<br><br>If that satis=
fies neither the requirements author nor the mapping&#39;s discipline, the =
open verdict stands and should. The point of the column is that it can say =
so.<br><br>Dr. I</div></div></div><br><div class=3D"gmail_extra"><div>On Th=
u, Jul 02, 2026 03:07 PM, morganLR &lt;morganLR=3D<a href=3D"mailto:40proto=
n.me@dmarc.ietf.org" rel=3D"noreferrer nofollow noopener" target=3D"_blank"=
>40proton.me@dmarc.ietf.org</a>&gt; wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:1=
4px"><span>Agreed: this is squarely the kind of concrete candidate the requ=
irements are meant to let us evaluate, so I&#39;m glad it&#39;s being put f=
orward that way.</span><div><br></div><div><span>On the second point, I wan=
t to make sure I engage the right concern rather than guess. If you&#39;re =
flagging that leaning on Security Event Tokens to satisfy the revocation an=
d audit requirements (R7, R8) would amount to importing a specific defined =
architecture, that&#39;s a fair thing to hold the requirements to. The inte=
nt is the opposite: R7 and R8 are meant to be satisfiable without mandating=
 SET, or any single mechanism =E2=80=94 a SET-based approach should be one =
conforming way to meet them, not a presupposition baked into the requiremen=
t text. If any of the wording reads as smuggling in an architecture, I&#39;=
d genuinely like to fix that, since mechanism-neutrality is the whole point=
 of framing it as requirements.</span></div><div><br></div><span>Is that th=
e tension you&#39;re pointing at, or did you mean something more specific b=
y &quot;defined architecture&quot;? Happy to go deeper once I&#39;m sure I&=
#39;ve got your actual point.</span><br></div><div style=3D"font-family:Ari=
al,sans-serif;font-size:14px"><span><br></span></div><div style=3D"font-fam=
ily:Arial,sans-serif;font-size:14px"><span>-Morgan</span></div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px">
</div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div>
        On Thursday, July 2nd, 2026 at 4:35 PM, Michael Debus &lt;<a href=
=3D"mailto:nocluemike17@gmail.com" rel=3D"noreferrer nofollow noopener" tar=
get=3D"_blank">nocluemike17@gmail.com</a>&gt; wrote:<br>
        <blockquote type=3D"cite">
            <div dir=3D"auto">Iman,<div dir=3D"auto">   More &quot;exactly&=
quot; the kind of canidate than ~Morgan can understand. Perhaps...</div><di=
v dir=3D"auto">  A+ Iman -On your logic. But the SET additional requirement=
 equate &quot;defined architecture&quot;  I suppose... </div><div dir=3D"au=
to"><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Thu, Jul 2, 2026, 3:06=E2=80=AFPM morganLR &lt;morganLR=
=3D<a href=3D"mailto:40proton.me@dmarc.ietf.org" rel=3D"noreferrer nofollow=
 noopener" target=3D"_blank">40proton.me@dmarc.ietf.org</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span>Thanks, I=
man =E2=80=94 this is exactly the kind of concrete candidate the requiremen=
ts framing was meant to invite, and I appreciate you scoping the claim so p=
recisely rather than asserting general coverage.</span></div><div><br></div=
><div><span>I want to take you up on the offer to map it against R1-R9, wit=
h one framing I&#39;d like to keep in place: I&#39;d rather run this as &qu=
ot;how does this candidate satisfy each requirement&quot; than as a conclus=
ion that any single receipt design settles the requirements it touches. Con=
cretely, I believe it would be beneficial if the mapping were explicit abou=
t which requirements are met *offline and unconditionally* versus which dep=
end on additional assumptions (issuer key distribution, validity-window sem=
antics, observed-evidence freshness). Surfacing those conditions per-requir=
ement is most of the value the requirements draft is trying to provide.</sp=
an></div><div><br></div><div><span>On the architecture point: I agree with =
the separation, and I think it&#39;s worth stating carefully. Keeping &quot=
;which workload is calling&quot; distinct from &quot;did a named human auth=
orize this exact action&quot; is a real and useful distinction, and the req=
uirements should reflect that these are different trust roots. Where I&#39;=
d want to be careful is not collapsing the human-authorization layer into a=
 single design prematurely =E2=80=94 the requirements should hold for that =
layer independent of whether a given receipt format is the one that fills i=
t.</span></div><div><br></div><div><span>The dimension I&#39;d most like to=
 see reflected in any candidate mapping is cross-domain independence =E2=80=
=94 the case where the verifying organization and the issuing organization =
are genuinely distinct trust domains, with no shared operator. Several of t=
he requirements (R3 on local verification, R7 on cross-domain revocation/fr=
eshness, R8 on composable audit) behave differently once the second party i=
sn&#39;t run by the issuer, and that boundary is where I think the interest=
ing requirements pressure actually lives. It would be useful to map the can=
didate against those requirements specifically under a no-shared-operator a=
ssumption.</span></div><div><br></div><div><span>I&#39;d also welcome the s=
ame requirements-mapping treatment of other approaches in this space =E2=80=
=94 e.g., the delegation-receipt work addressing the user-to-operator layer=
 =E2=80=94 so the group can compare coverage and gaps across candidates rat=
her than evaluating any one in isolation. If you produce the R1-R9 mapping =
as a proof-of-concept, I&#39;m happy to fold it into the requirements discu=
ssion in that comparative frame.</span></div><div><br></div><div><span>-Mor=
gan</span></div><div>
        On Tuesday, June 30th, 2026 at 12:57 AM, Iman Schrock &lt;team=3D<a=
 href=3D"mailto:40emiliaprotocol.ai@dmarc.ietf.org" rel=3D"noreferrer nofol=
low noopener" style=3D"word-break:break-word" target=3D"_blank">40emiliapro=
tocol.ai@dmarc.ietf.org</a>&gt; wrote:<br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div><div dir=3D"auto">Morgan =E2=80=94 thanks=
 for framing this requirements-first; it makes the gaps legible without pre=
judging a solution.<br><br>Several of the requirements line up closely with=
 an artifact we&#39;ve been building, and I wanted to offer it as a concret=
e candidate rather than abstract agreement =E2=80=94 specifically:<br><br> =
 - local verification without a real-time callback to the source org<br>  -=
 binding to the originating principal<br>  - cross-domain revocation / fres=
hness<br>  - composable audit<br><br>When the originating principal is a *h=
uman* authorizing an *irreversible* action, an offline-verifiable authoriza=
tion receipt satisfies these directly: an Ed25519 signature over RFC 8785 (=
JCS) canonical JSON binding the named principal to the exact action. A rely=
ing org verifies it with the issuer&#39;s public key alone =E2=80=94 no cal=
lback to the source domain (local verification); the signature itself is th=
e binding to the originating principal; a validity window plus observed-evi=
dence freshness covers revocation/freshness offline; and because each recei=
pt is a self-contained signed object, chaining them gives composable audit =
across domains.<br><br>We&#39;ve published this as an individual I-D, draft=
-schrock-ep-authorization-receipts (Apache-2.0; reference verifiers in Java=
Script, Python, and Go that agree on shared conformance vectors). I&#39;m n=
ot putting it forward as the answer to the whole delegation problem =E2=80=
=94 it&#39;s specifically the human-authorization-of-an-irreversible-action=
 slice, designed to compose with workload identity rather than replace it. =
If it&#39;s useful to the requirements discussion, I&#39;m happy to map it =
explicitly against R1=E2=80=93R9 as a proof-of-concept.<br><br>One framing =
note that may help keep scope clean: it&#39;s worth treating that human-aut=
horization slice as a separable layer above workload identity =E2=80=94 it =
keeps &quot;which workload is calling&quot; and &quot;did a named human aut=
horize this exact action&quot; from being conflated, which are different tr=
ust roots.<br><br>Best,<br>Iman Schrock<br>EMILIA Protocol =C2=B7 <a href=
=3D"mailto:team@emiliaprotocol.ai" rel=3D"noreferrer nofollow noopener" tar=
get=3D"_blank">team@emiliaprotocol.ai</a><br>draft-schrock-ep-authorization=
-receipts</div></div></div>

        </blockquote><br>
    </div>-- <br>
WIMSE mailing list -- <a href=3D"mailto:wimse@ietf.org" rel=3D"noreferrer n=
ofollow noopener" target=3D"_blank">wimse@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:wimse-leave@ietf.org" rel=
=3D"noreferrer nofollow noopener" target=3D"_blank">wimse-leave@ietf.org</a=
><br>
</blockquote></div>

        </blockquote><br>
    </div>-- <br>
WIMSE mailing list -- <a href=3D"mailto:wimse@ietf.org" rel=3D"noreferrer n=
ofollow noopener" target=3D"_blank">wimse@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:wimse-leave@ietf.org" rel=
=3D"noreferrer nofollow noopener" target=3D"_blank">wimse-leave@ietf.org</a=
><br>
</blockquote></div></div>
</blockquote></div>

        </blockquote><br>
    </div></blockquote></div>
</blockquote></div></div>

        </blockquote><br>
    </div></blockquote></div></div>

        </blockquote><br>
    </div></blockquote></div></div>
</blockquote></div>

--0000000000006b5b8a0655f7c106--