Security and privacy

Security contract

A valid TSAI presentation establishes a limited set of properties. The service provider can confirm that an accepted trust authority signed the credential, that the presenter controls the current private key bound through cnf, and that the credential identifies a persistent agent and accountable operator. It can also confirm that the presentation is recent and addressed to that service provider.

Established properties

The credential and disclosed claims have not changed since the trust authority signed them.
The presenter controls the private key corresponding to the public key in cnf.
The presentation is at most 90 seconds old and no more than 30 seconds ahead of the verifier's clock. A service provider may apply a tighter bound.
For a state-changing action, the presentation includes a single-use challenge and a req claim that binds it to the intended HTTP request.

Properties outside verification

Verification does not prove that every issued claim is true or suitable for the service provider's decision.
Verification does not authorise the request or establish the user's authority.
Verification does not show that the agent is uncompromised, that its behaviour is acceptable, or that its output is correct.
Verification does not predict how the agent or operator will behave after the interaction.

The service provider therefore applies its own trust and authorisation policy after verification. It also retains normal controls for request validation, output handling, rate limiting, behavioural monitoring, and consequential operations.

Trust assumptions and boundaries

The security contract holds only while several participants and infrastructure components meet their responsibilities. TSAI reduces the trust placed in a credential holder and the network, but it does not remove trust from the system.

A trust authority protects its signing keys, applies its declared evaluation methods, issues only the claims it established, and keeps its status material current.
An operator protects agent binding keys and management credentials, controls registration and rotation, and repudiates a key after suspected compromise.
A service provider selects accepted trust authorities, verifies every presentation, and applies the resulting evidence only within its own policy.
HTTPS, DNS, certificate authorities, cryptographic libraries, secure random generation, and system clocks operate within their stated security properties.
Components inside a service provider authenticate verification context when one component verifies a presentation and another executes the request.

The threat model considers an external attacker, a compromised agent, a malicious operator, a compromised trust authority, an intermediary that can alter internal request handling, and a compromised service-provider component. Protected assets include private keys, credentials, verification material, request integrity, policy decisions, status data, and security logs.

Correct time is an operational dependency. A service provider should monitor clock drift and return its current time with a stale-presentation rejection so the agent can correct its clock.

TSAI v1 fixes ES256 signatures, P-256 keys, and SHA-256 protocol digests. This fixed algorithm set removes negotiation and its downgrade paths, while a future algorithm change requires an explicit protocol-version transition.

Threats across the credential lifecycle

The controls below follow the credential from issuance and storage through presentation, verification, and policy use. Each control limits a specific attack, while the remaining exposure determines what the deployment must do next.

Issuance and evidence integrity

A verifier accepts credentials only from configured trust authority identifiers. It obtains issuer metadata from the standard HTTPS location defined by SD-JWT VC, selects the P-256 signing key from its embedded or referenced JWK Set, confirms that the returned issuer matches iss, rejects alternate key-discovery mechanisms, and verifies the ES256 signature.

Signature validity establishes attribution, but it does not define what a signal means. The credential therefore integrity-pins immutable Type Metadata and a JSON Schema, while a derived type must prove its chain to the canonical TSAI type. These checks prevent an attacker from changing field semantics or disclosure rules while retaining a familiar credential type.

The persistent agent identity is anchored to a verified domain-control signal, dct. The trust authority verifies domain control no more than 12 hours before issuance. Failed revalidation stops new issuance, while confirmed loss of control blocks every registered agent anchored to that domain. Domain takeover can therefore become agent-identity takeover until revalidation or incident response intervenes.

A compromised trust authority can still issue false claims under its own identity. Cryptography cannot make an accepted authority truthful. A service provider limits this risk through explicit issuer selection, review of evaluation practices and operational reports, and removal of an authority from its trusted set after material failure.

Trust authority infrastructure

A trust authority holds signing keys in an HSM and protects its registration index against unauthorised change and rollback. Registration changes require an authenticated and authorised management action and leave a tamper-evident audit record. An active binding-key identifier maps to one agent across the trust authority, and registration enforces that uniqueness atomically.

Domain-control challenges use at least 256 bits of entropy and remain single-use, short-lived, and bound to the operator account, agent identity, domain, and validation method. A proof-of-key-control challenge is also single-use, expires within five minutes, and receives a non-cacheable response. The trust authority APIs require TLS 1.3.

Signed operational reports and HSM attestations let service providers review key custody, availability, and evaluation operation without relying on an unsigned assertion. These publications do not remove trust in the authority, but they make its practices inspectable and support removal after an operational failure.

Credential and key custody

Credentials can escape through process memory, storage, proxies, backups, and application logs. TSAI binds each credential to the public key in cnf, and every presentation carries a key-binding JWT signed by the corresponding private key. A copied issuer-signed credential therefore cannot produce a valid presentation without that key.

The TSAI-Credential value must not appear in a URL or log, and proxies must not cache a request that carries it. HTTPS protects transmission, but these controls limit secondary exposure inside the operator and service-provider environments.

