[saag] Re: New I-D: draft-yossif-psea-01 — Post-Se ssion Execution Assurance (authority gap at execution time)

Michael Richardson <[email protected]> Sat, 09 May 2026 17:08:37 -0400
Newsgroups gmane.ietf.saag
Message-ID <[email protected]>
--===============3442801065565677319==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


[email protected] <[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)

=2D-
]               Never tell me the odds!                 | ipv6 mesh network=
s [
]   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 =
  [



--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmn/olUACgkQgItw+93Q
3WUaxQgApAqugBLPQeVqOwCJbEs9ZKdZC2A0eZMVJKrAKE7Jzedn1seg3aNTv0R8
0rJc9bI+Dw7gCDrlagFt8svYylJnEmyGNVH4fi4DYosrqfj7AIjn1+B9VQLWZISE
OQglXafJZIemxJoOrCTsC6oo0o3siCd4GFP86QVsLtIEZCuntEKSVoiEXjLcRXYZ
AF5yNAg+4TxSIan6fbh6xhKEST0s/6YuoiD+11Ckawr5UNuu7/EA+euGHDq6THT8
W6635LUMSqS74A/UFx4AtF4vVJTIf8IgmaPcPLdO6vw57z+EDU0gr5KJa1ulJzZb
Ruqdc6ecb06+ey3ANw0kZb4gDFbQZg==
=uHlG
-----END PGP SIGNATURE-----
--=-=-=--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc2FhZyBtYWls
aW5nIGxpc3QgLS0gc2FhZ0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHNhYWctbGVhdmVAaWV0Zi5vcmcK

--===============3442801065565677319==--