[saag] Re: New I-D: draft-yossif-psea-01 — Post-Se ssion Execution Assurance (authority gap at execution time)
| Newsgroups |
gmane.ietf.saag |
| Message-ID |
<[email protected]> |
--===============2106304914772720073==
Content-Type: multipart/alternative;
boundary="Apple-Mail=_6A5F3C13-04C1-4FF1-A1D6-D019DA161394"
--Apple-Mail=_6A5F3C13-04C1-4FF1-A1D6-D019DA161394
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Michael, list,
Your three points sharpened the discussion considerably and made me =
re-examine PSEA's positioning relative to the existing standards stack. =
After doing that work, here is what I believe is the precise gap PSEA =
addresses =E2=80=94 with citations to the existing specs, including =
yours.
I'll concede upfront: PSEA's contribution is not action binding =
(=C2=A7txAuthSimple historically, transactionalConfirmation in W3C =
webauthn issue #2022, SPC, FIDO TxConf, Android Protected Confirmation =
all address that), nor device attestation (RATS, lamps-csr-attestation, =
FIDO authenticator attestation cover that), nor key non-exportability =
(FIDO2, hardware-backed keystores cover that). Each of those mechanisms =
exists and works.
The gap is narrower and, I believe, genuine.
The specific-human-vs-device-owner distinction
WebAuthn User Verification, by the spec authors' own statement, does not =
identify a specific natural person. It verifies that *some* enrolled =
biometric or PIN gate was passed on the authenticator.
=46rom W3C WebAuthn Level 2, =C2=A76 (Authenticator Model):
"For example, some devices are intended to be used by a single
individual, yet they may allow multiple natural persons to enroll
fingerprints or know the same PIN and thus access the same Relying
Party account... Note that user verification does not give the
Relying Party a concrete identification of the user, but when 2 or
more ceremonies with user verification have been done with that
credential it expresses that it was the same user that performed all
of them. The same user might not always be the same natural person,
however, if multiple natural persons share access to the same
authenticator."
WebAuthn Level 3 (Candidate Recommendation Snapshot, 13 January 2026) =
retains this language in =C2=A74 Terminology:
"In general, an authenticator is assumed to have only one user. If
multiple natural persons share access to an authenticator, they are
considered to represent the same user in the context of that
authenticator."
The FIDO Alliance privacy principles frame UV correspondingly as "how a =
device locally interacts with or identifies the user" =E2=80=94 a local =
device-side concept, not a remote identity assertion to the Relying =
Party.
The operational consequence: an iPhone with five enrolled Touch ID =
fingerprints, or a shared workstation with multiple OS-level user =
profiles each capable of unlocking the same passkey, will pass UV for =
any of them. The Relying Party receives a UV=3Dtrue bit and cannot =
distinguish among them. For consumer login this is acceptable. For =
high-value action approval in regulated environments =E2=80=94 where the =
question is not "did a verified user present" but "did the *specific =
human authorized for this account* approve this action" =E2=80=94 it is =
not.
The UVI extension (registered in IANA's WebAuthn extension registry) is =
the closest existing mechanism to address this, by exposing whether the =
same biometric template approved the assertion as approved registration. =
In practice it is not implemented in any major browser or platform =
authenticator and does not bind to a specific action payload.
Where RATS sits
RFC 9334 explicitly scopes the architecture to system components:
"Roles are assigned to entities. Entities are often system components
[RFC4949], such as devices."
=E2=80=94 RFC 9334 =C2=A74
And the RATS WG charter:
"The working group will develop standards supporting interoperable
remote attestation procedures for system components."
The Attester is a device. Evidence is about the device's measured state. =
There is no claim type for "specific natural person X approved action Y =
at time T," because that is not what the architecture was designed to =
express. PSEA is not a competitor to RATS =E2=80=94 it composes =
naturally above it. The device-state half of any PSEA implementation =
should consume RATS primitives (EAT per draft-ietf-rats-eat, AR4SI's =
trustworthiness vector, CoRIM Reference Values, DICE-rooted identity). I =
should have been clearer about this in the draft and will be in -02.
What PSEA actually requires
Reframed in light of the above, PSEA's contribution is the architectural =
requirement that an action-approval proof bind, in a single =
cryptographic artifact:
(a) a specific enrolled biometric template =E2=80=94 not the =
device-owner
abstraction WebAuthn UV provides,
(b) a specific action payload =E2=80=94 generalized across protocols, =
not
scoped to payments (SPC) or to legacy WebAuthn extensions that
browsers never implemented (txAuthSimple),
(c) a specific moment =E2=80=94 with temporal binding non-negotiable =
per
action, not per session or per TLS connection,
verifiable by an external Verifier independently of any session, network =
connectivity, or transport, and composable with RATS device-state =
Evidence and FIDO2 credential possession.
None of the existing mechanisms I listed at the top of this email =
satisfy all three of (a), (b), (c) together as a normative requirement. =
They each address one or two. PSEA's claim is that the regulated-action =
use case (banking dynamic linking under PSD2 RTS Article 5, healthcare =
prescription approval, government classified-action authorization) =
requires all three bound together =E2=80=94 and that this requirement is =
best expressed as an architectural model, not as another extension to =
any single protocol.
Where this should live
I now think OAuth is not the right home for the architectural model =
itself. The natural homes for the components are:
- FIDO Alliance and W3C webauthn for the specific-human-template =
binding work (UVI revival, transactionalConfirmation evolution).
- RATS for the device-state composition (your area).
- OAuth for the authorization-time integration (how a PSEA proof is =
presented as evidence at a token endpoint or step-up flow per RFC 9470).
What I would value from you, as someone who built the architectural =
foundation in RFC 9334:
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? 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'm asking the question seriously =E2=80=94 not rhetorically. Your =
answer materially affects how -02 is positioned.
Mohamad Khalil Yossif
Yuthent
[email protected]
https://datatracker.ietf.org/doc/draft-yossif-psea/
=09
Mohamad Khalil Yossif
CEO =E2=80=93 Yuthent
Founder =E2=80=93 FitSnitch, Thesis, SwiftCrew, MK Digital, MK =
Electronics
=20
T: +972 50-931-1103 <tel:+972509311103>
E: [email protected] <mailto:[email protected]>
W: yuthent.com <https://yuthent.com/> =
<https://www.linkedin.com/in/mohamad-khalil-yossif-4b9781163/>
=20
<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 9 May 2026, at 0:07, Michael Richardson <[email protected]> wrote:
>=20
>=20
> Based upon your answers, I'm not convinced you actually understand =
remote attestation.
>=20
> You need:
> 1) Evidence that a real human is present at a computer.
> ** THAT'S REMOTE ATTESTATION **
>=20
> 2) An audit trail that the human saw the specific action you want
> confirmation on, **and not something else**
> So, you need Evidence that the screen used to *ask* the human was
> not trojan'ed. That's also remote attestation.
>=20
> 3) You need some way to link the credential a human is going to use
> to answer the question, so the credential you have.
> You need Evidence that the credentential was not hijacked.
> That's ALSO remote attestation about the location and management of =
the
> private key. We have, for instance, =
draft-ietf-lamps-csr-attestation.
>=20
>=20
> --
> ] 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 [
>=20
>=20
--Apple-Mail=_6A5F3C13-04C1-4FF1-A1D6-D019DA161394
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><div =
dir=3D"auto" style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: =
space; line-break: after-white-space;"><div style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); margin: 0px;">Michael, list,</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;">Your three points sharpened the discussion =
considerably and made me re-examine PSEA's positioning relative to the =
existing standards stack. After doing that work, here is what I believe =
is the precise gap PSEA addresses =E2=80=94 with citations to the =
existing specs, including yours.</div><div style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); margin: 0px;"><br></div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;">I'll concede upfront: PSEA's contribution is not action binding =
(=C2=A7txAuthSimple historically, transactionalConfirmation in W3C =
webauthn issue #2022, SPC, FIDO TxConf, Android Protected Confirmation =
all address that), nor device attestation (RATS, lamps-csr-attestation, =
FIDO authenticator attestation cover that), nor key non-exportability =
(FIDO2, hardware-backed keystores cover that). Each of those mechanisms =
exists and works.</div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0); margin: 0px;"><br></div><div style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); margin: 0px;">The gap is narrower and, I =
believe, genuine.</div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0); margin: 0px;"><br></div><div style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); margin: 0px;">The =
specific-human-vs-device-owner distinction</div><div style=3D"caret-color:=
rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px;"><br></div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;">WebAuthn User Verification, by the spec authors' own statement, =
does not identify a specific natural person. It verifies that *some* =
enrolled biometric or PIN gate was passed on the =
authenticator.</div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0); margin: 0px;"><br></div><div style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); margin: 0px;">=46rom W3C WebAuthn Level 2, =
=C2=A76 (Authenticator Model):</div><div style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0); margin: 0px;"><br></div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"> "For example, some devices are intended to be used by a =
single</div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0); margin: 0px;"> individual, yet they may allow multiple natural =
persons to enroll</div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0); margin: 0px;"> fingerprints or know the same PIN and =
thus access the same Relying</div><div style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0); margin: 0px;"> Party account... Note that =
user verification does not give the</div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px;"> Relying Party a =
concrete identification of the user, but when 2 or</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"> more ceremonies with user verification have been done with =
that</div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); =
margin: 0px;"> credential it expresses that it was the same user =
that performed all</div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0); margin: 0px;"> of them. The same user might not =
always be the same natural person,</div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px;"> however, if =
multiple natural persons share access to the same</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"> authenticator."</div><div style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0); margin: 0px;"><br></div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;">WebAuthn Level 3 (Candidate Recommendation Snapshot, 13 January =
2026) retains this language in =C2=A74 Terminology:</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;"> "In general, an authenticator is assumed to =
have only one user. If</div><div style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0); margin: 0px;"> multiple natural persons share =
access to an authenticator, they are</div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px;"> considered to =
represent the same user in the context of that</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"> authenticator."</div><div style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0); margin: 0px;"><br></div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;">The FIDO Alliance privacy principles frame UV correspondingly as =
"how a device locally interacts with or identifies the user" =E2=80=94 a =
local device-side concept, not a remote identity assertion to the =
Relying Party.</div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0); margin: 0px;"><br></div><div style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); margin: 0px;">The operational consequence: =
an iPhone with five enrolled Touch ID fingerprints, or a shared =
workstation with multiple OS-level user profiles each capable of =
unlocking the same passkey, will pass UV for any of them. The Relying =
Party receives a UV=3Dtrue bit and cannot distinguish among them. For =
consumer login this is acceptable. For high-value action approval in =
regulated environments =E2=80=94 where the question is not "did a =
verified user present" but "did the *specific human authorized for this =
account* approve this action" =E2=80=94 it is not.</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;">The UVI extension (registered in IANA's WebAuthn =
extension registry) is the closest existing mechanism to address this, =
by exposing whether the same biometric template approved the assertion =
as approved registration. In practice it is not implemented in any major =
browser or platform authenticator and does not bind to a specific action =
payload.</div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0); margin: 0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0); margin: 0px;">Where RATS sits</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;">RFC 9334 explicitly scopes the architecture to =
system components:</div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0); margin: 0px;"><br></div><div style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); margin: 0px;"> "Roles are assigned to =
entities. Entities are often system components</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"> [RFC4949], such as devices."</div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px;"> =E2=80=94 RFC =
9334 =C2=A74</div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0); margin: 0px;">And the RATS WG charter:</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;"> "The working group will develop standards =
supporting interoperable</div><div style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0); margin: 0px;"> remote attestation procedures =
for system components."</div><div style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0); margin: 0px;"><br></div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px;">The Attester is a =
device. Evidence is about the device's measured state. There is no claim =
type for "specific natural person X approved action Y at time T," =
because that is not what the architecture was designed to express. PSEA =
is not a competitor to RATS =E2=80=94 it composes naturally above it. =
The device-state half of any PSEA implementation should consume RATS =
primitives (EAT per draft-ietf-rats-eat, AR4SI's trustworthiness vector, =
CoRIM Reference Values, DICE-rooted identity). I should have been =
clearer about this in the draft and will be in -02.</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;">What PSEA actually requires</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;">Reframed in light of the above, PSEA's contribution =
is the architectural requirement that an action-approval proof bind, in =
a single cryptographic artifact:</div><div style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); margin: 0px;"><br></div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"> (a) a specific enrolled biometric template =E2=80=94 not =
the device-owner</div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0); margin: 0px;"> abstraction WebAuthn UV =
provides,</div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0); margin: 0px;"> (b) a specific action payload =E2=80=94 =
generalized across protocols, not</div><div style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); margin: 0px;"> scoped to =
payments (SPC) or to legacy WebAuthn extensions that</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"> browsers never implemented =
(txAuthSimple),</div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0); margin: 0px;"> (c) a specific moment =E2=80=94 with =
temporal binding non-negotiable per</div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px;"> =
action, not per session or per TLS connection,</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;">verifiable by an external Verifier independently of =
any session, network connectivity, or transport, and composable with =
RATS device-state Evidence and FIDO2 credential possession.</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;">None of the existing mechanisms I listed at the top =
of this email satisfy all three of (a), (b), (c) together as a normative =
requirement. They each address one or two. PSEA's claim is that the =
regulated-action use case (banking dynamic linking under PSD2 RTS =
Article 5, healthcare prescription approval, government =
classified-action authorization) requires all three bound together =E2=80=94=
and that this requirement is best expressed as an architectural model, =
not as another extension to any single protocol.</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;">Where this should live</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;">I now think OAuth is not the right home for the =
architectural model itself. The natural homes for the components =
are:</div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); =
margin: 0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0); margin: 0px;"> - FIDO Alliance and W3C webauthn for =
the specific-human-template binding work (UVI revival, =
transactionalConfirmation evolution).</div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px;"> - RATS for the =
device-state composition (your area).</div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px;"> - OAuth for the =
authorization-time integration (how a PSEA proof is presented as =
evidence at a token endpoint or step-up flow per RFC 9470).</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, =
0, 0); margin: 0px;">What I would value from you, as someone who built =
the architectural foundation in RFC 9334:</div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px;"><br></div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;">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? 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?</div><div style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0); margin: 0px;"><br></div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); margin: 0px;">I'm asking the question =
seriously =E2=80=94 not rhetorically. Your answer materially affects how =
-02 is positioned.</div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0); margin: 0px;"><br></div><div style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0); margin: 0px;">Mohamad Khalil =
Yossif</div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0); margin: 0px;">Yuthent</div><div style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0); margin: 0px;">[email protected]</div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><a =
href=3D"https://datatracker.ietf.org/doc/draft-yossif-psea/">https://datat=
racker.ietf.org/doc/draft-yossif-psea/</a></div><div style=3D"text-align: =
left; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); margin: =
0px;"><br></div><div>
<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%; border-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" =
border=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" =
cellspacing=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/public/assets/profile.jpg" width=3D"60" =
height=3D"60" alt=3D"Mohamad Khalil Yossif" style=3D"display: block; =
border-radius: 50%; width: 60px; height: 60px; border: 0;">
</td>
<td style=3D"font-family: Arial, =
sans-serif; 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;">
</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" =
border=3D"0" width=3D"100%" style=3D"direction: ltr !important;">
<tbody><tr>
<td style=3D"font-family: Arial, sans-serif; =
font-size: 13px; color: #333333; line-height: 1.5; text-align: left;">
<strong>T:</strong> <a =
href=3D"tel:+972509311103" style=3D"color: #002b5c; text-decoration: =
none;">+972 50-931-1103</a><br>
<strong>E:</strong> <a =
href=3D"mailto:[email protected]" style=3D"color: #002b5c; =
text-decoration: none;">[email protected]</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;">
</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: =
none;">
<img =
src=3D"https://yuthent.com/public/assets/banner.jpg" width=3D"600" =
alt=3D"Yuthent =E2=80=93 Verify the Human" style=3D"display: block; =
width: 100%; max-width: 600px; border: 0;">
</a>
</td>
</tr>
<tr>
<td style=3D"padding-top: 10px; font-family: Arial, =
sans-serif; font-size: 10px; color: #888888; line-height: 1.4; =
text-align: left;">
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.
</td>
</tr>
</tbody>
</table>
</div>
<div><br><blockquote type=3D"cite"><div>On 9 May 2026, at 0:07, Michael =
Richardson <[email protected]> wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div><br>Based upon your =
answers, I'm not convinced you actually understand remote =
attestation.<br><br>You need:<br>1) Evidence that a real human is =
present at a computer.<br> ** THAT'S REMOTE ATTESTATION =
**<br><br>2) An audit trail that the human saw the specific action you =
want<br> confirmation on, **and not something else**<br> =
So, you need Evidence that the screen used to *ask* the =
human was<br> not trojan'ed. That's also remote =
attestation.<br><br>3) You need some way to link the credential a human =
is going to use<br> to answer the question, so the =
credential you have.<br> You need Evidence that the =
credentential was not hijacked.<br> That's ALSO remote =
attestation about the location and management of the<br> =
private key. We have, for instance, =
draft-ietf-lamps-csr-attestation.<br><br><br>--<br>] =
&n=
bsp; Never tell me the odds! =
&n=
bsp; | ipv6 mesh networks [<br>] Michael =
Richardson, Sandelman Software Works =
| IoT =
architect [<br>] [email protected] =
http://www.sandelman.ca/ =
| ruby on rails =
[<br>] My working =
hours and your working hours may be different. =
[<br>] =
Please do not feel obligated to reply outside your normal working =
hours =
[<br><br><br></div></div></blockquote></div><br></div></body><=
/html>=
--Apple-Mail=_6A5F3C13-04C1-4FF1-A1D6-D019DA161394--
--===============2106304914772720073==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc2FhZyBtYWls
aW5nIGxpc3QgLS0gc2FhZ0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHNhYWctbGVhdmVAaWV0Zi5vcmcK
--===============2106304914772720073==--