An attacker holding both the credential and private key can present until the credential expires or a service provider observes a block. The 30-minute credential lifetime limits this exposure, while authenticated key repudiation lets the operator stop future issuance and trigger an agent block. Distinct binding keys reduce compromise scope, although they do not conceal the persistent agent identity.

An agent host that also holds an operator management session creates a larger risk. An attacker can request challenges, issuance, and refresh until that session is revoked. Operators should keep management credentials outside the agent runtime where practical, while trust authorities should scope sessions to the required agent and operations, limit their lifetime, and support immediate revocation.

Presentation replay and request substitution

The key-binding JWT contains aud, so a presentation captured at one service provider cannot be replayed to another. Its iat must remain within the fixed freshness bound: no more than 90 seconds old and no more than 30 seconds ahead of the verifier's clock.

The common offline path keeps no per-request state. A captured presentation for an idempotent read can therefore be replayed to the same service provider during that window. The service provider accepts or rejects this exposure according to the action and its policy.

A state-changing action requires a service-provider-issued single-use nonce and the req claim. The service provider atomically consumes the nonce, while req binds the method and absolute target URI by exact string equality and, where a body exists, its SHA-256 HTTP content digest defined by RFC 9530. The nonce prevents reuse, whereas the request digest prevents an intermediary from attaching the presentation to another action.

The same binding must survive an internal hand-off. When an edge component verifies and an origin acts, the origin authenticates the verification context and confirms that the bound request is the request it will execute.

Status and blocking

Status checking is an online, policy-driven step. When policy requires it, the service provider first confirms that the status URI shares the origin of iss. It then:

requires token type statuslist+jwt and algorithm ES256 and verifies the signature;
confirms that token sub exactly equals the credential's status_list.uri and that the issuers match;
rejects a token older than its configured bound and rejects a set status entry as blocked.

If the status list is unreachable, the service provider applies its bounded degraded-mode policy rather than silently treating the credential as unblocked.

Verification dependencies

Issuer metadata and referenced JWK Sets, status lists, credential type definitions, optional rendering resources, and referenced third-party identifiers create both integrity and server-side request-forgery risks. A verifier must not treat an HTTPS URL as sufficient permission to fetch.

Every protocol-directed fetch uses HTTPS, validates the destination after DNS resolution, refuses internal and non-global addresses, and limits response size and duration. It also requires the expected media type and a valid document before use. TSAI does not follow redirects; a redirecting endpoint causes the fetch to fail. DNSSEC-validated resolution is required when a service provider resolves a third-party did:web, a web-hosted decentralised identifier, on which it relies for a material decision.

Type Metadata, schemas, and reputation methodologies are obtained outside the request path and checked against their integrity values. This prevents an agent request from directing an arbitrary metadata fetch and keeps the common verification path offline.

If issuer metadata becomes unavailable, a service provider can continue with a previously validated key for a configured and bounded period. Degraded operation remains visible in protected logs and policy context, and it does not relax cryptographic checks, credential lifetime, the identity floor, holder proof, audience, freshness, or request binding. Verification fails closed when the period ends.

A cached verification result cannot outlive the credential's exp. Its cache key includes the presented credential, so a new presentation is verified rather than assumed. Where the service provider checks status, it does not serve a cached positive result across a status change it could have observed.

Public verification errors use stable, generic codes without issuer identifiers, algorithm details, or key-discovery information. Protected operational logs receive the diagnostic detail. STALE_PRESENTATION remains distinct from BINDING_INVALID because clock drift produces the former without invalidating the signature or binding claims.

Policy and subsequent behaviour

A fresh credential can contain older evidence. Service-provider policy must inspect a signal's asof, scope, provider, and methodology rather than treating credential issuance time as the age of every assertion.

The prv field attributes a compliance or assurance claim to a third party, but it is not an independent signature from that party. A service provider verifies the attributed provider outside TSAI before relying on the signal for a material decision.

When accepted credentials disagree about the same signal and operator, the service provider applies an explicit conflict policy. Without such a policy, it treats the signal as unresolved and does not silently prefer one credential.

An agent can be compromised after presenting valid evidence, and an operator can register a new agent to leave poor agent-level history behind. Operator-level reputation preserves continuity at the operator scope but does not provide end-user uniqueness. In a multi-agent chain, TSAI describes the immediately connecting agent rather than the original user or every upstream agent.

Privacy and correlation

TSAI excludes user identity because a service provider does not need routine cross-service disclosure of that identity to evaluate an agent request. Carrying it would create additional surveillance and legal obligations without improving agent or operator accountability. A service provider can continue to identify and authorise a user through its existing account and consent systems where the interaction requires them.

Agent accountability has a different privacy balance. Every credential contains the persistent HTTPS sub and the operator identity floor, so a service provider can recognise an agent across key rotation. Service providers that compare records can also correlate the same agent across interactions. This correlation supports stable policy, reputation continuity, and blocking, but it prevents pairwise agent unlinkability.

Rotating cnf keys reduces key-based linkage and compromise scope but does not conceal sub. A status reference adds another stable handle through its URI and index. Omitting status removes that handle, but the trust authority cannot then invalidate the current credential before its 30-minute expiry. A service provider can still apply its own local block by sub.

