[saag] Re: New I-D: draft-yossif-psea-01 — Post-Se ssion Execution Assurance (authority gap at execution time)
"Mohamad Khalil Yossif" <[email protected]> Sun, 10 May 2026 13:09:51 +0300
| Newsgroups | gmane.ietf.saag |
|---|---|
| Message-ID | <[email protected]> |
--===============6576223901483880311== Content-Type: multipart/alternative; boundary="----=_NextPart_29853752.320407257543" ------=_NextPart_29853752.320407257543 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Michael, list, Thank you - this is a useful frame. Three points. On biometric reliability in 2026. The Swedish researcher's work likely refl= ects the 2013-2017 era of attacks (Touch ID via dental molds, Face ID via 3= D masks, Galaxy via printed photos). The current state is meaningfully diff= erent. Apple Platform Security (March 2026) reports a Face ID false match r= ate of 1 in 1,000,000 with single-appearance enrollment, and Elcomsoft - a = forensics vendor whose business is breaking iPhones for law enforcement - r= eports no reproducible Face ID circumvention in the wild. On Android, the C= DD now defines Class 3 biometrics with SAR (spoof acceptance rate) at or be= low 7%, gated by hardware-backed StrongBox keystore on Pixel 4+ and Samsung= S20+. Class 3 is the only tier permitted to back FIDO2 and Keystore-protec= ted keys. PSEA does not assume biometric infallibility. The model assumes the modern = hardware trust anchor (Secure Enclave on iOS, StrongBox on Android) plus li= veness detection plus per-action cryptographic binding. The composition is = the security property, not any single component. An attacker who defeats on= e layer - even biometric spoofing - still has to forge a hardware-bound sig= nature over the specific action payload, which the trust anchor refuses to = produce without a fresh successful biometric match against the enrolled tem= plate, on a device whose state passes attestation, at the moment of the act= ion. On FIDO scanner attestation. You're right that FIDO has mature work on atte= sting biometric subsystems at enrollment time. The gap PSEA targets is at e= xecution. FIDO authenticator attestation answers "is this scanner genuine w= hen the credential was created." PSEA requires the artifact at every sensit= ive action to bind: (a) the specific enrolled biometric template that appro= ved this action, (b) the specific action payload, and (c) the specific mome= nt - producible by the trust anchor without any verifier in the loop. Wheth= er that gap is best closed inside FIDO, W3C webauthn, as a RATS extension, = or as a free-standing model is genuinely open. On the SDK. We have working iOS and Android SDKs that implement the model e= nd-to-end. Building them surfaced a set of threat-model questions the publi= c draft does not yet treat in depth - and which I'd genuinely value your vi= ew on, since they sit closer to your area than mine: =C2=A0 1. Device lifecycle continuity. How does the relying party gain conf= idence that the device the proof is generated on is still under the control= of the same human across the device's lifecycle? Re-enrollment events, Tou= ch ID / Face ID re-registration, OS updates that re-bind keys to a new atte= station root, ownership transfer, and family-sharing scenarios all break th= e naive "device =3D enrolled human" assumption. We handle some of these via= attestation-state hash chaining and forced re-enrollment, but the threat m= odel around silent re-binding events is not fully closed. =C2=A0 2. Single human presence on a shared device. The WebAuthn L2 =C2=A76= quote you'll know - "the same user might not always be the same natural pe= rson" - applies in practice to family iPhones, shared workstations in healt= hcare, and shift-based banking terminals. UVI exists as an extension for di= fferentiating templates, but is not implemented in any production WebAuthn = client. PSEA needs to express that the proof was produced by the specific e= nrolled template, not by any UV-passing human on the device. The cleanest m= echanism we've found is template-binding via a hash of the enrolled biometr= ic reference, but this collides with platform privacy guarantees that templ= ates never leave the enclave. =C2=A0 3. Theft, remote control, and injection. The two attack classes that= worry me most: (a) live device coercion / hijacking - the legitimate human= is present and biometrics pass, but the action being signed was injected b= y malware between the user's intent and the trust anchor's signing operatio= n; (b) remote-control scenarios where an attacker drives the UI while the l= egitimate human is watching, believing they approved one action while the s= igned payload represents another. We mitigate via canonical action display = in the trust anchor's secure UI plus action-hash binding, but the injection= vector inside the OS layer between the app and the secure UI is the part I= 'd most welcome scrutiny on. These are the kinds of questions I'd rather have answered before -02 than a= fter. If you have intuitions on any of the three - even rough ones - I'd va= lue them. The first two are partially addressed by existing FIDO/W3C work; = the third I genuinely don't see addressed cleanly anywhere. Mohamad Khalil-Yossif Yuthent [email protected] https://datatracker.ietf.org/doc/draft-yossif-psea/ [https://datatracker.ie= tf.org/doc/draft-yossif-psea/] [Mohamad Khalil Yossif] Mohamad Khalil Yossif CEO =E2=80=93 Yuthent Founder =E2=80=93 FitSnitch, Thesis, SwiftCrew, MK Digital, MK Electronics [Yuthent Logo] =C2=A0 T: +972 50-931-1103 [tel:+972509311103] E: [email protected] [mailto:[email protected]] W: yuthent.com [https://yuthent.com] [LinkedIn] [https://www.linkedin.com/i= n/mohamad-khalil-yossif-4b9781163/] =C2=A0 [Yuthent =E2=80=93 Verify the Human] [https://yuthent.com] This email may contain confidential or sensitive information. If you are no= t the intended recipient, any review, use, disclosure, distribution, or cop= ying is prohibited. If you received this message in error, please delete it= immediately. On 10/05/2026 00:08:49, Michael Richardson <[email protected]> wrote: [email protected] wrote: > If an Attester in RATS terms cannot, by charter, be a natural person, > and if WebAuthn UV explicitly disclaims concrete user identification =E2= =80=94 > where do you see the cleanest home for a model that requires the proof > artifact to bind a specific natural person, a specific action, and a > specific moment? I believe that neither Attesters nor Target Environment can be natural persons due to the inability of natural persons to execute digital signature operations, whether legacy (disco-era) ones, or any of the current quantum safe ones. I don't think this is a RATS *charter* limitation, but one of physics and human physiology. When biometrics first arrived, I wondered if there was a way for people to identify themselves in such a way that survived amnesia, diminished consciousness, and yet was not subject to duress. My ideas were silly, and best shared over beer. I later met a hacker/scientist (from Sweden I think) whose job it was to break biometric systems... the news then was not good. > Is this best pursued as a RATS extension that adds a > "human attestation" claim type (composing with existing device claims), > as a FIDO Alliance high-assurance profile, as a joint W3C/FIDO/IETF > effort, or as something the existing standards genuinely do not need to > address because the use case can be solved at deployment time by > relying parties enforcing single-template enrollment plus UVI-style > checking? I don't know. I don't know what technology you are proposing. Your document is an interesting requirements statement. Your section, "What PSEA Is Not" is interesting. I would say, what you need is all of what you described. If one believed that fingerprints were the way to go (they probably aren't), then what is possible today is to assess trusthworthiness in the fingerprint scanning system (hardware, firmware). My understanding is that is occuring today if various forms, and there are FIDO Alliance specifications relating to remote attestation of such scanner= s, and therefore incorporation of the resulting trustworthiness claim into the credential that either derived from the biometrics of the fingerprint, or which the fingerprint unlocks. (I think both occur, but it's not my expertise) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ ] My working hours and your working hours may be different. [ ] Please do not feel obligated to reply outside your normal working hours [ ------=_NextPart_29853752.320407257543 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <body><div id=3D"__MailbirdStyleContent" style=3D"font-size: 10pt;font-fami= ly: Cascadia Code;color: #1A1A1A;text-align: left" dir=3D"ltr"> <div><span style=3D"font-size: 13.3= 333px">Michael, list,</span></div><div><span style=3D"font-size: 13.3333px"= ><br></span></div><div><span style=3D"font-size: 13.3333px">Thank you - thi= s is a useful frame. Three points.</span></div><div><span style=3D"font-siz= e: 13.3333px"><br></span></div><div><span style=3D"font-size: 13.3333px">On= biometric reliability in 2026. The Swedish researcher's work likely reflec= ts the 2013-2017 era of attacks (Touch ID via dental molds, Face ID via 3D = masks, Galaxy via printed photos). The current state is meaningfully differ= ent. Apple Platform Security (March 2026) reports a Face ID false match rat= e of 1 in 1,000,000 with single-appearance enrollment, and Elcomsoft - a fo= rensics vendor whose business is breaking iPhones for law enforcement - rep= orts no reproducible Face ID circumvention in the wild. On Android, the CDD= now defines Class 3 biometrics with SAR (spoof acceptance rate) at or belo= w 7%, gated by hardware-backed StrongBox keystore on Pixel 4+ and Samsung S= 20+. Class 3 is the only tier permitted to back FIDO2 and Keystore-protecte= d keys.</span></div><div><span style=3D"font-size: 13.3333px"><br></span></= div><div><span style=3D"font-size: 13.3333px">PSEA does not assume biometri= c infallibility. The model assumes the modern hardware trust anchor (Secure= Enclave on iOS, StrongBox on Android) plus liveness detection plus per-act= ion cryptographic binding. The composition is the security property, not an= y single component. An attacker who defeats one layer - even biometric spoo= fing - still has to forge a hardware-bound signature over the specific acti= on payload, which the trust anchor refuses to produce without a fresh succe= ssful biometric match against the enrolled template, on a device whose stat= e passes attestation, at the moment of the action.</span></div><div><span s= tyle=3D"font-size: 13.3333px"><br></span></div><div><span style=3D"font-siz= e: 13.3333px">On FIDO scanner attestation. You're right that FIDO has matur= e work on attesting biometric subsystems at enrollment time. The gap PSEA t= argets is at execution. FIDO authenticator attestation answers "is this sca= nner genuine when the credential was created." PSEA requires the artifact a= t every sensitive action to bind: (a) the specific enrolled biometric templ= ate that approved this action, (b) the specific action payload, and (c) the= specific moment - producible by the trust anchor without any verifier in t= he loop. Whether that gap is best closed inside FIDO, W3C webauthn, as a RA= TS extension, or as a free-standing model is genuinely open.</span></div><d= iv><span style=3D"font-size: 13.3333px"><br></span></div><div><span style= =3D"font-size: 13.3333px">On the SDK. We have working iOS and Android SDKs = that implement the model end-to-end. Building them surfaced a set of threat= -model questions the public draft does not yet treat in depth - and which I= 'd genuinely value your view on, since they sit closer to your area than mi= ne:</span></div><div><span style=3D"font-size: 13.3333px"><br></span></div>= <div><span style=3D"font-size: 13.3333px"> 1. Device lifecycle contin= uity. How does the relying party gain confidence that the device the proof = is generated on is still under the control of the same human across the dev= ice's lifecycle? Re-enrollment events, Touch ID / Face ID re-registration, = OS updates that re-bind keys to a new attestation root, ownership transfer,= and family-sharing scenarios all break the naive "device =3D enrolled huma= n" assumption. We handle some of these via attestation-state hash chaining = and forced re-enrollment, but the threat model around silent re-binding eve= nts is not fully closed.</span></div><div><span style=3D"font-size: 13.3333= px"><br></span></div><div><span style=3D"font-size: 13.3333px"> 2. Si= ngle human presence on a shared device. The WebAuthn L2 =C2=A76 quote you'l= l know - "the same user might not always be the same natural person" - appl= ies in practice to family iPhones, shared workstations in healthcare, and s= hift-based banking terminals. UVI exists as an extension for differentiatin= g templates, but is not implemented in any production WebAuthn client. PSEA= needs to express that the proof was produced by the specific enrolled temp= late, not by any UV-passing human on the device. The cleanest mechanism we'= ve found is template-binding via a hash of the enrolled biometric reference= , but this collides with platform privacy guarantees that templates never l= eave the enclave.</span></div><div><span style=3D"font-size: 13.3333px"><br= ></span></div><div><span style=3D"font-size: 13.3333px"> 3. Theft, re= mote control, and injection. The two attack classes that worry me most: (a)= live device coercion / hijacking - the legitimate human is present and bio= metrics pass, but the action being signed was injected by malware between t= he user's intent and the trust anchor's signing operation; (b) remote-contr= ol scenarios where an attacker drives the UI while the legitimate human is = watching, believing they approved one action while the signed payload repre= sents another. We mitigate via canonical action display in the trust anchor= 's secure UI plus action-hash binding, but the injection vector inside the = OS layer between the app and the secure UI is the part I'd most welcome scr= utiny on.</span></div><div><span style=3D"font-size: 13.3333px"><br></span>= </div><div><span style=3D"font-size: 13.3333px">These are the kinds of ques= tions I'd rather have answered before -02 than after. If you have intuition= s on any of the three - even rough ones - I'd value them. The first two are= partially addressed by existing FIDO/W3C work; the third I genuinely don't= see addressed cleanly anywhere.</span></div><div><span style=3D"font-size:= 13.3333px"><br></span></div><div><span style=3D"font-size: 13.3333px">Moha= mad Khalil-Yossif</span></div><div><span style=3D"font-size: 13.3333px">Yut= hent</span></div><div><span style=3D"font-size: 13.3333px">mohamad@yuthent.= com</span></div><div><a href=3D"https://datatracker.ietf.org/doc/draft-yoss= if-psea/"><span style=3D"font-size: 10pt">https://datatracker.ietf.org/doc/= draft-yossif-psea/</span></a></div><div><br></div><div><br></div><div class= =3D"mb_sig"> <footer><table dir=3D"ltr" cellpadding=3D"0" cellspacing=3D"0" border=3D"0"= style=3D"direction: ltr !important;unicode-bidi: embed;font-family: Arial,= sans-serif;font-size: 14px;color: #000000;max-width: 600px;width: 100%;bor= der-collapse: collapse;text-align: left"> <tbody> <tr> <td style=3D"padding: 10px 0; text-align: left;"> <table dir=3D"ltr" cellpadding=3D"0" cellspacing=3D"0" bord= er=3D"0" width=3D"100%" style=3D"direction: ltr !important;"> <tbody><tr> <td valign=3D"middle" style=3D"font-family: Arial, = sans-serif; text-align: left;"> <table dir=3D"ltr" cellpadding=3D"0" cellspacin= g=3D"0" border=3D"0" style=3D"direction: ltr !important;"> <tbody><tr> <td style=3D"padding-right: 15px; text-= align: left;"> <img src=3D"https://yuthent.com/pub= lic/assets/profile.jpg" width=3D"60" height=3D"60" alt=3D"Mohamad Khalil Yo= ssif" style=3D"display: block; border-radius: 50%; width: 60px; height: 60p= x; border: 0;"></img> </td> <td style=3D"font-family: Arial, sans-s= erif; line-height: 1.2; text-align: left;"> <div style=3D"font-size: 18px;font-= weight: bold;color: #002b5c">Mohamad Khalil Yossif</div> <div style=3D"font-size: 13px;color= : #333333;margin-top: 2px">CEO =E2=80=93 Yuthent</div> <div style=3D"font-size: 11px;color= : #777777;margin-top: 2px">Founder =E2=80=93 FitSnitch, Thesis, SwiftCrew, = MK Digital, MK Electronics</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 Logo" style=3D"display: inline-= block; width: 90px; height: 90px; border: 0;"></img> </td> </tr> </tbody></table> </td> </tr> <tr> <td style=3D"border-top: 1px solid #d9d9d9;font-size: 1px;line-= height: 1px" height=3D"1"> </td> </tr> <tr> <td style=3D"padding: 10px 0; text-align: left;"> <table dir=3D"ltr" cellpadding=3D"0" cellspacing=3D"0" bord= er=3D"0" width=3D"100%" style=3D"direction: ltr !important;"> <tbody><tr> <td style=3D"font-family: Arial, sans-serif;font-si= ze: 13px;color: #333333;line-height: 1.5;text-align: left"> <strong>T:</strong> <a href=3D"tel:+97250931110= 3" style=3D"color: #002b5c; text-decoration: none;">+972 50-931-1103</a><br> <strong>E:</strong> <a href=3D"mailto:mohamad@y= uthent.com" style=3D"color: #002b5c; text-decoration: none;">mohamad@yuthen= t.com</a><br> <strong>W:</strong> <a href=3D"https://yuthent.= com" style=3D"color: #002b5c; text-decoration: none;">yuthent.com</a> </td> <td align=3D"right" valign=3D"middle" style=3D"text= -align: right;"> <a href=3D"https://www.linkedin.com/in/mohamad-= khalil-yossif-4b9781163/" style=3D"text-decoration: none;"> <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: 0;"></img> </a> </td> </tr> </tbody></table> </td> </tr> <tr> <td style=3D"border-top: 1px solid #d9d9d9;font-size: 1px;line-= height: 1px" height=3D"1"> </td> </tr> <tr> <td style=3D"padding-top: 10px; text-align: left;"> <a href=3D"https://yuthent.com" style=3D"text-decoration: n= one;"> <img src=3D"https://yuthent.com/public/assets/banner.jp= g" width=3D"600" alt=3D"Yuthent =E2=80=93 Verify the Human" style=3D"displa= y: block; width: 100%; max-width: 600px; border: 0;"></img> </a> </td> </tr> <tr> <td style=3D"padding-top: 10px;font-family: Arial, sans-serif;f= ont-size: 10px;color: #888888;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></footer></div><blockquote class=3D'history_container' type=3D'cite= ' style=3D'border-left-style:solid;border-width:1px; margin-top:20px; margi= n-left:0px;padding-left:10px;'> <p style=3D'color: #AAAAAA; margin-top: 10px;'>On 1= 0/05/2026 00:08:49, Michael Richardson <[email protected]> wrote:</p><= div style=3D'font-family:Arial,Helvetica,sans-serif'> <br>[email protected] <[email protected]> wrote: <br> > If an Attester in RATS terms cannot, by charter, be a natural per= son, <br> > and if WebAuthn UV explicitly disclaims concrete user identificat= ion =E2=80=94 <br> > where do you see the cleanest home for a model that requires the = proof <br> > artifact to bind a specific natural person, a specific action, an= d a <br> > specific moment? <br> <br>I believe that neither Attesters nor Target Environment can be natural <br>persons due to the inability of natural persons to execute digital sign= ature <br>operations, whether legacy (disco-era) ones, or any of the current quan= tum <br>safe ones. I don't think this is a RATS *charter* limitation, but one= of <br>physics and human physiology. <br> <br> <br>When biometrics first arrived, I wondered if there was a way for people= to <br>identify themselves in such a way that survived amnesia, diminished <br>consciousness, and yet was not subject to duress. My ideas were silly,= and <br>best shared over beer. I later met a hacker/scientist (from Sweden I t= hink) <br>whose job it was to break biometric systems... the news then was not go= od. <br> <br> > Is this best pursued as a RATS extension that adds a <br> > "human attestation" claim type (composing with existing device cl= aims), <br> > as a FIDO Alliance high-assurance profile, as a joint W3C/FIDO/IE= TF <br> > effort, or as something the existing standards genuinely do not n= eed to <br> > address because the use case can be solved at deployment time by <br> > relying parties enforcing single-template enrollment plus UVI-sty= le <br> > checking? <br> <br>I don't know. I don't know what technology you are proposing. <br>Your document is an interesting requirements statement. <br> <br>Your section, "What PSEA Is Not" is interesting. <br>I would say, what you need is all of what you described. <br> <br>If one believed that fingerprints were the way to go (they probably are= n't), <br>then what is possible today is to assess trusthworthiness in the finger= print <br>scanning system (hardware, firmware). <br> <br>My understanding is that is occuring today if various forms, and there = are <br>FIDO Alliance specifications relating to remote attestation of such sca= nners, <br>and therefore incorporation of the resulting trustworthiness claim into= the <br>credential that either derived from the biometrics of the fingerprint, = or <br>which the fingerprint unlocks. (I think both occur, but it's not my <br>expertise) <br> <br>-- <br>] Never tell me the odds! | ipv6 mesh net= works [ <br>] Michael Richardson, Sandelman Software Works | IoT archit= ect [ <br>] [email protected] http://www.sandelman.ca/ | ruby on rai= ls [ <br>] My working hours and your working hours may be different. = [ <br>] Please do not feel obligated to reply outside your normal working ho= urs [ <br> <br> <br></[email protected]></div></blockquote> </div></body> ------=_NextPart_29853752.320407257543-- --===============6576223901483880311== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc2FhZyBtYWls aW5nIGxpc3QgLS0gc2FhZ0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHNhYWctbGVhdmVAaWV0Zi5vcmcK --===============6576223901483880311==--