PSEA Token Profile: An EAT Profile for Action-Bound, User-Verification-Gated Transaction-Confirmation Evidence

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Terminology

This document uses the following terms. RATS terminology follows [RFC9334]; PSEA-specific terms are defined here.¶

Attester

The entity that generates Evidence by producing a proof token signed with a hardware-protected, user-verification-gated key. Concretely the Attester is the composite of (a) a hardware authenticator that holds the signing key and enforces the user-verification gate -- for example a TEE- or Secure-Element-backed mobile keystore, a PIN-gated PIV-class smartcard, or a programmable secure element -- and (b) the host software that assembles the token claim set around that signature. Where the hardware authenticator exposes only a raw user-verification-gated signing primitive, the host computes psea_payload_hash, maintains psea_counter, and populates psea_uv; the authenticator contributes the signature. A standard FIDO2/WebAuthn security key is not a conforming Attester under this profile (Section 1). A natural person is not an Attester.¶

Verifier

The server-side component that appraises Evidence and produces Attestation Results.¶

Relying Party

The application server that gates the action on the Verifier's Attestation Result.¶

Subject (of Evidence)

The natural person whose presence and intent the Attester's Evidence makes claims about.¶

Evidence

The signed proof token an Attester produces per this profile: a user-verification-gated, action-bound execution-authority proof. See Section 3.¶

Attestation Result

The integrity-protected artifact the Verifier produces and returns to the Relying Party.¶

Endorsement

A trust anchor the Verifier uses to appraise Evidence (for example, an Android Key Attestation root, an Apple App Attest root, a FIDO authenticator vendor root, or a smartcard issuer root).¶

action / action payload

The specific operation the Subject approves. The canonical encoding of the action payload is hashed and included in the signed Evidence body (see Section 3.13).¶

capability / assurance level

An abstract indicator of the authority or assurance context a proof is produced under, carried in the signed psea_tier claim and bound into the signature (Section 3.13.4). The value space is opaque to this profile and is agreed out of band between producer and Verifier; this profile does not define a fixed set of levels, and the operational mapping of applications to levels is deployment-specific and out of scope of this profile.¶

2.1. UTF-8 Serialization

The canonical byte sequence MUST be encoded as UTF-8 [RFC3629]. The encoding MUST NOT include a byte-order mark.¶

2.2. Object Key Ordering (UTF-16 Code-Unit Sort)

Object members MUST be ordered as [RFC8785], Section 3.2.3 specifies: property names, in their raw (unescaped) form, are compared as arrays of UTF-16 code units, each code unit treated as an unsigned integer, independent of locale. The comparison MUST NOT normalize case, fold Unicode equivalence classes, or apply collation rules. Two keys that differ only in case (for example, "endedAt" and "endReason") MUST order according to the value of their first differing code unit; in this example, "endReason" (uppercase "R" = U+0052 = 82) sorts before "endedAt" (lowercase "e" at the comparison position = U+0065 = 101) because 82 < 101.¶

For names that contain no character outside the Basic Multilingual Plane, UTF-16 code-unit order, Unicode code-point order, and UTF-8 byte order coincide. They diverge when one name carries a character outside the Basic Multilingual Plane (encoded in UTF-16 as a surrogate pair in the range U+D800 to U+DFFF) and the other carries a character in the range U+E000 to U+FFFF at the same position; the UTF-16 code-unit order governs in that case.¶

This rule is the canonical encoding's most consequential implementer-warning point. See Section 2.8 for cross-platform notes.¶

2.3. Array Ordering

JSON arrays preserve their natural element order; the canonical encoding MUST NOT re-order array elements. The semantics of array order are payload-specific and are defined where applicable in Section 3.¶

2.4. String Serialization

String values MUST be serialized following the encoding rules in [RFC8785], Section 3.2.2.2 (Serialization of Strings). In particular: U+0022 (quotation mark) and U+005C (reverse solidus) MUST be serialized as the two-character escapes \" and \\; U+0008, U+0009, U+000A, U+000C, and U+000D MUST be serialized as the two-character escapes \b, \t, \n, \f, and \r; every other code point in the range U+0000 to U+001F MUST be serialized in the six-character form \uhhhh with lowercase hexadecimal digits; and every other code point is emitted as is. Input containing a lone surrogate (an unpaired code point in the range U+D800 to U+DFFF) MUST cause canonicalization to fail with an error. Canonical encoding does not normalize Unicode form.¶

2.5. Number Serialization (Integers Only)

PSEA payload schemas define numeric fields only as integers. The canonical encoding of an integer N MUST follow [RFC8785], Section 3.2.2.3, which for an integer is its shortest decimal representation (no leading zeros, no "+" sign, no exponent, no decimal point). Because every numeric field defined in this revision is an integer, the floating-point cases of [RFC8785] do not arise; a full RFC 8785 serializer and an implementation of only this integer rule produce identical output for every payload schema defined in this revision.¶

Floating-point numbers, decimal fractions, and exponent notation MUST NOT appear in any PSEA payload field at this revision. A future revision MAY extend the subset; until such an extension is registered, any non-integer numeric value in a signed payload field is non-conformant.¶

This integers-only rule also governs the actionPayload that the action binding hashes (Section 3.13). The actionPayload schema is deployment-defined, but it is hashed under the same canonical encoding, so a JSON floating-point value placed in it would re-introduce exactly the [RFC8785] floating-point serialization divergence this section avoids for the profile's own claims. Accordingly, monetary and other fractional quantities carried in actionPayload MUST be represented as integers in a fixed minor unit (for example, integer cents) or as strings, and MUST NOT be represented as JSON floating-point numbers. The worked example of Appendix A.3 follows this rule (an amount of 2500 minor units, not 25.00). A deployment that places a JSON float in actionPayload falls outside the cross-platform canonicalization guarantee of this section and will observe payload-binding failures between peers whose float serializers differ.¶

2.6. Boolean and Null Serialization

The literals true, false, and null MUST be serialized with their lowercase JSON spelling. null as a value SHOULD NOT appear in PSEA payload schemas; absent fields are conveyed by omitting the key rather than by including the key with a null value.¶

2.7. Whitespace

The canonical encoding MUST NOT include whitespace between tokens (no spaces, tabs, newlines, or carriage returns). Whitespace inside string values is preserved verbatim per Section 2.4.¶

2.8. Conformance and Cross-Platform Implementer Warning

Implementations MUST verify their canonical encoder against the test vectors in Appendix A. A canonical encoder that produces output matching the test vectors for every input in that appendix is conformant; an encoder that diverges on any single test vector is non-conformant and will produce signed bytes that fail peer verification.¶

Specific implementer-warning notes on common platform pitfalls:¶

Apple platforms

JSONSerialization with the sortedKeys option performs a case-insensitive sort, which diverges from this section's case-sensitive rule (see Section 2.2). Implementations on Apple platforms MUST NOT rely on sortedKeys. Swift's default comparison of String values does not compare UTF-16 code units either, so an implementation MUST emit canonical bytes via a manual sort that compares the UTF-16 code units of each name.¶

JavaScript / TypeScript platforms

Array.prototype.sort() on string keys compares UTF-16 code units, matching this section's requirement. JSON.stringify with a comparator option is not standard; use a manual canonicalization pass.¶

Java / Kotlin

String.compareTo() compares UTF-16 code units, matching this section's requirement; the standard JCS implementations in major libraries (Jackson, Gson) produce conformant output when configured for canonical mode.¶

Python

The standard sorted() on strings, and the json module's sort_keys=True, order by Unicode code point, which diverges from UTF-16 code-unit order in the case described in Section 2.2; an implementation MUST sort by the UTF-16 encoding of each name.¶

Go, Rust

Default string comparison on both languages is byte-wise on UTF-8, which matches this section's rule only for names containing no character outside the Basic Multilingual Plane; an implementation MUST sort by the UTF-16 encoding of each name.¶

The most consequential pitfall is an Apple sortedKeys case-insensitive sort silently producing canonical bytes that diverge from a peer using a case-sensitive sort, causing cross-platform signature-verification failures. This is the failure mode the implementer-warning here is specifically designed to prevent.¶

3.1. PSEA as an EAT Profile

The PSEA proof is a profile of the Entity Attestation Token ([RFC9711]), as that term is used in [RFC9711], Section 6. The token is a compact JWS ([RFC7515]) signed with ES256 (ECDSA P-256 with SHA-256) whose payload is an EAT-JSON claims-set. A conforming PSEA proof MUST carry the eat_profile claim ([RFC9711], Section 4.3.2) with the stable profile identifier https://datatracker.ietf.org/doc/draft-yossif-psea/. The claim carries a URI or an OID and [RFC9711] defines no registry for profile identifiers, so this identifier requires no registration and carries no dependency on the publication stream this document appears in. A Verifier MUST reject a proof whose eat_profile claim is absent or carries any other value, except as permitted in Section 3.5.¶