Selective disclosure limits optional information, but it does not remove the accountability properties. The persistent agent identity, operator identity floor, and reputation remain non-disclosable. Participants should therefore limit status records, signal retention, and cross-service sharing to what their security and legal duties require, while credential contents remain excluded from logs.

Actor responsibilities

The protocol distributes security responsibilities because no participant can enforce the complete model alone.

Concern	Operator	Trust authority	Service provider
Evidence quality	The operator supplies authentic evidence and maintains accurate agent registration.	The trust authority applies its declared evaluation methods and issues only established claims.	The service provider decides which authorities, signal types, scopes, and methodologies its policy accepts.
Domain and key custody	The operator retains domain control, protects binding and management keys, rotates them, and repudiates suspected compromise.	The trust authority revalidates domains, protects signing keys in an HSM, and restricts registration and issuance access.	The service provider verifies holder proof and removes compromised authorities or keys from its trusted material.
Replay and substitution	The operator's agent creates a fresh, correctly bound presentation.	The trust authority issues the credential with the required binding information.	The service provider enforces freshness, issues and consumes nonces, compares `req`, and preserves binding across internal hand-offs.
Verification material	The operator obtains credentials before interacting with a service provider.	The trust authority publishes authentic keys, Type Metadata, schemas, status material, and signed operational reports.	The service provider validates, integrity-checks, caches, and refreshes the material within bounded policy.
Blocking and response	The operator reports key, session, or domain compromise and stops affected agent processes.	The trust authority stops issuance, records repudiation, updates status material, and rotates compromised signing keys.	The service provider applies status and local blocks and removes a compromised authority from its trusted set.
Authorisation and behaviour	The operator controls what the agent is instructed and permitted to do.	The trust authority does not authorise an agent request by issuing a TSAI credential.	The service provider authorises the action and monitors requests, outputs, and subsequent behaviour.
Privacy and records	The operator limits optional disclosure and protects stored credentials.	The trust authority limits retained issuance data and avoids request-time observation on the offline path.	The service provider excludes credential contents from logs and limits retention, correlation, and sharing.

Compromise response

Compromise	Immediate response	Remaining exposure
Agent binding key	The operator repudiates the key. The trust authority refuses further issuance and blocks the persistent agent identity where issued credentials may be affected.	An attacker can present an existing credential until it expires or a service provider observes the block.
Operator management session	The operator revokes the session, while the trust authority stops management and lifecycle operations authorised through it.	An attacker can request challenges, issuance, and refresh until revocation takes effect.
Operator domain	The trust authority stops issuance after failed revalidation and blocks every anchored agent after confirmed loss of control.	Existing credentials remain usable until expiry or an observed block, while the domain remains accepted as the identity anchor until the loss is detected.
Trust authority signing key	The trust authority rotates through its out-of-band path, notifies service providers and governance, and reissues affected material. Service providers can remove the authority from their trusted set.	Credentials signed with the compromised key remain suspect regardless of their apparent validity.

Residual risks and review questions

TSAI does not inspect model execution, prevent prompt injection, detect fabricated output, or secure the service provider's application. A valid operator can direct an agent maliciously, and valid evidence can become inaccurate after issuance. The protocol supplies attributable evidence to existing security and authorisation systems and does not replace them.

A service provider can introduce TSAI through one of three postures: log-only, annotate, or enforce. The posture controls the access decision after an absent or failed presentation; it never permits a failed verification to be represented as verified.

Implementation review

The accepted trust-authority set has explicit ownership, review criteria, and a removal process.
Trust-authority operations protect challenges, registration changes, key uniqueness, signing keys, and transparency publications.
Signing keys for agents, operator management, and the trust authority receive protection appropriate to their different consequences.
Domain control is revalidated within the required window, and loss of control stops issuance and triggers blocking.
The TSAI-Credential header never appears in a URL or log, and proxies do not cache requests carrying it.
Presentation freshness enforces the 90-second age bound and the 30-second forward-skew bound, and the service provider monitors clock drift.
The application rejects verification results that are not bound to the request it will execute.
State-changing actions use a single-use nonce, atomic consumption, and the required req comparison.
Status-list tokens receive type, algorithm, signature, subject, issuer, age, origin, and status-entry checks.
Protocol-directed fetches refuse redirects and internal or non-global destinations, bound response size and time, validate media type and document format, and control DNS changes and stale material.
Degraded operation has a fixed duration, retains the identity floor and all cryptographic and binding checks, and fails closed when its limit expires.
Cached verification results remain bound to the presented credential, expire with it, and do not survive an observable status change.
Policy evaluates signal age, scope, provider, methodology, attribution, and credential conflicts, not credential validity alone.
Public errors omit verification internals while protected logs contain enough detail for diagnosis.
Application controls — authorisation, input validation, rate limiting, output handling, and behavioural monitoring — operate independently of TSAI verification.

The Protocol page explains the credential and verification model, while the Implementation page provides role-specific starting paths and detailed trust-authority controls.