[Rats] draft-yossif-psea-02: an EAT profile seeking review, and what an audit of its reference implementation found

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

> Hi all,
> 
> I posted this on 25 and 28 July, both times before my subscription was
> confirmed, so both are presumably held. Apologies if any of them
> appears alongside this. There is enough new since the first attempt
> that this is a different message rather than a resend.
> 
> draft-yossif-psea defines an EAT profile and has never been reviewed by
> this group. That is my omission, not an oversight of anyone here.
> 
> https://datatracker.ietf.org/doc/draft-yossif-psea/
> 
> What it is. A compact JWS whose payload is an EAT-JSON claims-set,
> signed ES256 by a user-verification-gated key on the user's
> authenticator, carrying evidence that a human approved one specific
> action at the moment that action executes. It reuses ueid, eat_nonce,
> submods and eat_profile from RFC 9711 alongside JWT registered claims,
> and adds psea_* claims for what EAT does not register: an action-payload
> hash under JCS canonical encoding, a user-verification claim with two
> normative anchoring cases, a monotonic replay counter, and an operation
> and assurance-level binding.
> 
> The new part, and the reason this is worth your time rather than mine.
> 
> Since the first attempt I published a reference Attester and Verifier
> alongside the draft, and then audited them. The reference was never
> conformant to the document it claimed to implement. It omitted two
> REQUIRED claims entirely - ueid and eat_profile - implemented no
> additionalProperties check at all, and compared psea_proof_version as
> an integer against a schema declaring the string "1". Corrected in
> lockstep, and the correction is public along with the vectors the
> profile still fails:
> 
> https://github.com/yuthent/psea-spec/tree/main/conformance
> 
> Twenty-one vectors against an external negative-class list. Thirteen
> pass, three fail, five are not representable against this carrier. The
> three failures are on the record deliberately: no named-principal
> reference, no ordering input between authorization and effect, and a
> composition case where two artifacts verify for one action under
> different principals.
> 
> Four things I would value a read on.
> 
> 1. Section 3.1.1 states the profile in the form RFC 9711 Section 7 asks
> for. Does it state everything that section expects, and is anything in
> it phrased in a way this group would not recognize?
> 
> 2. The profile is strict rather than ignore-unknown: additionalProperties
> false, a conforming Verifier rejects any undeclared claim, any unknown
> version, and any unrecognized crit parameter, and the wire format is
> versioned as a whole rather than extended in place. That departs from
> what EAT and JWT consumers customarily do. Defensible profile decision,
> or mistake?
> 
> 3. ueid carries a deterministic per-issuer value under the RAND type tag
> - 0x01 followed by SHA-256(deviceId || iss) - so one device yields a
> distinct ueid per deployment. Rationale in Section 7.1. This is the item
> I am least confident about and I would rather be told now.
> 
> 4. Section 8.3 requests a urn:ietf:params:psea sub-namespace for the
> profile identifier, with a fallback URI if it is not granted. Is that
> the right mechanism for an EAT profile identifier, and is there
> precedent I should be following instead?
> 
> The ordering failure above may be the most interesting one for this
> group. Nothing in the token establishes that the signature preceded the
> effect it authorizes; iat is producer-asserted and the counter orders
> proofs from one attester against each other, not against a real-world
> event. The next revision states that as a known limitation rather than
> attempting to close it. If this group considers it closable within an
> attestation token rather than needing an external ordering input, that
> would change what the revision should say.
> 
> Mohamad Khalil-Yossif