[saag] Re: [Secdispatch] Re: Re: draft-yossif-psea-0 2 posted — re-scoped as an EAT token profile (diff)

--===============6955111099526582656==
Content-Type: multipart/alternative; boundary="00000000000075f9b30653f33bb3"

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

Hi Mohamad, Songbo, Rich, all,
Data point for the "is there a community" question: we converged on this
problem independently. I posted draft-schrock-ep-authorization-receipts-00
last week [1] =E2=80=94 authorization receipts that bind a human approver's
user-verification-gated assertion to the SHA-256 of an RFC 8785
(JCS)-canonicalized action payload, with fail-closed verifier rules
(replay, action mismatch, cross-context reuse, one-time consumption) and an
enforced approver-is-not-initiator check. We arrived at essentially the
same binding construction as PSEA-02 =E2=80=94 canonical JSON, hash of the =
exact
action, UV-gated signature, verifier-side fail-closed checks =E2=80=94 with=
out
being aware of each other's work. I take that as evidence the need is real
rather than one vendor's framing.
The drafts look complementary rather than competing. PSEA-02 explicitly
scopes out FIDO2/WebAuthn (standard authenticators cannot conform); our
draft profiles exactly that path =E2=80=94 commodity passkeys/platform
authenticators =E2=80=94 plus the enrollment ceremony PSEA leaves out. Toge=
ther
they cover the dedicated-hardware and commodity-authenticator deployments
with the same verifier philosophy. Songbo's do/don't-prove boundary matches
the lines we drew as well: we treat presentation-attack/WYSIWYS as an
explicit residual risk with mitigations rather than a solved problem, and
we don't attempt subject identity or OAuth step-up policy.
For the broader-community question: there are at least two further
independent efforts adjacent to this space =E2=80=94
draft-nelson-agent-delegation-receipts (user-signed delegation receipts)
and ScopeBlind's agent-action receipt format with public conformance test
vectors. Happy to compile a short survey for the chairs if that's useful
for dispatching.
Concretely: Songbo, if you do the verifier-side pass on PSEA, I'd value the
same adversarial read on our verifier section =E2=80=94 and Mohamad, I'd be=
 glad to
compare claim names and fail-closed check lists so the two profiles don't
gratuitously diverge for implementers. Our reference verifiers (JS/Python,
offline, no issuer trust required) and test vectors are public [2], plus
machine-checked models of the policy engine.
[1]
https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/
 [2] https://github.com/emiliaprotocol/emilia-protocol
Iman Schrock

On Wed, Jun 10, 2026 at 6:51=E2=80=AFPM Songbo Bu <[email protected]> wr=
ote:

> Hi Mohamad, Rich, all,
>
> I read -02 as a much more concrete document than the earlier model
> draft. Framing it as an EAT profile with action-payload binding and
> verifier rules makes the dispatch question easier to discuss.
>
> My quick review reaction is that the strongest path is to keep the
> document very explicit about what it does and does not prove:
>
> - it proves that a named action payload was approved through a
> user-verification-gated authenticator path;
> - it gives the verifier/relying party fail-closed checks for replay,
> action mismatch, and cross-context reuse;
> - it does not by itself solve WYSIWYS, establish a specific human
> identity, or define the surrounding OAuth / step-up policy.
>
> That boundary seems important because it lets the work complement
> OAuth step-up and RATS/EAT without trying to become either of them.
>
> If useful, I can do a focused pass on the verifier-side text and send
> concrete wording, especially around fail-closed behavior and
> action-binding validation.
>
> Best,
> Songbo Bu
>
> On Tue, 09 Jun 2026 19:01:19 +0300, Mohamad Khalil-Yossif
> <[email protected]> wrote:
> > Understood, and thanks =E2=80=94 both for the candor and the signature =
tip.
> >
> > I'll trim it down.
> >
> > Mohamad Khalil-Yossif
> >
> > On 09/06/2026 18:48:23, Salz, Rich <[email protected]=
>
> wrote:
> >
> > I am not criticizing, I am trying to understand the community that
> exists around this and I appreciate your honesty. It seems the answer is
> =E2=80=9Cnone yet.=E2=80=9D
> >
> > -
>
> >
> > If there are specific WGs or people you think should weigh in on whethe=
r
> the need is real, I'd welcome the pointer.
> >
> > Sorry, I have no suggestions. But while I=E2=80=99m here, I do suggest =
that you
> consider stripping down your email signature; four images and a few text
> lines seems a little excessive. :)
>
> _______________________________________________
> Secdispatch mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>


