]> Attenu

rafael.asor@gmail.com https://attenu.io/

Security WIMSE agent delegation attenuation authorization capability AI agents increasingly delegate tasks to other agents. Each delegation should convey only a subset of the delegating party's authority, that subset should be bounded in scope, magnitude, and time, and any enforcement point should be able to verify -- offline, with no call to an authorization server -- that a token presented at hop N carries authority no greater than the token at hop N-1, back to a trusted root. OAuth 2.0 Token Exchange (RFC 8693) models two-party delegation and records prior actors in a nested "act" claim, but that claim is informational only and cannot enforce attenuation across a chain of depth two or more. This document defines the Agent Delegation Chain: a profile of OAuth 2.0 JWT access tokens (RFC 9068) that carries authority as Rich Authorization Requests (RFC 9396), links each delegation to its parent by a cryptographic byte-commitment, and specifies a deterministic offline verification algorithm that enforces monotonic attenuation, bounded depth, and monotonic expiry. It reuses existing JOSE, proof-of-possession (RFC 9449), and status-list machinery (the OAuth Status List draft) and introduces no new cryptography.

Introduction An AI agent that receives a task from a user or another agent frequently decomposes it and delegates sub-tasks to further agents or tools. In production deployments this produces delegation chains of depth greater than two. The security requirement is a single invariant: the authority exercised at any hop MUST be a subset of the authority granted at the hop that delegated to it, and this MUST be verifiable by the enforcement point that ultimately honors a tool call, without that point contacting an authorization server.

The gap in existing mechanisms OAuth 2.0 Token Exchange defines delegation and impersonation semantics and a nestable "act" claim. However, Section 4.1 states that a recipient considers only the top-level claims and the current (outermost) actor; the nested chain is history for audit, not enforced authority. Token Exchange also normally contacts the authorization server at each hop. Neither property supports offline, enforced, depth >= 2 attenuation. Cross-domain identity chaining (see ) and transaction tokens address related but distinct problems (crossing trust domains and propagating immutable context within one domain, respectively) and explicitly do not provide chained cryptographic attenuation. Capability systems that do provide offline attenuation -- macaroons , Biscuit -- either verify with a shared secret (macaroons: symmetric HMAC, so every verifier holds the minting key) or use a non-IETF wire format (Biscuit: protocol buffers with an embedded Datalog engine). The historical standards-track ancestor is SDSI/SPKI . This document fills the gap by reusing the JOSE/OAuth stack and adding only the chain linkage and the subsumption-enforcing verification algorithm. It is designed as the attenuation mechanism satisfying requirement R1 of and as a companion to . It shares its approach with, and is intended to converge with, and . Its offline verification model is complementary to the online Delegation Server and synchronous revocation model in . The two are halves of one design, separated by a single axis: whether a server is in the path. The in-token mechanisms this document requires -- constraints carried in the token, parent-hash verification, and a child expiry bounded by its parent's -- are how a verifier with no network reconstructs what such a server would otherwise know first-hand; where a server is in every hop, they are redundant rather than absent.

Conventions and Definitions 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, as shown here.

Delegation Token (DT):

An OAuth 2.0 JWT access token profiled by this document, carrying the authority granted to one agent at one hop of a chain.

Delegation Chain:

An ordered sequence of Delegation Tokens DT_0, DT_1, ... DT_n, where DT_0 is the root, and each DT_i (i > 0) is linked to DT_{i-1} by the mechanism in .

Authority:

The set of permitted scope values carried by an "agent_delegation" authorization detail in the "authorization_details" claim , together with the constraints in .

Attenuation:

The construction of a child Delegation Token whose Authority is a subset of its parent's, per the subsumption rules in .

Enforcement Point:

The component that verifies a Delegation Chain and permits or denies an action.

Token Format A Delegation Token is a JWT signed with JWS using a fully-specified algorithm . Implementations MUST support Ed25519 and MAY support ES256 and, for post-quantum readiness, ML-DSA . The token uses the "application/at+jwt" header type of and includes its required claims (iss, exp, aud, sub, iat, jti). The protected header SHOULD contain "c14n": "JCS" as an informational label. Verifiers MUST NOT rely on this field. The canonicalization of the protected header and payload JSON is the JSON Canonicalization Scheme (JCS) : producers MUST serialize both with JCS before base64url encoding, and verifiers MUST reject either decoded byte string unless it is exactly the JCS serialization of the parsed object. Verifiers MUST also reject duplicate object member names, non-finite numbers, and lone UTF-16 surrogates. In addition, a Delegation Token contains:

authorization_details:

REQUIRED. An array of authorization detail objects expressing the Authority. See .

cnf:

