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

[Mohamad Khalil-Yossif <[e-mail]>]

Iman, Songbo, all,

Iman — thank you for this. Independent convergence on the same
construction (canonical JSON, hash of the exact action, UV-gated
signature, fail-closed verifier checks) without prior awareness of
each other's work is, I think, the strongest possible answer to the
community question raised earlier in this thread. Neither of us
invented the need; we both ran into it.

I agree the two profiles read as complementary rather than competing.
PSEA deliberately scopes to dedicated hardware-attested authenticators
(Secure Enclave / StrongBox with key attestation), which is why
standard FIDO2/WebAuthn authenticators cannot conform to it; your
draft profiles exactly the commodity-passkey path PSEA excludes, plus
the enrollment ceremony PSEA leaves out of scope. Same verifier
philosophy, different assurance tiers. Implementers should not have to
relearn claim semantics when moving between them.

So yes — comparing claim names and fail-closed check lists makes
sense. I'll read your draft properly over the weekend or early next
week and send you a first comparison off-list. We can bring any
convergence points back here.

On the survey for the chairs: happy to work on that together — a
short joint note mapping the independent efforts here (including
draft-nelson-agent-delegation-receipts and the ScopeBlind work) seems
genuinely useful for the dispatch question.

Mohamad Khalil-Yossif

[Mohamad Khalil Yossif, Founder & CEO of Yuthent]
Mohamad Khalil Yossif
Founder & CEO · Yuthent
PSEA Spec Author · IETF draft-yossif-psea
[Yuthent — Execution Authority Infrastructure]
 
T: [phone] [tel:[phone]]
E: [e-mail] [mailto:[e-mail]]
W: yuthent.com [https://yuthent.com] [LinkedIn] [https://www.linkedin.com/in/mohamadkhalilyossif]
 
[Yuthent — Cryptographic proof of human authorization at execution time] [https://yuthent.com]
This email may contain confidential or sensitive information. If you are not the intended recipient, any review, use, disclosure, distribution, or copying is prohibited. If you received this message in error, please delete it immediately.
On 11/06/2026 08:00:08, Iman Schrock <[e-mail]> wrote:
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] — 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 — canonical JSON, hash of the exact action, UV-gated signature, verifier-side fail-closed checks — without 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 — commodity passkeys/platform authenticators — plus the enrollment ceremony PSEA leaves out. Together 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 — 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 — 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/ [https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/] [2] https://github.com/emiliaprotocol/emilia-protocol [https://github.com/emiliaprotocol/emilia-protocol]
Iman Schrock

On Wed, Jun 10, 2026 at 6:51 PM Songbo Bu <[e-mail] [mailto:[e-mail]]> wrote:

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
<mohamad=[e-mail] [mailto:[e-mail]]> wrote:
> Understood, and thanks — 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 <rsalz=[e-mail] [mailto:[e-mail]]> 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 “none yet.”
>
> -

>
> If there are specific WGs or people you think should weigh in on whether the need is real, I'd welcome the pointer.
>
> Sorry, I have no suggestions. But while I’m 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 -- [e-mail] [mailto:[e-mail]]
To unsubscribe send an email to [e-mail] [mailto:[e-mail]]



--

Iman Schrock
Founder & CEO

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

emiliaprotocol.ai [http://emiliaprotocol.ai] | GitHub
[e-mail] [mailto:[e-mail]]