[Secdispatch] Re: [saag] Re: Re: draft-yossif-psea-0 2 posted — re-scoped as an EAT token profile (diff)
Iman Schrock <[email protected]> Thu, 11 Jun 2026 00:23:45 -0700
| Newsgroups | gmane.ietf.secdispatch,gmane.ietf.saag |
|---|---|
| Message-ID | <CAOfgHgrZQXnNBCEAJ6kT6ydzQt5Nr+5YQh40RPMNBdSWtxpqaQ@mail.gmail.com> |
--===============5997576263568522171== Content-Type: multipart/alternative; boundary="0000000000003e1af90653f53ef3" --0000000000003e1af90653f53ef3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mohamad, Songbo, all, That's exactly how I see it =E2=80=94 different assurance tiers, one verifi= er philosophy, and implementers shouldn't relearn claim semantics moving between them. No rush at all on reading the draft; whenever you get to it. On the survey: I'll rough out a neutral skeleton =E2=80=94 problem statemen= t, the independent efforts (PSEA, EP, draft-nelson DRP, ScopeBlind) on a common axis, shared construction vs. where they differ, and the open dispatch question =E2=80=94 and send it to you off-list as a strawman to shred. Stri= ctly a starting point; co-authored and neutral is the whole value. We bring it back here once it's worth the list's time. Thanks Songbo =E2=80=94 your do/don't-prove boundary is the spine the surve= y should hang on. Iman Schrock draft-schrock-ep-authorization-receipts https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/ On Thu, Jun 11, 2026 at 12:14=E2=80=AFAM Mohamad Khalil-Yossif <mohamad@yut= hent.com> wrote: > Iman, Songbo, all, > > Iman =E2=80=94 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 =E2=80=94 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 =E2=80=94 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 > > [image: Mohamad Khalil Yossif, Founder & CEO of Yuthent] > Mohamad Khalil Yossif > Founder & CEO =C2=B7 Yuthent > PSEA Spec Author =C2=B7 IETF draft-yossif-psea > [image: Yuthent =E2=80=94 Execution Authority Infrastructure] > > *T:* +972 50-931-1103 <+972509311103> > *E:* [email protected] > *W:* yuthent.com [image: LinkedIn] > <https://www.linkedin.com/in/mohamadkhalilyossif> > > [image: Yuthent =E2=80=94 Cryptographic proof of human authorization at e= xecution > 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 dele= te > it immediately. > > On 11/06/2026 08:00:08, Iman Schrock <[email protected]> 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-0= 0 > 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 th= e exact > action, UV-gated signature, verifier-side fail-closed checks =E2=80=94 wi= thout > being aware of each other's work. I take that as evidence the need is rea= l > 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. To= gether > they cover the dedicated-hardware and commodity-authenticator deployments > with the same verifier philosophy. Songbo's do/don't-prove boundary match= es > 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 profil= es > don't gratuitously diverge for implementers. Our reference verifiers > (JS/Python, offline, no issuer trust required) and test vectors are publi= c > [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]> = 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 >> <[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]= g> >> 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 >> whether 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] >> > > > -- > Iman Schrock > Founder & CEO > > EMILIA Protocol | Trust Before High-Risk Action > Eye warns. EP verifies. Signoff owns. > > emiliaprotocol.ai | GitHub > [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] --0000000000003e1af90653f53ef3 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)">Mohamad, Songbo, all,</div><div style=3D"font-size:12p= t;text-decoration-style:solid;margin:0px 0px 16px;font-family:Aptos,Arial,H= elvetica,sans-serif;color:rgb(0,0,0)">That's exactly how I see it =E2= =80=94 different assurance tiers, one verifier philosophy, and implementers= shouldn't relearn claim semantics moving between them. No rush at all = on reading the draft; whenever you get to it.</div><div style=3D"font-size:= 12pt;text-decoration-style:solid;margin:0px 0px 16px;font-family:Aptos,Aria= l,Helvetica,sans-serif;color:rgb(0,0,0)">On the survey: I'll rough out = a neutral skeleton =E2=80=94 problem statement, the independent efforts (PS= EA, EP, draft-nelson DRP, ScopeBlind) on a common axis, shared construction= vs. where they differ, and the open dispatch question =E2=80=94 and send i= t to you off-list as a strawman to shred. Strictly a starting point; co-aut= hored and neutral is the whole value. We bring it back here once it's w= orth the list's time.</div><div style=3D"font-size:12pt;text-decoration= -style:solid;margin:0px 0px 16px;font-family:Aptos,Arial,Helvetica,sans-ser= if;color:rgb(0,0,0)">Thanks Songbo =E2=80=94 your do/don't-prove bounda= ry is the spine the survey should hang on.</div><div style=3D"color:rgb(0,0= ,0);font-size:12pt;text-decoration-style:solid;margin:0px 0px 16px;font-fam= ily:Aptos,Arial,Helvetica,sans-serif">Iman Schrock draft-schrock-ep-authori= zation-receipts<span class=3D"gmail-Apple-converted-space">=C2=A0</span><sp= an style=3D"color:rgb(0,153,255)"><a href=3D"https://datatracker.ietf.org/d= oc/draft-schrock-ep-authorization-receipts/" target=3D"_blank" class=3D"gma= il-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);margin:0px;border-radius:= 3px">https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receip= ts/</a></span></div></div><br><div class=3D"gmail_quote gmail_quote_contain= er"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 11, 2026 at 12:14=E2= =80=AFAM Mohamad Khalil-Yossif <<a href=3D"mailto:[email protected]">m= [email protected]</a>> 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-left:1ex"><div><div id=3D"m_-8943099707923995358__MailbirdStyleCont= ent" style=3D"font-size:10pt;font-family:"Cascadia Code";color:rg= b(26,26,26);text-align:left" dir=3D"ltr"> <div><span style=3D"font-size:13.33= 33px">Iman, Songbo, all,</span></div><div><span style=3D"font-size:13.3333p= x"><br></span></div><div><span style=3D"font-size:13.3333px">Iman =E2=80=94= thank you for this. Independent convergence on the same</span></div><div><= span style=3D"font-size:13.3333px">construction (canonical JSON, hash of th= e exact action, UV-gated</span></div><div><span style=3D"font-size:13.3333p= x">signature, fail-closed verifier checks) without prior awareness of</span= ></div><div><span style=3D"font-size:13.3333px">each other's work is, I= think, the strongest possible answer to the</span></div><div><span style= =3D"font-size:13.3333px">community question raised earlier in this thread. = Neither of us</span></div><div><span style=3D"font-size:13.3333px">invented= the need; we both ran into it.</span></div><div><span style=3D"font-size:1= 3.3333px"><br></span></div><div><span style=3D"font-size:13.3333px">I agree= the two profiles read as complementary rather than competing.</span></div>= <div><span style=3D"font-size:13.3333px">PSEA deliberately scopes to dedica= ted hardware-attested authenticators</span></div><div><span style=3D"font-s= ize:13.3333px">(Secure Enclave / StrongBox with key attestation), which is = why</span></div><div><span style=3D"font-size:13.3333px">standard FIDO2/Web= Authn authenticators cannot conform to it; your</span></div><div><span styl= e=3D"font-size:13.3333px">draft profiles exactly the commodity-passkey path= PSEA excludes, plus</span></div><div><span style=3D"font-size:13.3333px">t= he enrollment ceremony PSEA leaves out of scope. Same verifier</span></div>= <div><span style=3D"font-size:13.3333px">philosophy, different assurance ti= ers. Implementers should not have to</span></div><div><span style=3D"font-s= ize:13.3333px">relearn claim semantics when moving between them.</span></di= v><div><span style=3D"font-size:13.3333px"><br></span></div><div><span styl= e=3D"font-size:13.3333px">So yes =E2=80=94 comparing claim names and fail-c= losed check lists makes</span></div><div><span style=3D"font-size:13.3333px= ">sense. I'll read your draft properly over the weekend or early next</= span></div><div><span style=3D"font-size:13.3333px">week and send you a fir= st comparison off-list. We can bring any</span></div><div><span style=3D"fo= nt-size:13.3333px">convergence points back here.</span></div><div><span sty= le=3D"font-size:13.3333px"><br></span></div><div><span style=3D"font-size:1= 3.3333px">On the survey for the chairs: happy to work on that together =E2= =80=94 a</span></div><div><span style=3D"font-size:13.3333px">short joint n= ote mapping the independent efforts here (including</span></div><div><span = style=3D"font-size:13.3333px">draft-nelson-agent-delegation-receipts and th= e ScopeBlind work) seems</span></div><div><span style=3D"font-size:13.3333p= x">genuinely useful for the dispatch question.</span></div><div><span style= =3D"font-size:13.3333px"><br></span></div><div><span style=3D"font-size:13.= 3333px">Mohamad Khalil-Yossif</span></div><div><br></div><div><table dir=3D= "ltr" cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"unicode-bid= i:embed;font-size:14px;color:rgb(0,0,0);max-width:600px;width:100%;border-c= ollapse:collapse;text-align:left;direction:ltr"> <tbody> <tr> <td style=3D"padding:10px 0px;text-align:left"> <table dir=3D"ltr" cellpadding=3D"0" cellspacing=3D"0" bord= er=3D"0" width=3D"100%" style=3D"direction:ltr"> <tbody><tr> <td valign=3D"middle" style=3D"text-align:left"> <table dir=3D"ltr" cellpadding=3D"0" cellspacin= g=3D"0" border=3D"0" style=3D"direction:ltr"> <tbody><tr> <td style=3D"padding-right:15px;text-al= ign:left"> <img src=3D"https://yuthent.com/pub= lic/assets/email-signature/profile-600.jpg" width=3D"60" height=3D"60" alt= =3D"Mohamad Khalil Yossif, Founder & CEO of Yuthent" style=3D"display: = block; border-radius: 50%; width: 60px; height: 60px; border: 0px;"> </td> <td style=3D"line-height:1.3;text-align= :left"> <div style=3D"font-size:18px;font-w= eight:bold;color:rgb(0,43,92)">Mohamad Khalil Yossif</div> <div style=3D"font-size:13px;color:= rgb(51,51,51);margin-top:3px">Founder & CEO =C2=B7 Yuthent</div> <div style=3D"font-size:11px;color:= rgb(119,119,119);margin-top:3px">PSEA Spec Author =C2=B7 IETF draft-yossif-= psea</div> </td> </tr> </tbody></table> </td> <td align=3D"right" valign=3D"middle" style=3D"text= -align:right"> <img src=3D"https://yuthent.com/assets/logo.png= " width=3D"90" height=3D"90" alt=3D"Yuthent =E2=80=94 Execution Authority I= nfrastructure" style=3D"display: inline-block; width: 90px; height: 90px; b= order: 0px;"> </td> </tr> </tbody></table> </td> </tr> <tr> <td style=3D"border-top:1px solid rgb(217,217,217);font-size:1p= x;line-height:1px" height=3D"1">=C2=A0</td> </tr> <tr> <td style=3D"padding:10px 0px;text-align:left"> <table dir=3D"ltr" cellpadding=3D"0" cellspacing=3D"0" bord= er=3D"0" width=3D"100%" style=3D"direction:ltr"> <tbody><tr> <td style=3D"font-size:13px;color:rgb(51,51,51);lin= e-height:1.5;text-align:left"> <strong>T:</strong> <a href=3D"tel:+97250931110= 3" style=3D"color:rgb(0,43,92);text-decoration:none" target=3D"_blank">+972= 50-931-1103</a><br> <strong>E:</strong> <a href=3D"mailto:mohamad@y= uthent.com" style=3D"color:rgb(0,43,92);text-decoration:none" target=3D"_bl= ank">[email protected]</a><br> <strong>W:</strong> <a href=3D"https://yuthent.= com" style=3D"color:rgb(0,43,92);text-decoration:none" target=3D"_blank">yu= thent.com</a> </td> <td align=3D"right" valign=3D"middle" style=3D"text= -align:right"> <a href=3D"https://www.linkedin.com/in/mohamadk= halilyossif" style=3D"text-decoration:none" target=3D"_blank"> <img src=3D"https://cdn-icons-png.flaticon.= com/512/174/174857.png" width=3D"24" height=3D"24" alt=3D"LinkedIn" style= =3D"border-radius: 4px; border: 0px;"> </a> </td> </tr> </tbody></table> </td> </tr> <tr> <td style=3D"border-top:1px solid rgb(217,217,217);font-size:1p= x;line-height:1px" height=3D"1">=C2=A0</td> </tr> <tr> <td style=3D"padding-top:10px;text-align:left"> <a href=3D"https://yuthent.com" style=3D"text-decoration:no= ne" target=3D"_blank"> <img src=3D"https://yuthent.com/public/assets/email-sig= nature/banner-1200.png" width=3D"600" alt=3D"Yuthent =E2=80=94 Cryptographi= c proof of human authorization at execution time" style=3D"display: block; = width: 100%; max-width: 600px; height: auto; border: 0px;"> </a> </td> </tr> <tr> <td style=3D"padding-top:10px;font-size:10px;color:rgb(136,136,= 136);line-height:1.4;text-align:left"> This email may contain confidential or sensitive informatio= n. If you are not the intended recipient, any review, use, disclosure, dist= ribution, or copying is prohibited. If you received this message in error, = please delete it immediately. </td> </tr> </tbody> </table></div><blockquote type=3D"cite" style=3D"border-left-style:solid;bo= rder-width:1px;margin-top:20px;margin-left:0px;padding-left:10px"> <p style=3D"color:rgb(170,170,170);margin-top:10px"= >On 11/06/2026 08:00:08, Iman Schrock <<a href=3D"mailto:team@emiliaprot= ocol.ai" target=3D"_blank">[email protected]</a>> wrote:</p><div st= yle=3D"font-family:Arial,Helvetica,sans-serif"><div dir=3D"ltr"><div style= =3D"font-size:12pt;text-decoration-style:solid;direction:ltr;margin:0px 0px= 16px;font-family:Aptos,Arial,Helvetica,sans-serif;color:rgb(0,0,0)">Hi Moh= amad, Songbo, Rich, all,</div><div style=3D"font-size:12pt;text-decoration-= style:solid;margin:0px 0px 16px;font-family:Aptos,Arial,Helvetica,sans-seri= f;color:rgb(0,0,0)">Data point for the "is there a community" que= stion: we converged on this problem independently. I posted draft-schrock-e= p-authorization-receipts-00 last week [1] =E2=80=94 authorization receipts = that bind a human approver's user-verification-gated assertion to the S= HA-256 of an RFC 8785 (JCS)-canonicalized action payload, with fail-closed = verifier rules (replay, action mismatch, cross-context reuse, one-time cons= umption) and an enforced approver-is-not-initiator check. We arrived at ess= entially the same binding construction as PSEA-02 =E2=80=94 canonical JSON,= hash of the exact action, UV-gated signature, verifier-side fail-closed ch= ecks =E2=80=94 without being aware of each other's work. I take that as= evidence the need is real rather than one vendor's framing.</div><div = style=3D"font-size:12pt;text-decoration-style:solid;margin:0px 0px 16px;fon= t-family:Aptos,Arial,Helvetica,sans-serif;color:rgb(0,0,0)">The drafts look= complementary rather than competing. PSEA-02 explicitly scopes out FIDO2/W= ebAuthn (standard authenticators cannot conform); our draft profiles exactl= y that path =E2=80=94 commodity passkeys/platform authenticators =E2=80=94 = plus the enrollment ceremony PSEA leaves out. Together they cover the dedic= ated-hardware and commodity-authenticator deployments with the same verifie= r 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 attem= pt subject identity or OAuth step-up policy.</div><div style=3D"font-size:1= 2pt;text-decoration-style:solid;margin:0px 0px 16px;font-family:Aptos,Arial= ,Helvetica,sans-serif;color:rgb(0,0,0)">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 re= ceipts) and ScopeBlind's agent-action receipt format with public confor= mance test vectors. Happy to compile a short survey for the chairs if that&= #39;s useful for dispatching.</div><div style=3D"font-size:12pt;text-decora= tion-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 pa= ss 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-clo= sed check lists so the two profiles don't gratuitously diverge for impl= ementers. Our reference verifiers (JS/Python, offline, no issuer trust requ= ired) and test vectors are public [2], plus machine-checked models of the p= olicy engine.</div><div style=3D"color:rgb(0,0,0);font-size:12pt;text-decor= ation-style:solid;margin:0px 0px 16px;font-family:Aptos,Arial,Helvetica,san= s-serif">[1]<span>=C2=A0</span><span style=3D"color:rgb(0,153,255)"><a href= =3D"https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipt= s/" rel=3D"noreferrer" style=3D"color:rgb(0,153,255);margin:0px;border-radi= us:3px" target=3D"_blank">https://datatracker.ietf.org/doc/draft-schrock-ep= -authorization-receipts/</a></span>=C2=A0[2]<span>=C2=A0</span><span style= =3D"color:rgb(0,153,255)"><a href=3D"https://github.com/emiliaprotocol/emil= ia-protocol" rel=3D"noreferrer" style=3D"color:rgb(0,153,255);margin:0px;bo= rder-radius:3px" target=3D"_blank">https://github.com/emiliaprotocol/emilia= -protocol</a></span></div><div style=3D"font-size:12pt;text-decoration-styl= e:solid;margin:0px 0px 16px;font-family:Aptos,Arial,Helvetica,sans-serif;co= lor:rgb(0,0,0)">Iman Schrock=C2=A0</div></div><br><div class=3D"gmail_quote= "><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 10, 2026 at 6:51=E2=80= =AFPM Songbo Bu <<a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a>> 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-left: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> <mohamad=3D<a href=3D"mailto:[email protected]" target=3D"_bl= ank">[email protected]</a>> wrote:<br> > Understood, and thanks =E2=80=94 both for the candor and the signature= tip.<br> ><br> > I'll trim it down.<br> ><br> > Mohamad Khalil-Yossif<br> ><br> > On 09/06/2026 18:48:23, Salz, Rich <rsalz=3D<a href=3D"mailto:40aka= [email protected]" target=3D"_blank">[email protected]</a>&g= t; wrote:<br> ><br> > 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> ><br> > -<br> <br> ><br> > If there are specific WGs or people you think should weigh in on wheth= er the need is real, I'd welcome the pointer.<br> ><br> > 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 & 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> </div></blockquote> </div></div></blockquote></div><div= ><br clear=3D"all"></div><div><br></div><span class=3D"gmail_signature_pref= ix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"lt= r">Iman Schrock<br>Founder & 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">emiliaprotocol.ai</a> | GitHub= <br><a href=3D"mailto:[email protected]" target=3D"_blank">team@emilia= protocol.ai</a></div></div> --0000000000003e1af90653f53ef3-- --===============5997576263568522171== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU2VjZGlzcGF0 Y2ggbWFpbGluZyBsaXN0IC0tIHNlY2Rpc3BhdGNoQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNl bmQgYW4gZW1haWwgdG8gc2VjZGlzcGF0Y2gtbGVhdmVAaWV0Zi5vcmcK --===============5997576263568522171==--