--=20
Iman Schrock
Founder & CEO

EMILIA Protocol | Trust Before High-Risk Action
Eye warns. EP verifies. Signoff owns.

emiliaprotocol.ai | GitHub
[email protected]

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

<div dir=3D"ltr"><div style=3D"font-size:12pt;text-decoration-style:solid;d=
irection:ltr;margin:0px 0px 16px;font-family:Aptos,Arial,Helvetica,sans-ser=
if;color:rgb(0,0,0)">Hi Mohamad, Songbo, Rich, all,</div><div style=3D"font=
-size:12pt;text-decoration-style:solid;margin:0px 0px 16px;font-family:Apto=
s,Arial,Helvetica,sans-serif;color:rgb(0,0,0)">Data point for the &quot;is =
there a community&quot; question: we converged on this problem independentl=
y. I posted draft-schrock-ep-authorization-receipts-00 last week [1] =E2=80=
=94 authorization receipts that bind a human approver&#39;s user-verificati=
on-gated assertion to the SHA-256 of an RFC 8785 (JCS)-canonicalized action=
 payload, with fail-closed verifier rules (replay, action mismatch, cross-c=
ontext reuse, one-time consumption) and an enforced approver-is-not-initiat=
or check. We arrived at essentially the same binding construction as PSEA-0=
2 =E2=80=94 canonical JSON, hash of the exact action, UV-gated signature, v=
erifier-side fail-closed checks =E2=80=94 without being aware of each other=
&#39;s work. I take that as evidence the need is real rather than one vendo=
r&#39;s framing.</div><div style=3D"font-size:12pt;text-decoration-style:so=
lid;margin:0px 0px 16px;font-family:Aptos,Arial,Helvetica,sans-serif;color:=
rgb(0,0,0)">The drafts look complementary rather than competing. PSEA-02 ex=
plicitly scopes out FIDO2/WebAuthn (standard authenticators cannot conform)=
; our draft profiles exactly that path =E2=80=94 commodity passkeys/platfor=
m authenticators =E2=80=94 plus the enrollment ceremony PSEA leaves out. To=
gether they cover the dedicated-hardware and commodity-authenticator deploy=
ments with the same verifier philosophy. Songbo&#39;s do/don&#39;t-prove bo=
undary matches the lines we drew as well: we treat presentation-attack/WYSI=
WYS as an explicit residual risk with mitigations rather than a solved prob=
lem, and we don&#39;t attempt subject identity or OAuth step-up policy.</di=
v><div style=3D"font-size:12pt;text-decoration-style:solid;margin:0px 0px 1=
6px;font-family:Aptos,Arial,Helvetica,sans-serif;color:rgb(0,0,0)">For the =
broader-community question: there are at least two further independent effo=
rts adjacent to this space =E2=80=94 draft-nelson-agent-delegation-receipts=
 (user-signed delegation receipts) and ScopeBlind&#39;s agent-action receip=
t format with public conformance test vectors. Happy to compile a short sur=
vey for the chairs if that&#39;s useful for dispatching.</div><div style=3D=
"font-size:12pt;text-decoration-style:solid;margin:0px 0px 16px;font-family=
:Aptos,Arial,Helvetica,sans-serif;color:rgb(0,0,0)">Concretely: Songbo, if =
you do the verifier-side pass on PSEA, I&#39;d value the same adversarial r=
ead on our verifier section =E2=80=94 and Mohamad, I&#39;d be glad to compa=
re claim names and fail-closed check lists so the two profiles don&#39;t gr=
atuitously diverge for implementers. Our reference verifiers (JS/Python, of=
fline, no issuer trust required) and test vectors are public [2], plus mach=
ine-checked models of the policy engine.</div><div style=3D"color:rgb(0,0,0=
);font-size:12pt;text-decoration-style:solid;margin:0px 0px 16px;font-famil=
y:Aptos,Arial,Helvetica,sans-serif">[1]<span class=3D"gmail-Apple-converted=
-space">=C2=A0</span><span style=3D"color:rgb(0,153,255)"><a href=3D"https:=
//datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/" target=
=3D"_blank" class=3D"gmail-text-[var(--accent)] gmail-hover:underline gmail=
-underline-offset-[1px] gmail-outline-none gmail-hide-focus-ring gmail-ring=
-focus gmail-rounded-r2" rel=3D"noreferrer" style=3D"color:rgb(0,153,255);m=
argin:0px;border-radius:3px">https://datatracker.ietf.org/doc/draft-schrock=
-ep-authorization-receipts/</a></span>=C2=A0[2]<span class=3D"gmail-Apple-c=
onverted-space">=C2=A0</span><span style=3D"color:rgb(0,153,255)"><a href=
=3D"https://github.com/emiliaprotocol/emilia-protocol" target=3D"_blank" cl=
ass=3D"gmail-text-[var(--accent)] gmail-hover:underline gmail-underline-off=
set-[1px] gmail-outline-none gmail-hide-focus-ring gmail-ring-focus gmail-r=
ounded-r2" rel=3D"noreferrer" style=3D"color:rgb(0,153,255);margin:0px;bord=
er-radius:3px">https://github.com/emiliaprotocol/emilia-protocol</a></span>=
</div><div style=3D"font-size:12pt;text-decoration-style:solid;margin:0px 0=
px 16px;font-family:Aptos,Arial,Helvetica,sans-serif;color:rgb(0,0,0)">Iman=
 Schrock=C2=A0</div></div><br><div class=3D"gmail_quote gmail_quote_contain=