The profile is composed of three claim families:¶

• Registered EAT claims ([RFC9711]). ueid (the per-device identifier, [RFC9711], Section 4.2.1; see the encoding requirement in Section 3.2 and the privacy discussion in Section 7.1), eat_nonce (OPTIONAL freshness nonce), submods (the device-state submodules map), and eat_profile (this profile's identifier).¶
• Registered JWT claims ([RFC7519]). jti, aud, iss, iat, and exp.¶
• Profile extension claims (psea_*). The properties for which EAT defines no registered claim: psea_payload_hash (action-binding payload hash; Section 3.13), psea_tier (capability/assurance-level binding), psea_counter (monotonic per-counter-scope replay counter; Section 3.10), psea_uv (user-verification claim; Section 3.7.1), psea_op (operation binding; Section 3.13.4), and psea_proof_version. The OPTIONAL extension claims psea_chain_prev (deployment-optional hash-chain anchor; Section 3.12), psea_user_hash, psea_caller_package, and psea_sdk_version MAY also be present.¶

This document does not claim that a generic EAT consumer can fully appraise a PSEA proof without understanding the psea_* extension claims; the extension claims are profile-specific and are defined normatively in Section 3. The eat_profile claim signals to a consumer which extension semantics apply.¶

3.2. Top-Level Structure

JWS Compact Serialization (value of the transport-body "proof" field)

   BASE64URL(UTF8(protected header))
   || "." || BASE64URL(JCS-canonical-JSON(payload))
   || "." || BASE64URL(r || s)        ; ES256, see Signature below

Protected header (a JSON object; base64url-encoded, no padding)
+-- alg   ; "ES256"  (ECDSA P-256 with SHA-256)
+-- kid   ; opaque, deployment-internal enrollment-lookup selector,
|         ;   untrusted until verified (a forged kid fails: the wrong
|         ;   key will not validate the signature). The SHA-256 of the
|         ;   signing-key SubjectPublicKeyInfo (SPKI) in standard base64
|         ;   is one ILLUSTRATIVE derivation; the value space is not
|         ;   constrained by this profile.
+-- typ   ; "psea-proof+jwt"

Payload (the claim set; base64url-encoded, no padding)
  JWT registered claims (RFC 7519)
  +-- jti   ; action id; also the global-uniqueness key
  +-- aud   ; intended Verifier/audience identifier (RFC 7519)
  +-- iss   ; tenant / deployment id
  +-- iat   ; NumericDate, epoch SECONDS
  +-- exp   ; NumericDate, epoch SECONDS
  EAT claims (RFC 9711)
  +-- ueid          ; base64url no-pad of the RAND-type UEID byte
  |                 ;   string, 33 bytes:
  |                 ;     0x01 || SHA-256(JCS({"deviceId": <deviceId>,
  |                 ;                          "iss": <iss>}))
  |                 ;   The two inputs are encoded as a canonical JSON
  |                 ;   object (RFC 8785), not concatenated, so the
  |                 ;   pair cannot be read two ways.
  |                 ;   Per-issuer (pairwise): the same device yields
  |                 ;   a distinct ueid per deployment
  |                 ;   (RFC 9711 Sec 4.2.1.1; 0x01 = RAND type tag)
  [+-- eat_nonce]   ; OPTIONAL server nonce for push-initiated
  |                 ;   freshness; omitted entirely when absent
  [+-- submods]     ; OPTIONAL; { "psea-device-state": {...} } --
  |                 ;   device-state appraisal input; contents
  |                 ;   out of scope of this document
  +-- eat_profile   ; "https://datatracker.ietf.org/doc/
  |                 ;    draft-yossif-psea/"  -- one string; wrapped
  |                 ;    here only to fit the diagram
  |                 ;   (RFC 9711 Sec 4.3.2); REQUIRED
  PSEA-private extension claims
  +-- psea_tier            ; capability/assurance indicator (opaque;
  |                        ;   deployment-defined value space)
  +-- psea_counter         ; JSON integer [0, 2^53-1], monotonic per
  |                        ;   (attester, counter scope)
  +-- psea_payload_hash    ; standard base64 of SHA-256(canonical
  |                        ;   actionPayload) -- the action binding
  +-- psea_op              ; operation/authority-context discriminator
  |                        ;   (REQUIRED; see cross-replay binding)
  +-- psea_uv              ; { "verified": bool, "method": string }
  |                        ;   user-verification (human-presence) claim;
  |                        ;   REQUIRED; see the psea_uv section
  +-- psea_proof_version   ; "1"
  [+-- psea_chain_prev]    ; OPTIONAL deployment-optional hash-chain
  |                        ;   anchor; 64-char lowercase hex
  |                        ;   (sentinel: 64 ASCII '0' for first proof);
  |                        ;   present only when the deployment enables
  |                        ;   the chain layer (see ChainEntry section)
  [+-- psea_caller_package] ; OPTIONAL; reverse-DNS app identifier
  [+-- psea_sdk_version]    ; OPTIONAL; Attester implementation version
  [+-- psea_user_hash]     ; OPTIONAL; base64url no-pad; omitted
                           ;   entirely when empty

Signature
   ECDSA P-256 (ES256). The signature is the fixed-width 64-byte
   concatenation of the (r, s) integers, base64url no-pad, computed
   over ASCII(headerB64 || "." || payloadB64). This is the JWS ES256
   signature encoding (RFC 7518 Sec 3.4), NOT a DER/ASN.1 encoding.

Encoding split: ueid uses base64url (no padding) of the 33-byte
RAND-type UEID; psea_payload_hash uses standard base64 (with
padding); psea_user_hash uses base64url (no padding).

NOTE on chainEntry (deployment-optional layer): when a deployment
enables the hash-chain tamper-evidence layer, the Attester sends
psea_chain_prev IN the signed payload (the prior proof's chainEntry,
or the sentinel for the first proof). chainEntry itself is not carried
inbound: the Verifier recomputes this proof's chainEntry from the
signed inputs (see the ChainEntry section). The mechanism by which the
recomputed chainEntry is conveyed back to the Attester for use as the
next proof's psea_chain_prev is deployment-specific and out of scope.
Deployments that do not enable the chain layer omit psea_chain_prev
entirely.

Base64 encoding split (normative): psea_payload_hash MUST be encoded as standard base64 ([RFC4648], Section 4) with padding (the pattern ^[A-Za-z0-9+/]{42}[AEIMQUYcgkosw048]=$; the restricted final-sextet class rejects non-canonical encodings of the 32-octet digest, whose trailing two bits are always zero). ueid and psea_user_hash MUST be encoded as base64url ([RFC4648], Section 5) without padding. This is a deliberate per-claim encoding split that implementers MUST observe exactly; using base64url for psea_payload_hash or standard base64 for ueid or psea_user_hash produces a non-conformant token.¶

The two encodings are not interchangeable; they carry the same underlying octets and differ only in alphabet and padding. A Verifier validates each claim against the exact pattern in Section 3.5.¶

The operation a proof is presented for determines which psea_tier and psea_op values the Verifier expects in the payload; the expected values are deployment-defined and agreed out of band. The payload's psea_tier, psea_op, aud, and iss claims together close the cross-replay attack surface (Section 3.13.4).¶

The transport body POSTed to the endpoint wraps the JWS in the proof field and carries the cleartext action and evidence alongside it:¶

{
  "proof":             "<compact JWS>",
  "actionPayload":     { ... },  // unsigned cleartext; the
                                 //   Verifier re-canonicalizes,
                                 //   SHA-256s, and compares against
                                 //   psea_payload_hash
  "integrityEvidence": { ... },  // OPTIONAL attestation evidence
  "requestId":         "...",    // OPTIONAL opaque request id
  "signalReport":      { ... },  // OPTIONAL device-signal report
  "proofId":           "..."     // OPTIONAL opaque proof
                                 //   identifier
}

The actionPayload is unsigned cleartext; the Verifier re-canonicalizes it (Section 2), takes its SHA-256, and compares the result against the signed psea_payload_hash claim. This comparison is the fail-closed action binding (Section 3.13). Because a compact JWS has a single authoritative payload, the proof carries no envelope-level duplicates of the signed claims.¶

3.3. Single Authoritative Payload (No Envelope Duplicates)

A compact JWS has a single, cryptographically attested payload. The PSEA proof format therefore carries no envelope-level duplicates of its signed claims, and there is no envelope-versus-signed-body consistency check to perform: the only field a Verifier reads ahead of signature verification is the protected-header kid, which is the untrusted-until-verified enrollment-lookup selector. A forged kid fails verification because the key it selects will not validate the signature, so no separate envelope-body comparison is needed to defend against a substituted routing value.¶

The Verifier looks up the enrollment by kid, verifies the JWS signature with the enrolled key, and only then reads the authentic claim set (including jti, psea_counter, psea_payload_hash, and ueid) directly from the verified payload. There are no pre-signature lookup copies of these values to reconcile.¶

A compact JWS carries a single authoritative payload, so there is no envelope/body pair to reconcile and this profile defines no envelope-body mismatch error codes. A Verifier reads the signed claim set (jti, psea_counter, psea_payload_hash, ueid) directly from the verified payload.¶

3.4. JOSE Header Hardening (Normative)

Because a JWS protected header is attacker-influenceable until the signature is verified, a Verifier MUST apply the following constraints to every PSEA proof JWS before trusting any claim. A deployment that represents its Verifier acknowledgement / Attestation Result as a JWS — that artifact's format is out of scope of this profile (Section 3.13.3) — SHOULD apply equivalent header hardening when the Attester consumes it:¶

• The Verifier MUST reject any JWS whose protected-header alg is not "ES256". ES256 is the only mandatory-to-implement algorithm at this revision (Section 9.1.1); a Verifier that does not implement algorithm negotiation (Section 9.1.3) MUST NOT accept any other alg value.¶
• The Verifier MUST reject any JWS whose protected-header alg is "none". An unsigned token MUST NOT be accepted under any circumstance.¶
• The Verifier MUST ignore any key material embedded in the JWS header, including the jwk, jku, and x5u header parameters. The verification key is resolved only from the enrolled record selected by the untrusted-until-verified kid; the Verifier MUST NOT verify a PSEA JWS against any key conveyed in or referenced by the token itself.¶
• The Verifier MUST verify the protected-header typ value. A PSEA proof carries typ = "psea-proof+jwt", and a consumer expecting a proof MUST reject a JWS whose typ is not "psea-proof+jwt". A deployment that defines a Verifier acknowledgement / Attestation Result as a JWS (out of scope of this profile) SHOULD give it a distinct typ — for example "psea-ack+jwt" — applying the explicit-typing guidance of [RFC8725], Section 3.11, so that a proof cannot be processed as an acknowledgement or the reverse.¶
• The Verifier MUST reject any JWS that carries a crit header parameter naming an extension this profile does not define, and MUST reject any JWS that uses the unencoded-payload option (the b64 header parameter set to false, [RFC7797]). A conforming PSEA JWS uses only the base64url-encoded payload form and defines no critical header extensions at this revision.¶

These constraints close the classic JOSE downgrade and key-confusion attacks (algorithm substitution, alg:"none", attacker-supplied verification keys, cross-type confusion between proof and acknowledgement, and unencoded-payload / unknown-critical-header tricks) at the protocol's wire surface, and align with the JSON Web Token Best Current Practices ([RFC8725]); see also Section 6.4.1.¶

3.5. JWS Payload Claim Set

The following JSON Schema describes the claim set carried in the BASE64URL(payload) segment of the PSEA proof JWS. The claims combine JWT registered claims ([RFC7519]), a subset of EAT claims ([RFC9711]), and PSEA-private psea_* claims. eat_nonce and psea_user_hash are optional and, when not applicable, are omitted entirely rather than serialized as empty or null.¶

The schema sets additionalProperties: false. This is deliberate: as stated in the "Extensibility model" entry of Section 3.1.1, this profile is a strict lock-step profile, so a Verifier rejects a proof carrying any claim outside the set below, and a future psea_* claim is by design rejected by current-revision Verifiers until they are upgraded. This departs from the ignore-unknown-claims extensibility customary for EAT and JWT.¶

Two OPTIONAL members, psea_chain_pending and psea_last_confirmed_head, are registered in the schema below as opaque diagnostic extension members: they are permitted so that proofs carrying deployment-defined diagnostic context are not rejected by additionalProperties: false, but they carry no Verifier appraisal obligation, and a Verifier that does not recognize them ignores them.¶

The OPTIONAL member psea_rp_context_hash is not a diagnostic member and is not ignorable in the same way. A deployment MAY bind a relying-party request context to a proof; where a deployment does so, this claim carries that binding and a Verifier in that deployment appraises it. A binding that is carried but never appraised confers nothing. Whether a deployment establishes such a context at all, and the content model of the context, are deployment-defined and out of scope of this profile, which requires no deployment to establish one.¶

The OPTIONAL member psea_signals_hash commits the proof to an auxiliary document carried beside it in the transport body (Section 3.6) rather than inside the signed payload. It relates to that document as psea_payload_hash relates to actionPayload: the digest is signed, the document is not, and the document is bound only to the extent that a Verifier recomputes the digest over it. The document's content model is deployment-defined and out of scope. A deployment MAY require psea_signals_hash on every proof, and a Verifier in such a deployment MUST refuse a proof that omits it: without the claim the auxiliary document is unsigned and can be stripped, substituted, or replayed independently of the proof.¶

The OPTIONAL member psea_chain_prev is carried only where the deployment enables the chain layer (Section 3.12). A deployment that enables it MAY require the claim on every proof, and a Verifier in such a deployment MUST refuse a proof that omits it: a proof without the claim bypasses the linkage check, so it could be inserted into the stored proof sequence without the gap being detected.¶

The OPTIONAL member psea_stepup_selection is carried only where the deployment, before the signature, asked the user a step-up question about the action and holds a commitment to the expected answer. The claim places a commitment to the user's selection inside the signed payload, so the selection is covered by the proof signature. How the question is formed, how the commitment is constructed, and how the Verifier obtains the value it compares against are deployment-defined and out of scope of this profile. A deployment that issued such a step-up for an action MAY require the claim on the proof for that action, and a Verifier in such a deployment MUST refuse a proof that omits it or whose value does not match.¶

The eat_profile claim carries the profile identifier of Section 3.1, and a conforming Attester emits only that value. Notwithstanding the enumeration in the schema below, a Verifier MAY additionally accept the value urn:ietf:params:psea:eat-profile:2, which implementations built before this revision emit, provided every other requirement of this profile is met. That value is not a registered URN: this document requests no registration in the urn:ietf:params namespace, and the value is accepted only as an identifier emitted by earlier implementations, never as one a new Attester emits.¶

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "PseaProofClaims",
  "description": "The JWS payload claim set for the PSEA proof.",
  "type": "object",
  "required": [
    "jti", "aud", "iss", "iat", "exp", "ueid", "eat_profile",
    "psea_tier", "psea_op", "psea_counter", "psea_payload_hash",
    "psea_uv", "psea_proof_version"
  ],
  "properties": {
    "jti":  { "type": "string", "minLength": 1, "maxLength": 128,
              "pattern": "^[A-Za-z0-9._-]+$",
              "description": "Action id; also the global-uniqueness
                key. Alphanumeric/dot/underscore/hyphen only. UUID
                RECOMMENDED." },
    "aud":  { "type": "string", "minLength": 1, "maxLength": 256,
              "description": "JWT audience (RFC 7519): identifier of
                the intended Verifier/audience. See cross-replay
                binding." },
    "iss":  { "type": "string", "minLength": 1, "maxLength": 128,
              "description": "Tenant / deployment identifier;
                verified against the deployment/tenant the Verifier
                resolves for the request. See cross-replay
                binding." },
    "iat":  { "type": "integer", "minimum": 0,
              "description": "NumericDate; epoch SECONDS." },
    "exp":  { "type": "integer", "minimum": 0,
              "description": "NumericDate; epoch SECONDS." },
    "ueid": { "type": "string", "pattern": "^[A-Za-z0-9_-]{44}$",
              "description": "RFC 9711 Sec 4.2.1.1 RAND-type UEID:
                base64url (no padding) of the 33-byte string 0x01 ||
                SHA-256(JCS({\"deviceId\": <deviceId>, \"iss\":
                <iss>})). JCS is the RFC 8785 canonical form of that
                two-member object; the inputs are encoded, not
                concatenated, so the pair cannot be read two ways.
                Per-issuer (pairwise): the same device yields a
                distinct ueid per iss, preventing cross-deployment
                correlation. The leading 0x01 is the RAND type tag.
                See Privacy Considerations." },
    "eat_nonce": { "type": "string",
              "description": "OPTIONAL. Server nonce for
                push-initiated freshness. Omitted entirely when
                absent." },
    "submods": { "type": "object",
              "properties": {
                "psea-device-state": { "type": "object",
                  "description": "Reserved placeholder extension
                    point; contributes nothing wire-normative in this
                    revision (contents out of scope)." }
              },
              "description": "OPTIONAL EAT submodules map. The
                psea-device-state submodule is a reserved,
                deployment-specific placeholder; an authenticator
                that cannot produce device-state omits submods
                entirely." },
    "eat_profile": { "type": "string",
      "enum": [
        "https://datatracker.ietf.org/doc/draft-yossif-psea/"
      ],
              "description": "EAT profile identifier (RFC 9711 Sec
                4.3.2). REQUIRED. This document fixes exactly one
                value for this claim. The claim carries a URI or an
                OID and RFC 9711 defines no registry for profile
                identifiers, so no registration is requested for this
                value." },
    "psea_tier": { "type": "string", "minLength": 1,
              "maxLength": 128,
              "description": "Capability/assurance-level binding.
                Opaque to this profile; deployment-defined value
                space agreed out of band. The Verifier rejects the
                proof if it does not match the level expected for the
                operation. See cross-replay binding." },
    "psea_op": { "type": "string", "minLength": 1, "maxLength": 128,
              "description": "Operation / authority-context
                discriminator the proof is bound to. Opaque to this
                profile; the Verifier rejects the proof if it does
                not match the operation being performed. See
                cross-replay binding." },
    "psea_counter": { "type": "integer", "minimum": 0,
                      "maximum": 9007199254740991,
              "description": "Monotonic per (attester, counter
                scope). JSON integer in [0, 2^53-1]; see counter
                model." },
    "psea_payload_hash": { "type": "string",
              "pattern": "^[A-Za-z0-9+/]{42}[AEIMQUYcgkosw048]=$",
              "description": "Standard base64 (with padding) of
                SHA-256(canonical actionPayload); the action binding.
                The restricted final-sextet class rejects
                non-canonical encodings (the digest's trailing two
                bits are always zero). See action binding." },
    "psea_chain_prev": { "type": "string",
              "pattern": "^[0-9a-f]{64}$",
              "description": "OPTIONAL deployment-optional hash-chain
                anchor. 64-char lowercase hex; sentinel 64 ASCII '0'
                for the first proof. Present only when the deployment
                enables the chain tamper-evidence layer. See
                ChainEntry." },
    "psea_uv": { "type": "object",
              "required": ["verified", "method"],
              "properties": {
                "verified": { "type": "boolean",
                  "description": "Whether a contemporaneous user-
                    verification event gated this signature." },
                "method": { "type": "string",
                  "description": "User-verification method.
                    Extensible string; suggested baseline values
                    include \"biometric\", \"pin\", \"fido_uv\" (no
                    IANA registry is defined). Unknown values MUST be
                    tolerated." }
              },
              "description": "User-verification claim. REQUIRED on
                the PSEA proof. The Verifier MUST require
                verified==true and MUST cross-check it against the
                authenticator's attested UV-enforcement where the
                attestation conveys it. See the user-verification
                claim section." },
    "psea_proof_version": { "type": "string", "enum": ["1"] },
    "psea_caller_package": { "type": "string", "minLength": 1,
              "maxLength": 256,
              "description": "OPTIONAL profile-extension claim.
                Reverse-DNS identifier of the calling
                application." },
    "psea_sdk_version": { "type": "string", "maxLength": 64,
      "description": "OPTIONAL profile-extension claim. Attester
        implementation version." },
    "psea_signals_hash": { "type": "string",
      "pattern": "^[A-Za-z0-9+/]{42}[AEIMQUYcgkosw048]=$",
      "description": "OPTIONAL profile-extension claim. Standard
        base64 (with padding) of SHA-256 over the canonical form of
        an auxiliary document carried beside the proof in the
        transport body rather than inside the signed payload. Its
        presence commits the proof to that document, so the document
        cannot be substituted, stripped, or replayed independently of
        the signature. Same canonicalization and encoding as
        psea_payload_hash; the restricted final-sextet class rejects
        non-canonical encodings. The document's content model is
        deployment-defined and out of scope." },
    "psea_user_hash": { "type": "string",
              "pattern": "^[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]$",
      "description": "OPTIONAL. base64url (no padding) of
        SHA-256(subject_id): a pairwise, deployment-local commitment
        to the enrolled subject that establishes no identity, which a
        Verifier MAY require to match the enrollment record (see
        Subject Hash). The restricted final-sextet class rejects
        non-canonical encodings. Omitted entirely when empty. MUST be
        derived pairwise per issuer (see Privacy Considerations)." },
    "psea_chain_pending": {
      "description": "OPTIONAL registered opaque profile-extension
        member; empty schema (any JSON value). Semantics are
        deployment-defined and out of scope; the member carries no
        Verifier appraisal obligation, and a Verifier that does not
        recognize it ignores it. Present only when the deployment's
        chain gap-tolerance layer emits it." },
    "psea_last_confirmed_head": {
      "description": "OPTIONAL registered opaque profile-extension
        member; empty schema (any JSON value). Semantics are
        deployment-defined and out of scope; the member carries no
        Verifier appraisal obligation, and a Verifier that does not
        recognize it ignores it. Present only when the deployment's
        chain gap-tolerance layer emits it." },
    "psea_stepup_selection": { "type": "string",
      "pattern": "^[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]$",
      "description": "OPTIONAL profile-extension claim. base64url
        (no padding) of a 32-octet commitment to a selection the
        user made in a deployment-defined step-up interaction about
        the action. Present only when the deployment issued such a
        step-up for this action. The commitment's construction and
        the value a Verifier compares it against are
        deployment-defined and out of scope." },
    "psea_rp_context_hash": {
      "description": "OPTIONAL profile-extension member; empty schema
        (any JSON value). Present only when the deployment binds a
        relying-party request context. Where a deployment establishes
        such a context, this member carries that binding and a
        Verifier in that deployment appraises it rather than ignoring
        it. The content model of the context is deployment-defined
        and out of scope." }
  },
  "additionalProperties": false
}

3.6. Wire Transport Bodies

A PSEA proof is submitted to the Verifier in a transport body of the form { proof, actionPayload, integrityEvidence?, requestId?, signalReport?, proofId? }, where proof is the compact JWS (Section 3.2), actionPayload is the unsigned cleartext action bound by psea_payload_hash (Section 3.13), and integrityEvidence is an OPTIONAL attestation evidence block whose contents are out of scope of this profile. The concrete transport (HTTP method and path) is deployment-specific and out of scope.¶

Of the transport-body fields, only proof is signed, and actionPayload is cryptographically bound to it through psea_payload_hash (Section 3.13). The remaining fields — integrityEvidence, requestId, signalReport, and proofId — are unsigned and attacker-mutable in transit. A Verifier MUST NOT use any unsigned transport-body field as an input to a security decision. integrityEvidence is appraised on its own cryptographic merits against the platform Endorsement (its appraisal does not trust the envelope framing); requestId and proofId are correlation and operational hints only and confer no authority.¶

signalReport is not unconditionally in that last category. Where the proof carries psea_signals_hash (Section 3.5), that claim commits to the report, and a Verifier in such a deployment appraises the received report against the claim by recomputing the digest over it — the same relation actionPayload bears to psea_payload_hash. A report appraised in that way is a committed field rather than an unsigned one, so the rule above is not engaged by it. Where the claim is absent, or where no such comparison has been made, signalReport is an unsigned hint conferring no authority and the rule above applies to it without qualification.¶

3.7. Human Presence via User-Verification-Gated Signature

This profile establishes the human-presence requirement through the signing operation itself rather than through a separate wire-level presence block. The Attester's hardware-protected signing key MUST be gated by a platform user-verification event such that the signing operation cannot complete without a successful, contemporaneous user-verification ceremony. The signed proof body is therefore implicit Evidence that a user-verification event occurred at the moment of signing; the signature itself is the presence commitment.¶

Per-operation gating (normative). The user-verification gate MUST be enforced per signing operation: each proof signature MUST be preceded by its own fresh user-verification event. A configuration in which a single user-verification event authorizes signing for a time window or for multiple subsequent signatures (duration- or window-based authentication) is NOT RECOMMENDED for any signing and is non-conformant for proof signing: it would let a compromised host pre-compute a batch of proofs from one ceremony (see Section 6.4.1, Paragraph 3). A conforming Attester binds exactly one user-verification event to exactly one proof signature.¶

This rules out "authenticate-once-then-reuse" key configurations. By way of example, the following common platform configurations are non-conformant for proof signing, and only their per-operation counterparts conform: a PIV-class smartcard in PIN-once mode (only a PIN-always / per-signature PIN policy conforms); an Android Keystore key with a non-zero user-authentication validity timeout (only a timeout of 0 — authentication required for every use — conforms); and an iOS authentication context reused across multiple signing operations (a fresh, non-reused authentication context per signature is required). The specific platform mechanism is out of scope; the normative requirement is the one-verification-per-signature binding above.¶

The user-verification mechanisms that gate the signing key — for example, a platform biometric subsystem (fingerprint or face match), a Secure Enclave PIN entry, a hardware-token PIN, a smartcard with PIN, a magnetic-stripe credential combined with a PIN, or any equivalent platform user-verification primitive — are out of scope of this specification. The specific per-authenticator mechanism is mechanism-agnostic; what is normative is that the signing operation cannot complete without a contemporaneous user-verification event and that the proof carries an explicit psea_uv claim asserting that fact (Section 3.7.1).¶

The Verifier MUST NOT infer presence silently from the bare existence of a signature from the hardware-protected signing key. For the PSEA proof it MUST require the explicit psea_uv claim and, where the authenticator's attestation conveys a UV-enforcement property, cross-check the claim against that attested property (appraised through the authenticator attestation and the deployment's Reference Values). The detailed normative rule, and the statement of where this property is attested versus where it rests on a documented trust assumption, are given in Section 3.7.1.¶

This design uses a single, compact user-verification claim rather than a parallel wire-level presence block whose other fields would duplicate information already carried by the attestation evidence (in integrityEvidence) for platforms that bundle user-verification into the attestation chain. The cryptographic anchor for "a human was present at the moment of signing" is the psea_uv claim covered by the proof signature plus the hardware-protected-key attestation against which it is cross-checked.¶

3.8. Subject Hash (psea_user_hash)

The OPTIONAL psea_user_hash claim (Section 3.5) is an Attester-signed subject-binding commitment: the SHA-256 of an opaque, deployment-issued subject identifier, encoded as base64url without padding. The claim cryptographically attributes the action to a subject identifier for the audit trail. It is a pairwise, deployment-local commitment to the enrolled subject: it does not establish who the subject is, and a Verifier MUST NOT treat it as proof of the identity of any person.¶

When present, psea_user_hash MUST be derived so that it does not function as a cross-deployment correlator, mirroring the pairwise ueid derivation (Section 7.1): the subject identifier MUST be bound to the deployment before hashing — for example by salting the hash input with a per-issuer (iss) secret not published with the proofs, or by deriving a per-issuer subject identifier. A deployment MUST NOT emit a bare SHA-256 of a globally stable subject identifier (see Section 7.2).¶

A Verifier MAY require that the per-proof psea_user_hash match the value recorded for the subject at enrollment. A Verifier that does so MUST refuse a proof whose psea_user_hash is absent or does not byte-exactly equal the recorded value. Such a check establishes only that the proof was produced for the same deployment-issued subject identifier the enrollment recorded; it does not establish which natural person that identifier denotes. The cryptographic chain of authorization at the Verifier continues to rest on the device-bound signature, the monotonic counter, and the presence Evidence (Section 3.7); the subject-hash comparison is a consistency check against the enrollment record, not a substitute for any of them.¶

The per-proof psea_user_hash is distinct from the enrollment-bound subject binding a deployment records at enrollment time. The binding between the recorded value and a natural person is established at enrollment, by the deployment's enrollment ceremony and identity proofing, and is out of scope of this profile (Section 6.3).¶

3.9. Device-State Submodule (submods.psea-device-state)

The OPTIONAL psea-device-state submodule of the EAT submods map (Section 3.5) carries an opaque device-posture commitment from the Attester. Its contents and the Verifier's appraisal logic are out of scope of this document. An authenticator that cannot produce device-state omits submods entirely.¶

On the wire, the psea-device-state submodule is a JSON object whose internal structure is not constrained by this specification. The Verifier appraises the commitment as part of the deployment's policy evaluation; the wire surface visible to the Attester is binary -- the Verifier either accepts the commitment (the proof proceeds through subsequent appraisal steps) or rejects the proof through the deployment's policy verdict. The appraisal mechanism the Verifier applies, the categorical properties the commitment may carry, and any operator-side controls over appraisal sensitivity are deployment-specific and outside the scope of this specification.¶

Because the submodule travels inside the signed JWS payload, its bytes are covered by the proof signature as written; a future revision of this document MAY define a normative sealed commitment form for the submodule, but until such a revision is published, conforming implementations treat submods.psea-device-state as an opaque deployment-specific object whose contents are out of scope.¶

3.10. Counter Model (Monotonic Replay Ordering)

The signed psea_counter claim is a monotonic replay-ordering anchor. The Verifier compares the submitted value against the last-accepted counter value it holds for the same Attester and the same counter scope (see below); a value that is not strictly greater than the stored value for that scope MUST cause the Verifier to reject the proof.¶

An Attester MAY maintain a single counter or several independent counter scopes, and emits in psea_counter the value of the scope the proof is produced under. The number of scopes, and the mapping of an application's actions to scopes, is deployment-specific and out of scope of this profile. Independent scopes serve only to preserve independent offline progress: if proofs produced offline under different scopes drew every value from one shared sequence, an offline-signed proof would collide on submission with a proof signed under another scope after the first was composed but before it was synced. Independent scopes let each progress without colliding.¶

Scope selection (normative). When a deployment uses more than one counter scope, the value that identifies the scope a proof was produced under MUST be cryptographically bound to that proof — either carried as a signed claim (for example psea_tier) or carried in the action payload and therefore covered by the signed psea_payload_hash (Section 3.13). A Verifier MUST select the stored counter value to compare against using only such a bound scope identifier, and MUST NOT derive the scope from any field that is not covered by the signature or by the action-binding hash. This closes the otherwise-exploitable case in which an attacker steers the comparison toward a stale bucket by altering an unbound scope selector. Because the action-binding check (Section 3.13.2) MUST run and fail-closed before the counter comparison is reached, a scope identifier conveyed in the action payload is fully bound at the point the Verifier selects the bucket. A deployment that maintains a single counter has no scope to select and emits one monotonic sequence.¶

The cross-scope replay surface that a single counter would defend against (a captured proof submitted under a different scope) is closed instead by a global action-identifier uniqueness check the Verifier MUST maintain (each jti action identifier finalizes exactly once) plus the cross-replay binding of Section 3.13.4 (the signed psea_tier + psea_op bindings force operation-correctness independent of counter scope). The Verifier MUST retain each finalized jti for at least as long as a proof bearing it could still be within its exp validity window (that is, at least until the maximum exp the Verifier will accept has passed); a jti MAY be evicted once no proof carrying it could still pass the exp freshness check. A Verifier that retains finalized jti values for less than the exp window reopens the replay surface this check exists to close.¶

Atomicity (normative). A Verifier MUST perform the counter comparison-and-advance and the jti finalization atomically — serialized per (Attester, counter scope) — within a single transaction: read the stored counter, compare, and conditionally advance in one atomic step that also records the jti. The counter value compared MUST be the value read inside that transaction (not a value read earlier), and the stored value MUST be advanced only when the submitted counter is strictly greater than it. A blind last-write-wins advance is non-conformant. This guarantees that two concurrent or out-of-order submissions cannot both commit and cannot lower (regress) the stored high-water mark: of any set of submissions racing at a given scope, at most one advances, and a later-arriving lower counter is rejected rather than overwriting a higher stored value.¶

Interoperability bound (normative): Producers MUST emit psea_counter as a JSON integer in the range [0, 2⁵³ − 1] (inclusive) so that the value round-trips losslessly through IEEE 754 double-precision JSON parsers. Verifiers MUST treat the claim as a 64-bit unsigned integer for comparison purposes. This profile does not string-encode the counter; a string-valued psea_counter is non-conformant. At any reasonable operational rate a producer never approaches the 2⁵³ bound, but producers MUST enforce this bound explicitly.¶

3.11. Freshness and Expiry

The signed iat and exp claims ([RFC7519]) bound the time window in which a proof is acceptable. Both are NumericDate values in epoch seconds and are REQUIRED (Section 3.5). A producer MUST set iat to the time of signing and exp to a value no later than iat plus the deployment's maximum proof lifetime.¶

A Verifier MUST reject a proof whose exp is at or before the current time, and MUST reject a proof whose iat is implausibly in the future. The Verifier MAY allow a small clock-skew tolerance when applying these checks; the tolerance SHOULD NOT exceed 60 seconds. The Verifier SHOULD additionally enforce a bounded maximum acceptable proof lifetime (the interval between iat and exp); a RECOMMENDED bound is given in Section 9.2. These checks MUST be applied after signature verification and before any state mutation.¶

The iat/exp window complements, but does not replace, the replay defenses of Section 3.10: the monotonic psea_counter provides ordering, the global jti uniqueness check ensures each action finalizes exactly once, and the OPTIONAL eat_nonce (when the Verifier issued a challenge) binds the proof to that challenge. A deployment that produces proofs offline for deferred submission MUST choose an exp margin wide enough to cover its expected offline-to-sync interval; the freshness anchor for such proofs is then the counter and the jti uniqueness check rather than a narrow exp window.¶

When a Verifier issued a challenge, it MUST correlate the returned proof to the issued challenge using only the signed eat_nonce claim value read from the verified payload — for example, by looking up its outstanding-challenge state keyed on the nonce value itself. A Verifier MUST NOT rely on any unsigned transport-body field (for example requestId, Section 3.6) to decide which issued challenge a proof answers, because an unsigned field is attacker-mutable in transit and a mismatched correlation could let a proof carrying one (signed) nonce be accepted against a different outstanding challenge. The eat_nonce value is covered by the proof signature, so keying the correlation on it keeps the challenge-to-proof binding within the signed surface.¶

3.12. ChainEntry (Deployment-Optional Tamper-Evidence Layer)

The chainEntry is a deterministic hash-chain anchor that links each proof to the prior proof from the same Attester. It provides a per-Attester tamper-evident ledger of accepted proofs in addition to the monotonic ordering already provided by psea_counter (Section 3.10); its value is detecting after-the-fact alteration or omission within a stored proof sequence, not freshness, which the counter and the action-binding already supply.¶

The chain is a deployment-optional layer. A deployment MAY enable it; when enabled, the Attester carries the prior proof's chainEntry inbound as the psea_chain_prev claim and the Verifier behaves as specified in Section 3.12.3. A deployment that does not enable the chain MUST omit psea_chain_prev entirely (the claim is OPTIONAL in Section 3.5), and a Verifier that does not implement the chain ignores it.¶

Completing the chain loop requires the Verifier to convey each recomputed chainEntry back to the Attester so it can serve as the next proof's psea_chain_prev. That conveyance rides on the Verifier acknowledgement / Attestation Result, whose format is deployment-specific and out of scope of this profile. Two independent implementations therefore interoperate on the chain only after they additionally agree on that out-of-scope acknowledgement format; the chain is consequently specified here as an optional deployment feature rather than a mandatory wire element, and a self-contained conforming Verifier (Appendix B.3) is not required to implement it.¶

encode(s)  = u32_be(len(utf8(s))) || utf8(s)

input      = encode(actionId)
          || encode(decimal(counter))
          || encode(chainPrev)

chainEntry = lowercase_hex( SHA-256( input ) )

Offset  Bytes                                Description
─────────────────────────────────────────────────────────────────────
[00–03] 00 00 00 24                          u32_be(36) = len(actionId)
[04–39] 35 35 30 65 38 34 30 30 ...          actionId UTF-8 (36 bytes)
[40–43] 00 00 00 02                          u32_be(2)  = len("42")
[44–45] 34 32                                "42" UTF-8 (2 bytes)
[46–49] 00 00 00 40                          u32_be(64) = len(chainPrev)
[50–113] 30 30 30 30 ...                     chainPrev UTF-8 (64 bytes)
─────────────────────────────────────────────────────────────────────
Total: 114 bytes → SHA-256 → 64 hex chars

3.13. Action Binding (Fail-Closed by Default)

PSEA's execution-authority guarantee requires that an approved action be cryptographically bound to a specific action payload. Without this binding, a captured proof from one execution can be replayed against a different payload at the Verifier.¶

3.14. Enrollment Lifecycle and Trust Gate (Verifier)

The enrollment ceremony that binds a kid to an enrolled signing key and to a subject is deployment-specific and out of scope of this profile (Section 3.13.3). The enrollment lifecycle states that the Verifier enforces on every proof are, by contrast, in scope and normative, because they are the trust gate that makes the rest of the profile meaningful: a valid signature from an enrolled key is necessary but not sufficient for acceptance.¶

A conforming Verifier MUST maintain an authoritative, server-side enrollment lifecycle for each enrolled Attester with at least the states active, suspended, and revoked, and MUST reject any proof whose enrollment is not in the active state. This enrollment-status check is authoritative: this profile carries no self-asserted wire trust-state field, and a Verifier MUST NOT derive the trust state from any value the Attester supplies. The check MUST be applied after signature verification and before any state mutation. The transitions between these states, and the events that trigger them, are deployment-specific; the requirement here is only that the three states exist and gate acceptance. The Elevation-of-Privilege analysis in Section 6.4.6 relies on this requirement.¶

3.15. Versioning

The psea_proof_version claim identifies the wire-format revision the producer targets. This revision uses "1". Future revisions MAY extend the value space; a Verifier MUST reject a proof carrying an unknown version value. Conforming implementations at this revision emit only "1"; the version field is included in the signed payload so that the wire-version commitment is cryptographically anchored.¶

5.1. Comparison

5.2. Complementarity

RFC 9470 step-up and PSEA MAY be composed: the first to signal that a per-action authority check is required; the second to produce the cryptographically action-bound Evidence that satisfies that check.¶

1. An OAuth-protected resource server, acting as a Relying Party, receives a request whose access token does not satisfy the resource's per-action policy.¶
2. The resource server returns HTTP 401 with a WWW-Authenticate challenge per [RFC9470], indicating the required step-up.¶
3. The client drives the step-up flow on a device hosting a PSEA Attester. The Attester produces fresh Evidence at the capability level the resource's policy demands, cryptographically bound to the specific action that triggered the 401.¶
4. The client re-submits the request, conveying the Evidence to the Verifier. The Verifier appraises the Evidence and produces an Attestation Result. The resource server gates the action on both the OAuth access token (session validity) and the Attestation Result (per-action authority).¶

In this composition, OAuth supplies the session and identity context; PSEA supplies the per- action cryptographic authority proof. Neither mechanism replaces the other.¶

5.3. Out of Scope for This Document

This section identifies architectural complementarity. It does not define a normative integration profile between PSEA and [RFC9470]. A normative integration profile (specifying the precise WWW-Authenticate challenge syntax, the acr_values registration for PSEA capability/assurance levels, the error-mapping table between RFC 9470 challenges and PSEA error codes, and the conveyance of the Evidence in the re-submitted request) is deferred to a future document.¶

6.1. Scope and Method

This section enumerates the threats this document addresses, the assumptions on which the protocol's security properties rest, and the residual risks. The method is a STRIDE decomposition (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of privilege) applied to the protocol's wire surface; threats specific to a particular deployment's policy or non-protocol implementation choices are out of scope.¶

6.2. Attester Assumptions

The protocol's security properties depend on the following assumptions about a conforming Attester:¶

A1. Hardware-protected signing key

The Attester's signing key is generated in and never leaves a hardware-protected key store (for example a TEE, a Secure Enclave, a StrongBox, a smartcard secure chip, or a programmable secure element). The authenticator's attestation chain, verified by the Verifier against a trust anchor (Section 6.2), provides cryptographic evidence of this property.¶

A2. Contemporaneous user-verification gating

The Attester's signing key is gated by a platform user-verification ceremony such that signing cannot complete without a successful, contemporaneous user-verification event (see Section 3.7). The mechanism by which the platform implements this gating is out of scope; the Attester's assertion of the property is appraised through the platform attestation.¶

A3. Platform user-verification subsystem integrity

The Attester relies on the integrity of the platform user-verification subsystem (for example, a platform biometric subsystem, PIN entry into a Secure Enclave, hardware-token PIN handling, smartcard or magnetic-stripe-with-PIN reader logic). This is a platform guarantee; PSEA does not attempt to verify platform user-verification subsystem internals.¶

A4. Authenticator attestation as a trust anchor

The Verifier holds the authenticator's attestation root (for example an Android Key Attestation root, an Apple App Attest root, a hardware-token vendor root, or a smartcard issuer root) as a trust anchor. The Verifier's appraisal of attestation chains is bounded by the authenticator's published chain-validation rules.¶

6.3. Enrollment Is the Root of Trust

Every security property in this document is conditional on one out-of-scope step: the enrollment ceremony that binds an enrolled signing key (selected at verification time by kid) to the correct device and the correct subject. This is stated as an out-of-scope assumption in O3 (Section 6.7), but its consequence is foundational and is called out here explicitly so it is not understated: if enrollment binds the wrong key, the entire chain of guarantees is anchored to the wrong hardware, and every downstream check in this profile still passes.¶

Concretely, an adversary who can complete the deployment's enrollment ceremony with hardware the adversary controls — enrolling the adversary's own hardware-protected key as if it were the victim's device — thereafter produces proofs that are valid in every respect this profile can check: the signature verifies against the enrolled key, the attestation chain is genuine (it attests the adversary's real hardware), the user-verification gate fires (on the adversary), the action binding holds, and the counter and jti checks pass. The Verifier has no in-protocol signal that the enrolled key belongs to the wrong person, and the substitution persists for the lifetime of the enrollment. The forged-binding cannot be detected by the wire protocol; it can be detected only by the strength of the enrollment ceremony and by out-of-band identity proofing.¶

Deployments therefore MUST treat enrollment as the security-critical root of the whole system and apply identity-proofing, attestation freshness, and binding controls commensurate with the authority the resulting proofs will carry. No property claimed elsewhere in this document is stronger than the enrollment binding it rests on.¶

6.4. STRIDE Threats Addressed

6.5. Verifier State Integrity: Sharding and Rollback

The replay defenses of Section 3.10 — the strictly-increasing psea_counter compared-and-advanced atomically per (Attester, counter scope), and the global jti uniqueness check that finalizes each action identifier exactly once — are stated as logical, single-domain guarantees. A horizontally-scaled (sharded) Verifier deployment and the durability of the Verifier's state both bear on whether those guarantees actually hold, and neither is closed by the wire format alone.¶

Sharding / distributed serialization. The atomic compare-and-advance of Section 3.10 assumes a single transactional domain per (Attester, counter scope), and the jti uniqueness check assumes a globally consistent index. A deployment that spreads verification across multiple nodes MUST preserve these assumptions: all submissions for a given (Attester, counter scope) MUST be serialized to a single authority (for example by routing or partitioning on the Attester identity, or by a shared transactional store that serializes per scope), and the jti finalization index MUST be globally consistent across all nodes that can accept proofs for the deployment. A design in which two nodes can independently advance the same scope's counter, or independently finalize the same jti, without a serializing authority is non-conformant: it reopens the concurrent-double-accept and counter-regression surfaces that the atomicity requirement of Section 3.10 exists to close, this time at the storage tier rather than at the single-node transaction.¶

Rollback / durability. Section 3.10 prevents an Attester from regressing its counter; the symmetric risk is the Verifier regressing its own stored high-water mark and jti set. If the Verifier's counter / jti state is restored from an older backup or otherwise rolled back, counter values and jti values consumed since that backup become acceptable again, reopening the replay surface for proofs still within their exp window. A conforming Verifier MUST protect its replay state (the per-scope high-water-mark counters and the finalized-jti set) against rollback, such that a restore or failover does not lower a stored high-water mark or forget a finalized jti that could still be replayed within the exp window. This is the server-side mirror of the client-side regression the counter model forbids; durability of the replay state is part of the replay defense, not an operational afterthought.¶

6.6. Future Work: Relying Party Counter-Signature

The current protocol provides cryptographic action-binding between the Attester and the Verifier. A future extension MAY introduce a Relying-Party counter-signature primitive in which the Relying Party countersigns the Attestation Result, producing a three-party signed artifact that binds the action approval to (a) the Subject (via the Attester's hardware key + user- verification), (b) the Verifier's appraisal, and (c) the Relying Party's policy acceptance.¶

This three-party binding would close the residual risk that a compromised Relying Party accepts an Attestation Result it should have rejected on policy grounds. The wire-level primitive is informative-only at this revision; a normative specification is deferred to a future document.¶

6.7. Threats Out of Scope

The following threats are acknowledged but are out of scope of the wire protocol:¶

O1. Platform user-verification subsystem compromise

Compromise of the platform user-verification subsystem (biometric subsystem, Secure Enclave, hardware-token reader, smartcard reader, or equivalent). Bounded by platform vendor guarantees; PSEA appraises the resulting attestation but does not verify platform internals.¶

O2. Insider threat at the Verifier or Relying Party

An insider with administrative access to the Verifier or Relying Party can subvert appraisal regardless of the wire protocol. Deployments SHOULD apply standard operational controls (separation of duties, audit logging, key custodianship).¶

O3. Pre-enrollment trust establishment

The protocol assumes that an enrollment ceremony validly binds an Attester to a subject identity. Deployment-specific enrollment policies are out of scope. This is the root-of-trust assumption for the entire profile and its consequence (a forged enrollment binding yields fully-valid proofs anchored to the wrong hardware) is treated explicitly in Section 6.3.¶

6.8. Known Open Problems

The following are attack surfaces that PSEA does not solve and that remain unsolved at the authenticator/platform layer at the time of writing. They are documented so that deployers and reviewers can assess residual risk in their own deployment context, and each is a candidate for future research and protocol evolution.¶

7.1. UEID Linkability

The ueid claim (Section 3.2) is, within one deployment, a stable per-device identifier: it is the same value across every action a given device attests to a given issuer (iss). A Verifier therefore can, and by construction does, link all of a given device's proofs to one another within its deployment. This intra-deployment linkability is an inherent property of a device-bound attestation identifier, not a defect; this profile depends on the Verifier being able to bind successive proofs to one enrollment.¶

To prevent the same physical device from being correlated across deployments, the ueid MUST be derived pairwise per issuer: the UEID byte string is 0x01 || SHA-256(JCS({"deviceId": <deviceId>, "iss": <iss>})) (Section 3.2), where JCS() denotes the JSON Canonicalization Scheme ([RFC8785]) form of that two-member JSON object, taken under the canonical-encoding rules of Section 2, so the same device yields a different ueid for each distinct iss. The two inputs are encoded as a canonical JSON object rather than concatenated because a bare concatenation of two variable-length strings is ambiguous: the pairs ("acme", "corp.example") and ("acmecorp", ".example") concatenate to identical octets and would derive one ueid for two distinct deployments, defeating the very separation the pairwise derivation exists to provide. Because iss is itself a signed claim bound into the proof, the derivation is verifiable: a Verifier recomputes the expected ueid for its own iss from the enrolled device-id input. The privacy rationale is that a single, globally-shared device identifier would let independent Relying Parties and deployments correlate one person's device activity across unrelated services; binding the identifier to iss confines linkability to the single deployment that legitimately requires it.¶

This profile carries a deterministic per-issuer value under the RFC 9711 RAND type tag (0x01). [RFC9711], Section 4.2.1.1 requires that a UEID be permanent and not change for a given entity. The value this profile carries does not meet that requirement: it is derived from a deviceId input that is wiped on factory reset and re-derived afterwards, as happens both to a platform-provided device identifier and to an identifier generated and stored on the device, so the same entity presents a new value after a factory reset. [RFC9711], Section 4.2.2 defines the semipermanent UEID (sueids) claim for this case: a value with the format of a UEID that may change on entity life-cycle events, of which factory reset is one. sueids is the correct claim for the value this profile carries. This revision retains ueid for wire continuity only.¶

The sueids claim is a map, not an array: each entry pairs a text-string label with a value in the UEID format, and a label is required even when only one entry is present ([RFC9711], Section 4.2.2). This profile defines no means for a device owner to add an identifier: the Attester emits exactly one device identifier, derived from its deviceId input and the signed iss.¶

Migrating the identifier to sueids is a wire-incompatible change. It is the stated intent for the next wire-incompatible revision of this profile, which will also define the label. Until then the ueid value is a per-issuer pseudonym for the current enrollment: deterministic by construction, not random, and not preserved across factory reset.¶

Per-issuer derivation does not provide per-Relying-Party unlinkability within a single deployment, nor does it defeat correlation by other shared fields. A future revision MAY define a pairwise / sueids-style per-Relying-Party identifier derivation (in the spirit of the EAT semipermanent-UEID concept, [RFC9711]) so that one device presents a distinct, unlinkable identifier to each Relying Party within a deployment; this is the path to per-RP unlinkability and is RECOMMENDED as the direction for deployments with strong unlinkability requirements.¶

The same "hashing is not anonymization" caution that applies to psea_user_hash (Section 7.2) applies to the deviceId input of the ueid derivation. If deviceId is a low-entropy or enumerable value (for example a hardware serial number or other guessable platform identifier), then the derived ueid is recoverable by brute force from a known iss, defeating the confinement the per-issuer derivation is meant to provide; encoding the inputs unambiguously prevents one derived ueid from standing for two input pairs, and does not raise the entropy of either input. A deployment SHOULD use a high-entropy, per-enrollment random value as deviceId (a value generated at enrollment and not derived from a stable hardware identifier), so that the derived ueid is not recoverable from guessable inputs and is not a globally stable value computable by any other party.¶

7.2. Hashing Is Not Anonymization

PSEA wire fields carry SHA-256 hashes of identifiers (the device-id hash inside ueid, and the OPTIONAL psea_user_hash subject hash) rather than the identifiers themselves. Hashing reduces casual exposure of the raw value, but it MUST NOT be relied upon as a privacy or anonymization guarantee. An unsalted hash of a low-entropy identifier — a phone number, an account number, an email address, a national ID, or any identifier drawn from a small or enumerable space — is reversible by brute-force or dictionary attack: an adversary who can compute the same hash function over candidate inputs recovers the input, and two systems that hash the same identifier produce the same digest, making the hash a stable, globally linkable identifier in its own right.¶

Where linkability or re-identification of the hashed identifier matters, a deployment SHOULD either (a) salt or pepper the hash input with a per-deployment secret that is not published with the proofs, so the digest is not a globally stable value computable by any other party, or (b) derive a pairwise identifier per Relying Party (see Section 7.1), so the hashed value is not a single stable identifier shared across contexts. A deployment MUST NOT treat a bare SHA-256 of a user or device identifier as sufficient to claim the wire field is non-identifying. The minimization PSEA does provide is that the raw identifier and the biometric template never transit the wire (Section 6.4.4); that is a reduction in exposure, not anonymization.¶

7.3. Data Minimization at the Verifier

The Verifier and Relying Party necessarily retain proof records to serve PSEA's audit-trail purpose, and those records are linkable per Section 7.1. Deployments SHOULD apply retention limits, access controls, and purpose limitation to stored proofs and Attestation Results consistent with their regulatory environment, and SHOULD NOT retain the OPTIONAL psea_user_hash beyond the audit-trail need it serves. Correlation of proofs with out-of-band identity (which natural person a ueid or psea_user_hash corresponds to) is established only at enrollment and is a deployment responsibility outside the wire protocol.¶

8.1. Summary of Requested Registrations

This document requests IANA to register one media type:¶

• One media-type registration (Section 8.2).¶

This document requests no URN sub-namespace and no registration of any kind for its eat_profile identifier. The eat_profile claim carries a URI or an OID and [RFC9711] defines no registry for profile identifiers, so the identifier this profile uses — the HTTPS URI https://datatracker.ietf.org/doc/draft-yossif-psea/ (Section 3.1) — requires no registration action and does not depend on the stream this document is published on.¶

This document does not request registration of the psea_* claims in the JSON Web Token Claims registry ([RFC7519], Section 10.1) or in the CBOR Web Token (CWT) Claims registry. The psea_* claims are profile-private extension claims whose semantics are meaningful only to a consumer that understands this eat_profile (Section 3.1); their names are scoped by the eat_profile claim rather than by a global registry, consistent with the strict, profile-scoped extensibility model of this document (Section 3.1.1). A future revision MAY register one or more psea_* claims in the JWT Claims registry should cross-profile reuse warrant a globally-managed name; this revision intentionally does not, to avoid reserving global names for semantics that are defined only relative to this profile.¶

8.2. Media Type Registration

This document requests registration of the media type application/psea+jwt in the "Media Types" registry, following the procedures of [RFC6838] and using the registered +jwt structured syntax suffix ([RFC7519]). The subtype carries the PSEA proof defined by this profile (protected-header typ = "psea-proof+jwt") per Section 3. The media type application/psea+jwt labels the object at the transport layer, and a consumer expecting a proof MUST verify the protected-header typ value (Section 3.4). The Verifier acknowledgement / Attestation Result is out of scope of this profile (Section 3.13.3); a deployment that represents that artifact as a JWS MAY reuse this media type with a distinct protected-header typ value (for example "psea-ack+jwt"), applying the explicit-typing guidance of [RFC8725], Section 3.11 so the two object types are not confused, but this document does not define that artifact.¶

Type name

application¶

Subtype name

psea+jwt¶

Required parameters

N/A¶

Optional parameters

N/A¶

Encoding considerations

8bit; a PSEA token is a JWS Compact Serialization ([RFC7515]): a series of base64url-encoded values separated by period (".") characters.¶

Security considerations

See Section 6 of this document and the Security Considerations of [RFC7515] and [RFC7519]. In particular, a consumer MUST apply the JOSE header hardening of Section 3.4 (ES256 only; reject alg:"none"; ignore jwk/jku/x5u; verify typ; reject unknown crit parameters and the unencoded-payload option).¶

Interoperability considerations

See Section 3 and Section 2.¶

Published specification

This document.¶

Applications that use this media type

PSEA Attesters, Verifiers, and Relying Parties exchanging action-bound, user-verification-gated execution-authority Evidence and the corresponding Attestation Results.¶

Fragment identifier considerations

N/A¶

Additional information

Deprecated alias names for this type: N/A; Magic number(s): N/A; File extension(s): N/A; Macintosh file type code(s): N/A.¶

Person & email address to contact for further information

Mohamad Khalil Yossif <mohamad@yuthent.com>¶

Intended usage

COMMON¶

Restrictions on usage

None¶

Author

Mohamad Khalil Yossif¶

Change controller

IETF¶

A CWT/COSE representation ([RFC9052]) carrying the same EAT ([RFC9711]) and psea_* claim set is future work; this revision does not register a +cose media type.¶

9.1. Cryptographic Algorithms

9.2. Operational Defaults

The following operational defaults are RECOMMENDED for conforming deployments:¶

Nonce TTL

Deployment-defined; RECOMMENDED 60-300 seconds.¶

Maximum proof lifetime (exp - iat)

Deployment-defined (Section 3.11); RECOMMENDED 300 seconds for synchronously-submitted proofs, extended only as far as a deployment's offline-to-sync interval requires for proofs produced offline.¶

Clock-skew tolerance

Deployment-defined; SHOULD NOT exceed 60 seconds (Section 3.11).¶

Operational grace window after enrollment

Deployment-defined; RECOMMENDED 24 hours during which the Verifier accepts proofs from a freshly-enrolled Attester before requiring strict policy enforcement.¶

Counter range

The counter is a JSON integer in [0, 2⁵³ − 1] (Section 3.10); exhaustion is not a practical concern at any reasonable operational rate.¶

A.1. Case-Sensitive Key Sort

Input object (logical):¶

{ "endReason": "TtlExpired",
  "endedAt":   1700000060,
  "sessionId": "abc-123",
  "startedAt": 1700000000 }

Canonical bytes (the keys ordered by UTF-16 code-unit sort: 'R' = U+0052 = 82 sorts before 'e' = U+0065 = 101, so "endReason" precedes "endedAt"), shown with one line break added for display only; the canonical form contains no line break:¶

{"endReason":"TtlExpired","endedAt":1700000060,
"sessionId":"abc-123","startedAt":1700000000}

A.2. Integer Serialization

The integer 0 is serialized as the single character 0; the integer 42 as 42; the integer 1700000000000 as 1700000000000; no leading zeros, no decimal point, no exponent.¶

A.3. Action-Payload Hash (End-to-End Worked Example)

This vector demonstrates the first of the two normative uses of canonical encoding (Section 2): the action-payload binding. Given the logical actionPayload:¶

{ "amount": 2500, "actionType": "transfer",
  "to": "alice", "currency": "EUR" }

the canonical encoding orders the keys by UTF-16 code-unit sort (actionType < amount < currency < to), removes all inter-token whitespace, and serializes the integer with no decimal point or exponent, yielding the 69 canonical octets:¶

{"actionType":"transfer","amount":2500,"currency":"EUR","to":"alice"}

SHA-256 of those octets is, in lowercase hex:¶

f0f8eb390ecdb3b312765cfe3a888c39ad4571bb94ddfc553230a4b85171e942

The psea_payload_hash claim is that digest in standard base64 with padding (Section 3.2):¶

8PjrOQ7Ns7MSdlz+OoiMOa1FcbuU3fxVMjCkuFFx6UI=

A Verifier re-canonicalizes the received actionPayload, recomputes this digest, and compares it byte-for-byte against the signed psea_payload_hash (Section 3.13.2). The same 32-byte digest encoded as base64url without padding — the encoding used by ueid and psea_user_hash, not by psea_payload_hash — is 8PjrOQ7Ns7MSdlz-OoiMOa1FcbuU3fxVMjCkuFFx6UI; the difference (+ versus -, trailing = versus none) illustrates why the per-claim encoding split of Section 3.2 must be observed exactly.¶

B.1. Conformance Roles

This document defines conformance for three roles: Attester, Verifier, Relying Party.¶

B.2. Attester Conformance

B.3. Verifier Conformance

B.4. Relying Party Conformance

A conforming Relying Party:¶

• MUST gate the action on the Verifier's Attestation Result.¶
• MUST verify the integrity of the Attestation Result for non-co-located Verifiers.¶