REQUIRED. A confirmation claim binding the token to the holder's key, proven per DPoP . See .

del_depth:

REQUIRED. A non-negative integer; the position of this token in the chain. DT_0 has del_depth 0.

del_max_depth:

REQUIRED in DT_0. A positive integer; the maximum permitted chain length. MUST NOT be increased by any child (see ).

par_hash:

REQUIRED in every DT_i with i > 0; MUST be absent in DT_0. The base64url-encoded SHA-256 digest of the parent token's JWS Signing Input ( Section 5.1), i.e. of the exact bytes "ASCII(BASE64URL(parent JOSE Header)) || '.' || ASCII(BASE64URL(parent JWS Payload))". This is the byte-commitment that binds a child to one specific parent and prevents chain splicing.

Authority Representation For this profile, Authority is expressed by an authorization detail object whose "type" is "agent_delegation". The object contains a REQUIRED "scopes" member: an array of strings, where each string names one permitted operation. An empty array conveys no permitted operation. Numeric and enumerated bounds ("ceilings") that does not standardize are carried in the "constraints" member defined here.

Scope Syntax and Wildcards Each member of "scopes" MUST match the following ABNF : Thus, scope values are lowercase, dot-separated names with at least two segments. A wildcard is permitted only as the complete final segment following a dot. The bare value *, partial-segment forms such as crm.re*, and non-terminal forms such as crm.*.read are invalid. A producer MUST NOT emit an invalid scope. A verifier that encounters one MUST reject the Delegation Token as malformed before evaluating subsumption. A parent literal scope covers only an identical child scope. A parent wildcard scope covers any child scope whose value begins with the parent value after removing only the final * and retaining the dot. Therefore crm.* covers "crm.read", "crm.x.y.z", and crm.x.*; it does not cover the bare name "crm" or the adjacent namespace "crmx.read". Wildcard coverage is segment-bounded and extends to any depth below the named prefix. This wildcard-covering rule applies only to the "scopes" member of the "agent_delegation" authorization detail type defined in ; other authorization detail types, if defined, specify their own scope semantics.

Constraint Vocabulary The "constraints" member is an array of objects. Each object contains a REQUIRED "key" member identifying the constrained dimension and one typed constraint value. This document defines:

• "max" : a number. The value of the associated quantity MUST NOT exceed it (e.g. {"key": "max_rows", "max": 5000}).
• "min" : a number. The value of the associated quantity MUST NOT be less than it (e.g. {"key": "tenure_years", "min": 2}). Where "max" carries a ceiling tightened downward, "min" carries a floor tightened upward.
• "one_of" : an array. The associated value MUST be a member.
• "not_one_of" : an array. The associated value MUST NOT be a member.
• "prefix" : a string. The associated value MUST have it as a prefix.
• "rank" : used for ordered enumerations (e.g. egress none < internal < any); the value's rank MUST NOT exceed the constraint's.

The registry in allows new constraint types. A verifier that encounters an unknown constraint type MUST treat the action as denied (fail-closed), never as unconstrained.

Subsumption Rules An Authority C is subsumed by an Authority P (written C <= P) if and only if all of the following hold:

1. Every scope in C's "agent_delegation" detail is covered by at least one scope in P's "agent_delegation" detail according to , and
2. for every constraint present in P, a corresponding constraint is present in C whose admissible set is a subset of P's (e.g. C.max <= P.max; C.min >= P.min; C.one_of subset of P.one_of; C.rank <= P.rank), and
3. a constraint present in P MUST NOT be absent in C (absence means unbounded, which is not a subset), and
4. C.exp <= P.exp (monotonic expiry), and
5. C.del_max_depth <= P.del_max_depth.

Attenuation is the construction of C as the greatest lower bound (meet) of P and a request R under these rules. Because the meet can only narrow, C <= P holds by construction for every R.

Chain Linkage Each child token commits to its parent by "par_hash" (). This binds the child to the parent's exact serialized bytes, so a child cannot be re-parented onto a different (e.g. broader) token: doing so changes the parent's Signing Input and thus its SHA-256 digest, which no longer matches the child's "par_hash". The digest is over the already-serialized JWS Signing Input; the protected header and payload that form that input are JCS as required by .

Offline Verification Algorithm An Enforcement Point presented with a Delegation Chain DT_0 ... DT_n and an attempted action A, and holding the trusted root public key(s), MUST perform the following, denying on the first failure:

1. Verify the JWS signature of every DT_i using a fully-specified algorithm . DT_0 MUST verify under a trusted root key.
2. For each i > 0, compute SHA-256 of DT_{i-1}'s JWS Signing Input and compare, in constant time, to DT_i's "par_hash". Any mismatch: deny.
3. Check del_depth: DT_0.del_depth == 0; DT_i.del_depth == i; n < DT_0.del_max_depth. Otherwise deny.
4. For each i > 0, verify DT_i.Authority <= DT_{i-1}.Authority per . Any violation: deny.
5. Check time: for every i, nbf (if present) <= now <= exp, and exp is monotonic non-increasing along the chain. Otherwise deny.
6. Verify holder binding: the presenter proves possession of the key in DT_n.cnf via a valid DPoP proof bound to this request. Otherwise deny.
7. Check revocation: consult the Token Status List reference in each DT_i (if present) against a cached list; if any is revoked, deny (and, by local policy, treat the whole subtree as revoked).
8. Authorize A against DT_n.Authority (scope and every constraint in ). Permit only if A is within it.

The algorithm is deterministic, side-effect free, and requires no network call except the (cacheable, offline-checkable) status list of step 7.

Holder Binding Every Delegation Token is sender-constrained by a "cnf" claim carrying the JWK thumbprint of the holder's key, proven per request with DPoP . mTLS-bound tokens MAY be used where the transport is controlled end-to-end. A captured token is therefore unusable without its bound private key, which mitigates replay of intermediate tokens.

Revocation Delegation Tokens are RECOMMENDED to be short-lived (seconds to minutes for leaf and execution tokens), so that expiry is the common revocation path. For earlier revocation of longer-lived delegations, each token MAY carry a Token Status List reference; revoking a token's status entry, and by local policy the entries of its descendants, revokes a delegation or a whole sub-chain while preserving offline verification (the status list is itself cacheable and offline-checkable). An online revocation endpoint MAY additionally be offered. Deployments that require synchronous cascading revocation MAY issue and exercise Delegation Tokens through an online Delegation Server as specified by . The server can evaluate current delegation-tree state and refuse a revoked root or descendant immediately. This online bridge complements, and does not replace, the offline verification algorithm in : an Enforcement Point that receives a chain MUST still verify its signatures, linkage, attenuation, depth, and expiry.

Security Considerations

Parent tokens remain valid after attenuation Attenuation produces a new child token but does not, by itself, invalidate the parent. A party holding the parent still holds the parent's (broader) authority. This is mitigated by three mechanisms that MUST be considered together: (a) tokens are short-lived and holder-bound (), so a leaked parent is both time-boxed and non-replayable without its key; (b) the "par_hash" byte-commitment () prevents splicing a child onto a different parent; and (c) status-list revocation () allows early invalidation of a parent and its subtree. Deployments that require immediate parent invalidation on delegation MUST use short TTLs and status lists accordingly.

Chain splicing Without the byte-commitment, an attacker could present a valid child together with a broader token as its purported parent. Step 2 of prevents this: the child's "par_hash" digests the parent's exact Signing Input, so only the intended parent verifies.

Confused deputy and over-broad delegation Because each hop's authority is the meet of parent and request (), a child cannot be induced (e.g. by prompt injection) to exercise authority the parent lacked.

Unbounded depth and fan-out "del_max_depth" (checked in step 3) bounds chain length; deployments SHOULD set it low (e.g. 5). Fan-out (a parent delegating to many children) is not limited by the token format and MUST be bounded by the issuing infrastructure if required.

Offline verification vs. revocation latency Offline verification means an enforcement point may honor a token that has been revoked but whose status-list update it has not yet fetched. Deployments trade this window against TTL: shorter TTLs bound the exposure. This is the standard status-list trade-off and MUST be documented for each deployment.

Why not macaroons; algorithm agility Macaroons verify with the root secret, precluding public offline verification at an untrusted edge; this document uses public-key signatures. Algorithms are fully specified and agile via the JOSE "alg" registry, with a migration path to ML-DSA .