er"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 10, 2026 at 6:51=E2=
=80=AFPM Songbo Bu &lt;<a href=3D"mailto:[email protected]">king347608@g=
mail.com</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">Hi Mohamad, Rich, all,<br>
<br>
I read -02 as a much more concrete document than the earlier model<br>
draft. Framing it as an EAT profile with action-payload binding and<br>
verifier rules makes the dispatch question easier to discuss.<br>
<br>
My quick review reaction is that the strongest path is to keep the<br>
document very explicit about what it does and does not prove:<br>
<br>
- it proves that a named action payload was approved through a<br>
user-verification-gated authenticator path;<br>
- it gives the verifier/relying party fail-closed checks for replay,<br>
action mismatch, and cross-context reuse;<br>
- it does not by itself solve WYSIWYS, establish a specific human<br>
identity, or define the surrounding OAuth / step-up policy.<br>
<br>
That boundary seems important because it lets the work complement<br>
OAuth step-up and RATS/EAT without trying to become either of them.<br>
<br>
If useful, I can do a focused pass on the verifier-side text and send<br>
concrete wording, especially around fail-closed behavior and<br>
action-binding validation.<br>
<br>
Best,<br>
Songbo Bu<br>
<br>
On Tue, 09 Jun 2026 19:01:19 +0300, Mohamad Khalil-Yossif<br>
&lt;mohamad=3D<a href=3D"mailto:[email protected]" target=3D"_bl=
ank">[email protected]</a>&gt; wrote:<br>
&gt; Understood, and thanks =E2=80=94 both for the candor and the signature=
 tip.<br>
&gt;<br>
&gt; I&#39;ll trim it down.<br>
&gt;<br>
&gt; Mohamad Khalil-Yossif<br>
&gt;<br>
&gt; On 09/06/2026 18:48:23, Salz, Rich &lt;rsalz=3D<a href=3D"mailto:40aka=
[email protected]" target=3D"_blank">[email protected]</a>&g=
t; wrote:<br>
&gt;<br>
&gt; I am not criticizing, I am trying to understand the community that exi=
sts around this and I appreciate your honesty. It seems the answer is =E2=
=80=9Cnone yet.=E2=80=9D<br>
&gt;<br>
&gt; -<br>
<br>
&gt;<br>
&gt; If there are specific WGs or people you think should weigh in on wheth=
er the need is real, I&#39;d welcome the pointer.<br>
&gt;<br>
&gt; Sorry, I have no suggestions. But while I=E2=80=99m here, I do suggest=
 that you consider stripping down your email signature; four images and a f=
ew text lines seems a little excessive. :)<br>
<br>
_______________________________________________<br>
Secdispatch mailing list -- <a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]=
g" target=3D"_blank">[email protected]</a><br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr">Iman Schrock<br>Founder &amp; CEO<br><br>EMILIA =
Protocol | Trust Before High-Risk Action<br>Eye warns. EP verifies. Signoff=
 owns.<br><br><a href=3D"http://emiliaprotocol.ai" target=3D"_blank">emilia=
protocol.ai</a> | GitHub<br><a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a></div></div>

--00000000000075f9b30653f33bb3--


--===============6955111099526582656==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc2FhZyBtYWls
aW5nIGxpc3QgLS0gc2FhZ0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHNhYWctbGVhdmVAaWV0Zi5vcmcK

--===============6955111099526582656==--