Zero Trust Attribute Assertion Tokens

Many services require verification of user attributes rather than identity. Existing mechanisms frequently disclose unnecessary information and enable cross-service tracking. This document specifies a zero-trust attribute assertion system in which: A relying party requests a single boolean claim. An issuer evaluates that claim. The issuer produces a signed assertion token. The subject presents the token to the relying party. The relying party verifies the token without contacting the issuer. The subject is untrusted. All claim validity derives solely from the issuer's signature.

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 when, and only when, they appear in all capitals. An individual presenting an assertion token. An authority capable of evaluating and asserting claims. An entity requesting verification of claims. A boolean predicate defined by the issuer. A cryptographically signed structure containing one claim result.

Token issuance and token presentation are distinct phases. During issuance, the issuer MAY verify subject identity using authoritative records. The issuer MAY learn that a token is being requested but MUST NOT learn the intended relying party. During presentation, the relying party MAY learn that a subject is requesting access to a resource but MUST NOT learn the subject's identity from the token. The issuer MUST NOT observe token presentation.

The following invariants are REQUIRED: Assertion tokens MUST NOT contain identifiers, pseudonyms, or stable entropy. Tokens intended for different relying parties MUST be unlinkable. The issuer MUST NOT learn the intended relying party. Tokens MUST reveal only the requested claim. Tokens MUST NOT enable cross-service tracking.

Claims MUST be defined in an issuer-controlled registry. Claims: MUST be boolean MUST be coarse-grained MUST NOT encode identifying information Example claims include: is_over_18 is_us_citizen is_us_resident

Each AssertionToken MUST encode exactly one claim result. A relying party requiring multiple claims MUST obtain and verify separate tokens for each claim. Relying parties MUST NOT request arbitrary claims outside the registry.

The requested boolean claim. The asserted truth value. Expiration time. An opaque value bound to a single relying party. The value MUST be meaningful only to the relying party and MUST NOT reveal relying party identity to the issuer. Identifier of the issuer. Digital signature over all fields. Requirements: Tokens MUST be audience-bound. Tokens MUST be unmodifiable. Tokens MUST NOT contain identifiers. The expiration time MUST be no more than 10 minutes after issuance.

be meaningful only to the relying party not reveal relying party identity to the issuer not be derivable by the issuer

The issuer evaluates the requested claim and produces a signed assertion token. The issuance process MUST prevent the issuer from learning the intended relying party. The issuer MAY learn that a request occurred but MUST NOT learn the audience value.

The subject provides the AssertionToken to the relying party.

The relying party MUST: Verify the token signature using issuer verification material. Verify expiration. Verify that the audience value matches a relying-party-local value. Apply relying-party replay policy. Evaluate the claim. Verification MUST NOT require real-time issuer interaction.

Relying parties MUST maintain a local trust configuration of accepted issuers. Trust MUST be scoped per issuer and per claim. An issuer MUST NOT assert claims outside its authoritative domain.

Tokens MUST expire within 10 minutes of issuance. Tokens MUST NOT be renewable.

Assertion tokens MUST be digitally signed by the issuer. A relying party MUST verify the issuer signature using trusted verification material. Issuers MUST make verification material available through a trusted distribution mechanism. This specification does not mandate specific cryptographic algorithms or key formats.

The primary threat is unauthorized claim assertion. This protocol mitigates: forgery through signature verification tampering through integrity checks cross-relying-party misuse through audience binding Replay is handled by relying-party policy.

The subject is untrusted. The issuer is trusted only for correctness of claim evaluation. The relying party trusts only issuer signatures and local policy. The protocol guarantees claim authenticity and integrity, but does not guarantee identity or subject uniqueness.

This document has no IANA actions.