IANA Considerations This document requests registration, in the JSON Web Token Claims registry, of: "del_depth", "del_max_depth", and "par_hash" (with the semantics in ). It requests a new "Agent Delegation Constraint Types" registry (initial entries: "max", "min", "one_of", "not_one_of", "prefix", "rank"; registration policy Specification Required; unknown types fail closed per ). It requests an "authorization_details" type value for delegated agent authority, coordinated with to avoid divergence.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. MATTR Bundesdruckerei SPRIND This specification defines a status mechanism called Token Status List (TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT, CBOR Web Token, and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. Informative References This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. This memo defines an Experimental Protocol for the Internet community. This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. TowerGuardian Consulting Autonomous software agents increasingly act on behalf of human principals by invoking tools, services, and other agents, frequently across organizational boundaries. Existing workload and token-based authorization mechanisms were designed for a single trust domain and a small number of delegation hops. They do not adequately express, constrain, or verify authority that is delegated recursively among agents and that crosses the boundary between independently administered organizations. This document describes the problem of cross-organizational agent delegation, identifies the gaps in current mechanisms, and enumerates requirements that any solution within the scope of the Workload Identity in Multi-System Environments (WIMSE) working group should satisfy. It does not specify a solution. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. Tenuo This document defines Attenuating Authorization Tokens (AATs), a signed credential format for task-scoped delegation in AI agent systems. An AAT encodes the tools an agent may invoke and the argument constraints that apply to those invocations. A token holder authorized to delegate can derive a token offline with equal or narrower authority, subject to the parent token's depth and lifetime limits. The resulting delegation chain is verifiable offline by any enforcement point that has the root issuer's trust anchor key. This specification profiles the OAuth Rich Authorization Requests format (RFC 9396) for tool-level capability claims, adds delegation- chain claims, and defines a core constraint vocabulary for argument restrictions. The chain verification algorithm authenticates each delegation step and enforces monotonic attenuation without network contact with the root issuer. Violet Sky Security SEZC Current authorization is role-scoped: an actor is granted a role whose authority persists across every action it takes. This fails exactly when actors fail -- under compromise, prompt injection, or goal hijacking -- because a compromised actor retains full role authority. This document specifies SPT-Txn, a family of transaction- bound authorization tokens in which authority exists only inside a short-lived token bound to one declared action, on one resource, under one jurisdictional policy, verified against how the requesting workload was attested. Delegation across agents and tools is expressed as a cryptographically sealed chain that can only narrow authority and is verifiable offline. Each authorization decision emits a signed, tamper-evident receipt as a byproduct of enforcement. This document specifies normative intent binding, transaction receipts and their transparency log, attested issuance via OAuth 2.0 Token Exchange, per-token status-list revocation, and cryptographic algorithm agility including hybrid post-quantum signing. It also hardens attested issuance in response to an adversarial security review of the reference implementation: it makes an audience and a verifiable expiry mandatory on the presented attestation, requires the issuer to bound the delegated depth it grants, and clamps a token's lifetime to the attestation it was minted on. The issuer- side requested-versus-permitted scope intersection is retained; the enforcement point re-checks the chain independently. Autonomous AI agents increasingly require access to protected resources across multiple service providers on behalf of human users. Existing OAuth 2.0 extensions address individual aspects of this problem (token exchange, proof-of-possession, and structured authorization) but no current specification defines how these mechanisms compose into a coherent credential delegation framework for AI agents. This document specifies the Credential Delegation Protocol: a profile of OAuth 2.0 Token Exchange (RFC 8693), Demonstrating Proof-of- Possession (RFC 9449), Rich Authorization Requests (RFC 9396), and Client-Initiated Backchannel Authentication (OpenID Connect CIBA) that enables human users to delegate scoped, attenuated credentials to AI agents operating across heterogeneous service providers. The protocol defines: agent identity lifecycle management using ephemeral key pairs; capability-shaped delegation tokens bound to specific operations and resources; credential wrapping semantics that prevent exposure of underlying OAuth tokens to agents; consent-gated delegation flows for asynchronous agents; real-time cascading revocation; and tamper-evident audit chains. This document does not define new token formats, new OAuth grant types, or modifications to existing authorization server behavior. It specifies how existing mechanisms are combined to achieve secure, auditable credential delegation for AI agents. Independent This document specifies a profile for delegating authorization to automated agents across administrative domains. It defines an HTTP header field, Agent-Delegation, that carries a chain of attenuated delegation links. Each link narrows the scope, tightens or holds a set of floor conditions, and shortens or holds the expiry of its parent. A verifier checks every link in the chain, not only the last, and rejects the chain if any link violates attenuation. The profile is deliberately agnostic to the credential format and to the nature of the entity that issues floor attestations; it specifies required properties, not a specific encoding or a specific kind of issuer. It composes with, and does not replace, existing work on agent credential provisioning and posture. n.d.

Acknowledgments This work builds directly on, and seeks convergence with, , , , , and the requirements of . The capability-token lineage of , , and is gratefully acknowledged. The "min" constraint type was added after Amr Hassan, author of , observed that -00 had no comparator for a floor tightened upward; the duration-typed "tenureMin" axis of that document is the motivating example.

Reference Implementation and Test Vectors A permissively licensed reference implementation (the "attenu-guard" library) and a set of offline-verification test vectors (chains that MUST verify and adversarial chains that MUST be rejected) accompany this draft. Separating vectors cover scope and ceiling widening, parent splicing, depth and expiry violations, wildcard errors, RFC 8785 number and string forms, non-finite values, duplicate member names, and the informational "c14n" label, including a valid JCS token without that label. They are intended for interoperability testing across independent implementations.