Individual Submission

founder@phalanxaisec.com

Security This document defines a trust model for agent-to-agent (A2A) interactions in multi-agent AI systems. It specifies how agents obtain verifiable identities via CA-signed templates, how spawn chains are cryptographically established and validated, how dynamic policies are governed under a dual-signature model, and how cross-organizational agent interactions are explicitly authorized. The model applies existing PKI primitives (X.509, CRL, CSR) and established identity patterns (OAuth 2.0, On-Behalf-Of) to the problem of agent provenance. This document does not address agent-to-resource access control, human-in-the-loop orchestration, or agent behavior, as those concerns belong to the resource enforcement layer and the orchestration layer respectively.

Introduction Multi-agent AI systems introduce identity and authorization gaps that existing standards do not fully address. When Agent A spawns Agent B, and Agent B calls a resource, no current standard defines how the resource verifies that Agent B was legitimately spawned, that its scope has not been escalated, or that its origin template is trusted. This document proposes a trust model based on:

• Agent templates as first-class, CA-signed identity artifacts.
• Verifiable spawn chains where each agent's provenance is cryptographically traceable to a registered template.
• Two-lane governance separating static identity (cert-based) from dynamic policy (policy-engine gated).
• Fail-closed enforcement at every verification step.

The model reuses proven PKI primitives and applies them to a new surface -- agent identity -- rather than inventing new cryptographic mechanisms.

Conventions Used in This Document 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.

Document Encoding Every document defined by this specification -- the Agent Template extension of , the Agent Spawn extension of , the dynamic policy document of , the cross-organizational grant of , and the audit log entry of -- is a JSON object serialized using the JSON Canonicalization Scheme (JCS) . Field names in the tables of this document are display names, written for a reader. The corresponding wire names are lowercase, use underscore as the word separator, and are given in . A relying party MUST compare wire names exactly and MUST NOT apply case folding, Unicode normalization, or any other transformation before comparison. The same rule governs every string value this document compares for equality: an agent identifier, an Owner, an OrgID, a Grantor or Grantee, a scope, a nonce, an outcome. Two values are equal when their octets are identical, and a relying party MUST NOT apply case folding, Unicode normalization, trimming, or any other transformation to either before comparing them. Where a later section restates this for one value, it does so for emphasis, not because the rule differs there. A JSON object carried under this specification MUST NOT contain a duplicate member name, which , Section 3.1, also requires of any input to JCS. A relying party MUST detect a duplicate and refuse the document. This is a requirement on the parser, not only on the document: JSON syntax permits duplicates, and a parser that silently keeps the first or the last occurrence does not satisfy it. Two such parsers disagree about what was signed while both report success, which is the failure this rule exists to prevent. Every timestamp carried under this specification is an date-time in UTC using the Z designator. A relying party MUST refuse a timestamp carrying a numeric offset, a lowercase designator, or no designator: a time is compared byte-for-byte in a signed body, and one instant with two spellings is two instants to a signature. Fractional seconds MAY be present. The JSON objects this document defines are flat. Their members are strings, integers, or arrays of strings, as the tables specify, and nothing else. A relying party MUST refuse an object carrying a nested object, an array of anything other than strings, a null, a boolean, or a non-integer number, before any further processing. A parser that will accept only the shapes this document defines has no depth to exhaust and no type to confuse.

Signature Envelope A signed document is carried inside an envelope: a JSON object whose members are the signed document itself and the values that attest to it. The envelope members are named as follows. These names are REQUIRED; a relying party MUST refuse an envelope carrying any member not listed here. Envelope Members

Member	Type	Content
body	object	The signed document: a template, a policy, or a grant
owner_sig	string	Signature by the template Owner
pa_sig	string	Signature by the Policy Authority
content_hash	string	SHA-256 digest of the signed octets, lowercase hexadecimal. REQUIRED in the envelope of a dynamic policy document; MUST be absent from the envelope of a template or a grant ()

Every signature, and the content hash, is computed over the same octet string: the JCS serialization of body, and nothing else. The other envelope members are outside body and therefore never inside a preimage. A signature cannot cover itself, and an implementation that signs the whole envelope produces a value no verifier can reproduce. The rule that a document carrying an undefined field MUST be refused applies to body; the envelope members are not fields of the document they attest to. Each signature member MUST be a string containing the base64 encoding of the raw signature value, without line breaks and without PEM framing. A relying party MUST refuse an envelope whose owner_sig and pa_sig verify under the same public key: the subjectPublicKeyInfo of the Owner certificate and of the Policy Authority certificate MUST differ. Two roles satisfied by one key is one role. The comparison is of keys, not of signature octets: a randomized signature scheme produces different octets from one key on every signing, so equal signatures would never be observed even when a single key holds both roles. The signature algorithm is determined by the type of the signer's public key, as carried in the signer's certificate, and is not signalled in the envelope. A signer MUST use, and a relying party MUST verify with, exactly the algorithm this table assigns; any other combination MUST be refused. Signature Algorithm by Key Type

Signer key	Algorithm	Signature value
RSA, 3072 bits or more	RSASSA-PSS with SHA-256, MGF1 with SHA-256, salt length 32 octets	The PSS signature octets
EC, curve P-256	ECDSA with SHA-256	r and s, each 32 octets, concatenated: 64 octets
EC, curve P-384	ECDSA with SHA-384	r and s, each 48 octets, concatenated: 96 octets
Ed25519	Ed25519 (PureEdDSA)	The 64-octet EdDSA signature

Fixing the digest to the key type is what allows the envelope to carry no algorithm identifier: a verifier learns everything it needs from the certificate it has already validated, and an attacker cannot negotiate a weaker algorithm because there is nothing to negotiate. ECDSA values are the fixed-width concatenation rather than DER, so that a signature has exactly one encoding. RSASSA-PSS is specified rather than RSASSA-PKCS1-v1_5 because PSS carries a security proof and is the scheme new profiles adopt; a relying party MUST refuse a PKCS1-v1_5 signature even when it verifies. PSS is randomized: the same key and body produce a different signature on each signing, so a test vector verifies a signature rather than comparing its octets.

Wire Names The following table gives the wire name for every display name used in this document. Where a display name appears in more than one document it has the same wire name in each. Display Name to Wire Name

Display name	Wire name	Defined in
Subject	subject	Sections ,
Owner	owner	Sections ,
OrgID	org_id	Sections ,
PermittedOperations	permitted_operations	Section
AllowedScopes	allowed_scopes	Sections ,
CanSpawn	can_spawn	Section
MaxChildren	max_children	Section
PolicyRef	policy_ref	Section
TTL	ttl_seconds	Sections ,
Scopes	scopes	Section
SpawnTargets	spawn_targets	Section
Version	version	Section
IssuedAt	issued_at	Sections ,
NotAfter	not_after	Section
Grantor	grantor	Section
Grantee	grantee	Section
Template	template	Section
MaxSpawns	max_spawns	Section
GrantID	grant_id	Sections ,
ParentAgentID	parent_agent_id	Section
SpawnedAt	spawned_at	Section
SpawnNonce	spawn_nonce	Section

Terminology

Agent:

An ephemeral, autonomous process that performs tasks on behalf of a user or another agent.

Agent Template:

A CA-signed artifact defining exactly one agent's identity, allowed scopes, spawn rules, and policy reference. A template is not a class from which many agents are made: its Subject is the identifier of the one agent it defines, and spawning from a template instantiates that agent. A deployment wanting many similar agents registers many templates.

Relying Party:

Any party that validates an agent's certificate, chain, policy, or grant in order to decide whether to act on it -- a resource, a Registry evaluating a spawn request, or another agent.

Owner:

The party responsible for a template, identified by the template's Owner field and holding the private key of the Owner certificate described in .

Orchestrator:

An agent that spawns other agents. The figures in this document use the bare term for any such agent; the Root Orchestrator is the one with no parent.

Root Orchestrator:

An agent that has no parent. Its certificate carries no Agent Spawn extension ().

Template Registry:

The authoritative store of approved, signed agent templates for an organization.

Template Registry CA:

The Certificate Authority that signs agent templates -- the root of trust for the agent ecosystem.

Spawn:

The act of an agent instantiating a child agent from an approved template.

Spawn Chain:

The ordered, cryptographically verifiable sequence of agents from the root orchestrator to the current agent.

Policy Authority:

The entity responsible for countersigning dynamic policy changes after automated gate validation.

CRL:

Certificate Revocation List -- the list of revoked template and agent certificates maintained by the CA.

CSR:

Certificate Signing Request -- the template author's request to the CA for a signed template certificate.

Cross-Org Grant:

An explicit, signed authorization allowing agents from one organization to spawn from a template owned by another.

The Template Registry and the Template Registry CA are described as one logical entity throughout this document -- "the Registry" -- that stores templates, evaluates spawn requests, and issues certificates. A deployment may separate them; the interface between them is outside this document, and every requirement placed on "the Registry" applies to that entity as a whole.

Problem Statement Multi-agent orchestration creates identity and authorization gaps:

spawns --> Agent B --> calls --> Resource ]]>

• Which identity does the Resource see?
• How does authorization propagate across the chain without escalating?
• If Agent B is compromised, can it impersonate Agent A?
• Who owns the audit trail across the full chain?
• How does the Resource prove Agent B was authorized to be spawned?

The author is not aware of a standard, from the W3C, the IETF, or a vendor, that fully addresses agent provenance in multi-hop chains.

Existing Patterns and Gaps Several systems address a neighbouring problem. Workload identity frameworks such as SPIFFE issue verifiable identities to services but do not model one service spawning another under a bounded delegation. Relationship-based authorization systems such as OpenFGA evaluate what an identity may do but assume the identity is already established. PKI secrets engines such as Vault issue certificates on request but leave the content of a certificate to the requester. This document assumes the zero-trust posture of , in which no request is trusted for where it came from, and applies it to the question those systems leave open: how an agent proves what authority it was granted, and by whom.

On-Behalf-Of (OBO) Microsoft Entra ID OBO provides user-to-service delegation:

Agent A (token A) --> Agent A requests token for Agent B on behalf of user --> Entra validates the chain --> Issues scoped delegated token ]]>

Key insight: a trusted third party validates the delegation chain. Agents do not self-assert trust. OBO breaks down for agent-to-agent because agents are ephemeral, agent spawning is dynamic, and no registry exists for agent templates.

OAuth 2.0 Token Exchange (RFC 8693) OAuth 2.0 Token Exchange defines scope constraint across delegation hops -- downstream tokens MUST be a subset of upstream grants. This document adopts that principle for agent scope inheritance.

Agent Identity Agent identity MUST be established using X.509 certificate chains . This reuses the same trust model used by TLS and existing workload identity systems.

Certificate Profile Certificates used for agent identity MUST conform to . In addition, a relying party validating an agent certificate MUST enforce all of the following, and MUST refuse the certificate if any is not satisfied:

• An agent certificate MUST carry the basicConstraints extension asserting cA = FALSE. A certificate that omits basicConstraints MUST be refused; the extension's absence MUST NOT be treated as equivalent to cA = FALSE.
• A Template Registry CA certificate MUST carry basicConstraints asserting cA = TRUE, marked critical, and MUST assert keyCertSign in its keyUsage extension.
• Certificates MUST be signed using SHA-256 or a stronger digest. Certificates signed with SHA-1 or MD5 MUST be refused irrespective of key size.
• Public keys MUST provide at least a 128-bit security level as defined in : RSA with a modulus of 3072 bits or more, an EC key on P-256 or P-384, or an Ed25519 key . A relying party MUST refuse a certificate whose key falls below this level, including an RSA key of 2048 bits. EC and Ed25519 keys are RECOMMENDED over RSA: they reach the floor with smaller certificates and faster generation, and Ed25519 signatures are deterministic.
• An agent certificate MUST carry the keyUsage extension, marked critical, asserting digitalSignature and no other bit. keyCertSign and cRLSign MUST NOT be asserted on an agent certificate; a relying party MUST refuse one that asserts either, independently of the basicConstraints check above.
• The serialNumber MUST contain at least 64 bits of output from a cryptographically secure random number generator. A predictable serial number is an input an attacker controls when searching for a digest collision over a certificate. The value is an ASN.1 INTEGER, which requires to be positive, at most 20 octets, and in minimal DER form. An implementation that clears the top bit of the first random octet to keep the value positive discards a bit of entropy and, one draw in 256, produces a leading zero octet followed by an octet below 0x80 -- a non-minimal encoding that a strict parser refuses. Draw the random octets, at most 19 so that a prepended octet stays within the limit; strip any leading zero octets; and prepend a single zero octet only when the first remaining octet has its top bit set. The result is positive, minimal, and carries every bit it was given.

An agent certificate asserting cA = TRUE is a certificate entitled to issue further certificates. Such an agent can create children without presenting a request to the Template Registry CA, which removes both checks required by from the spawn path entirely. No signature is invalid in that scenario and no chain fails to verify; the containment described in is simply never consulted. This is the reason the constraint is stated normatively here rather than left to the general RFC 5280 profile. These requirements are necessary and not sufficient. A certificate satisfying all of them establishes identity only; it carries no authorization. See .

Binding Identity to the Certificate An agent has exactly one identity, expressed as a UUID in the canonical lowercase textual form defined in . A relying party MUST refuse a certificate whose subject common name is absent, is not a well-formed UUID in that form, or does not match the agent identifier the presenting party claims. Uppercase hexadecimal MUST be refused rather than case-folded: the identifier is compared byte-for-byte in several places, and an implementation that folds in one of them and not another will accept a document another implementation refuses. This document does not constrain which UUID version is used. Implementations SHOULD use version 4 where the time an agent was created should not be inferable from its identifier, and MAY use version 7 where time-ordered identifiers are wanted and that disclosure is acceptable. A version 7 identifier embeds a millisecond timestamp, and an agent identifier travels to places its template does not -- audit records, policy references, diagnostic messages -- so the disclosure is wider than the certificate's own notBefore field. Where a chain document restates that identifier alongside the certificate, every restatement MUST be identical to the subject common name, and a relying party MUST refuse the document if any two disagree. An implementation MUST NOT treat one restatement as authoritative and the others as advisory. This requirement exists because a restated identifier that no signature covers is an unsigned claim sitting next to a signed one. Without this rule a chain could name one agent in the position a relying party reads and present a certificate issued to a different agent, and both artifacts would validate on their own terms.

Certificate Signing Request Flow

Certificate Chain Structure

Orchestrator Agent Certificate | Subject CN: 9f3c... (a UUID, Section 7.2) | Issuer: Template Registry CA | Agent Template extension (Section 8.2): | subject: 9f3c... (equals Subject CN, 9.3) | owner, org_id | permitted_operations: [spawn] | allowed_scopes: [read:data, write:data] | can_spawn: [2b7e...], max_children: 1 | policy_ref, ttl_seconds: 3600 | +--> Child Agent Certificate Subject CN: 2b7e... (a UUID) Issuer: Template Registry CA Agent Template extension: subject: 2b7e... allowed_scopes: [read:data] (subset, 10.3) ttl_seconds: 900 (shorter, SHOULD) Agent Spawn extension (Section 10.5): parent_agent_id: 9f3c... spawned_at, spawn_nonce grant_id (only when spawned under a grant, 13.2) An agent certificate never issues a certificate (Section 7.1). The parent-child link is recorded in the child's Agent Spawn extension; the chain of authority runs through the CA. ]]>

Template Structure

Static Fields The following fields MUST be present in every agent template certificate and MUST NOT be modified without full re-certification:

Field	Required	Description
Subject	REQUIRED	Unique template identifier
Owner	REQUIRED	Verified identity of template owner
OrgID	REQUIRED	CA-validated organization identifier
PermittedOperations	REQUIRED	Operations this agent may perform
AllowedScopes	REQUIRED	Maximum scopes this agent may hold
CanSpawn	REQUIRED	Whitelist of permitted child templates
MaxChildren	REQUIRED	Maximum concurrent child agents
PolicyRef	REQUIRED	Pointer to dynamic policy store
TTL	REQUIRED	Maximum agent lifetime

This document defines one value of PermittedOperations: spawn, which an agent MUST hold to invoke . Any other value, including those shown in examples, is defined by the deployment and carries no meaning under this specification. A template whose CanSpawn is non-empty while its PermittedOperations omits spawn describes an agent permitted to spawn specific children and not permitted to spawn; the conformance gate of SHOULD refuse it, and a Registry MUST refuse a spawn request from it. A template defines exactly one agent (), so each entry of CanSpawn names a child that can exist at most once at a time, and MaxChildren counts named children rather than instances of one. MaxChildren MUST NOT exceed the number of entries in CanSpawn. The conformance gate of MUST refuse a template that violates this, and a relying party MUST refuse a certificate whose extension does. A cap above the number of children a template can name is a cap on nothing, and a validator reading it would count toward a limit that can never be reached. The certificate's issuer is not a template field. It is set by the Template Registry CA at issuance () and read from the certificate (); a template carries no member for it.

Encoding of Static Fields The fields in MUST be carried in a single X.509 certificate extension, identified by the object identifier 2.25.318754453516410815925104555075461256891 and referred to in this document as the Agent Template extension. The extension MUST be marked critical. A validator that does not implement this specification therefore refuses the certificate, as requires of any unrecognized critical extension, rather than accepting it as an ordinary client certificate and granting whatever its issuer's chain would grant. The certificate is unusable except by a party that understands what it says, which is the fail-closed outcome requires; an agent certificate has no legitimate use outside this specification. The extnValue MUST be a DER OCTET STRING whose contents are the UTF-8 encoding of a JSON object, serialized as required by . A relying party MUST refuse a certificate whose Agent Template extension is not valid JCS, and MUST NOT attempt to repair or re-canonicalize it. The JSON object MUST carry exactly the following members, all of which are REQUIRED. Wire names are as given in . A relying party MUST refuse a certificate whose Agent Template extension omits any member, carries a member not listed here, or carries a member whose type differs from the type given. Agent Template Extension Members

Member	Type
subject	string
owner	string
org_id	string
permitted_operations	array of string
allowed_scopes	array of string
can_spawn	array of string
max_children	integer
policy_ref	string
ttl_seconds	integer

The ttl_seconds member states a duration in seconds; the display name TTL in does not carry a unit, and a duration whose unit is inferred is a duration two implementations will infer differently. The certificate's issuer has no member in this extension. X.509 already carries the issuer, and a second copy inside an extension the issuer signs could disagree with the copy the relying party validated the signature against. A relying party MUST take the issuer from the certificate. A certificate MUST NOT carry more than one Agent Template extension, and a relying party MUST refuse a certificate carrying two rather than choosing between them. The duplicate member rule of applies, and is a requirement on the parser used to read the extension. A relying party MUST impose a limit on the size of the extension before parsing it, and MUST refuse an extension exceeding that limit rather than attempting a partial parse. The limit is 16384 octets of extnValue for the Agent Template extension and 1024 octets for the Agent Spawn extension of . The first holds two hundred scopes at the maximum length of , which is more than any template this document contemplates; the second holds every member of a fixed-shape object with room to spare; and neither is large enough to be worth handing to a parser unverified. The extension arrives inside a certificate presented by the party whose authority it describes; it is attacker-controlled input up to the point the issuer's signature has been verified, and that signature covers whether the bytes were issued, not whether they are safe to parse. Implementations SHOULD verify the certificate signature before parsing the extension, so that malformed input from an unsigned certificate is discarded without being decoded at all. Placing these fields in the certificate rather than in a document accompanying it is deliberate. requires that they not change without re-certification. A field carried outside the certificate is signed by whoever assembled the document, not by the Template Registry CA, so an agent could present a valid certificate beside a template granting authority the CA never issued. Carrying them inside the certificate makes the immutability requirement a property of the artifact rather than a rule an implementation is asked to remember.

Dynamic Policy Bounds Dynamic policies MUST be bounded by the static template fields. A dynamic policy MUST NOT grant scopes beyond AllowedScopes. A dynamic policy MUST NOT add spawn targets beyond CanSpawn. A relying party MUST evaluate these bounds itself, on every validation, against the static fields of the template certificate naming the subject the policy governs. This evaluation MUST be independent of signature validity -- a bounds violation is refused whether or not the signatures verify -- and it is performed after signature verification, in the order given by , so that a refusal under this section reports an authentic document whose content is not permitted. A policy exceeding the bounds MUST be refused before it is applied, however many valid signatures it carries. The signatures required by and the bounds required here answer different questions. The signatures establish who authorized a change. They do not, and cannot, establish that the change was within the ceiling the template set, because the ceiling is stated in a certificate that no signature over the policy covers. An implementation that treats a valid dual signature as sufficient authority to apply a policy has removed the only mechanism bounding what a policy may grant. Refusal under this section is a distinct condition from a signature failure, and implementations SHOULD report it distinctly: the document is authentic and its content is not permitted. Reporting it as a signature failure misdirects the operator to the wrong lane of .

Template Authoring and Attestation A template is authored before any certificate is issued against it. This section specifies the checks that MUST pass before a Template Registry CA issues a certificate carrying the fields of .

Conformance Gate Every field marked REQUIRED in MUST be present and non-null before a template is signed. A template missing any REQUIRED field is non-conforming and MUST be refused, both at signing and again at issuance. An implementation MUST NOT sign a non-conforming template, and MUST NOT issue a certificate against one by omitting the corresponding member from the Agent Template extension. The gate is applied twice deliberately. A template that was conforming when signed can be edited afterwards, and an issuance path that trusts the signature without re-checking conformance will issue a certificate whose extension is missing a member the relying party requires.

Dual Attestation A template MUST carry two signatures before it is eligible for issuance: one from the template Owner and one from the Policy Authority. Both signatures MUST be computed over the same octet string, as required by , being the JCS serialization of the template restricted to the members of . A relying party MUST verify both, and MUST refuse the template if either is absent or does not verify. Signature verification MUST occur after the conformance gate of , not before. A signature over an incomplete body is a valid signature over an incomplete body. Every member that becomes part of the Agent Template extension MUST be inside the signed body. A member carried into a certificate without having been covered by both signatures has entered the certificate without the approval the two signatures exist to record. Both signatures MUST use the algorithm that assigns to the signer's key type, over a key meeting the strength floor of . The requirement is stated by reference rather than restated, because two lists of acceptable algorithms in one document will eventually disagree, and the weaker of the two becomes the one an implementation follows. The Owner and the Policy Authority each hold a certificate conforming to , issued by the Template Registry CA or by a CA the relying party trusts for that purpose. A relying party MUST validate that certificate to a trust anchor it holds before verifying any signature with its key, and MUST refuse a signature whose certificate does not validate: a signature that verifies under an untrusted key establishes nothing. The subject common name of the Owner certificate MUST equal the template's owner member; that equality is what binds the string in owner to a key. The Policy Authority certificate is a trust decision the relying party configures, one per Registry.

Issuance On issuance the Template Registry CA MUST re-apply the conformance gate, MUST re-verify both signatures, and MUST copy the signed members into the Agent Template extension of without alteration. The CA MUST set the certificate subject common name to the value of the template's subject member, which MUST satisfy , and MUST set the issuer to its own name. The template carries no issuer member, and the CA MUST NOT take the issuer from the template. A relying party MUST refuse a certificate whose subject common name differs from the subject member of its Agent Template extension. The CA MUST set the certificate's notAfter to no later than its notBefore plus the template's ttl_seconds, so that the TTL of is enforced by ordinary certificate path validation and not only by a relying party that reads the extension. A relying party MUST refuse a certificate whose notAfter minus notBefore, in seconds, exceeds its ttl_seconds: a certificate that outlives its own stated lifetime was not issued as this section requires. ttl_seconds MUST NOT exceed 604800 (seven days), and SHOULD NOT exceed 86400 (one day). A relying party MUST refuse a certificate whose ttl_seconds exceeds the maximum. An agent is ephemeral by the definition in ; its certificate's lifetime is the longest an attacker holding its key can act if revocation is slow to propagate, and can only refuse a certificate a relying party knows to be revoked. A short lifetime bounds that window without depending on revocation reaching every relying party.

Spawn Chain Validation

Two-Check Spawn Rule Every spawn MUST pass two independent checks. Either check failing MUST result in spawn denial with no fallback. The Template Registry performs both checks, as specifies. That section lists the individual conditions in the order they are evaluated; this section states which check each condition belongs to, and an implementation MUST evaluate every condition of both. Check 1 -- Static (from the spawning agent's certificate): The spawning agent's PermittedOperations MUST include spawn, the requested child template MUST appear in the spawning agent's CanSpawn list, and the requested scopes MUST be a subset of the spawning agent's AllowedScopes (). All three are read from the Agent Template extension of the spawning agent's certificate, never from a document the agent supplies. These are steps 1 and 4 of . Check 2 -- Dynamic (Registry live lookup): The requested child template MUST be currently registered, CA-signed, not self-signed, not present in the current CRL, not DISABLED under , and owned either by the spawning agent's organization or by an organization that has issued a grant under naming the spawning agent's organization as Grantee. The child template MUST also appear in the SpawnTargets of the dynamic policy currently in force for the spawning agent (), which the Registry retrieves through the PolicyRef of the spawning agent's certificate and never accepts from the agent; a policy with no SpawnTargets grants none, and an agent with no policy in force may not spawn. Finally the spawning agent's live child count MUST be below its MaxChildren. These are steps 2, 3 and 5 of . Rationale: CanSpawn alone is insufficient because the certificate may be stale and a template may have been revoked since issuance. Registry lookup alone is insufficient because any party could forge a request claiming any template. The policy condition is what gives the fast lane of authority over spawning: CanSpawn is the ceiling the certificate sets, SpawnTargets is what the Owner has currently authorized within it, and a spawn target can therefore be withdrawn by a policy change without re-certification. Both checks MUST pass.

Spawn Validation Sequence

DENY, audit log YES --> continue 2. Registry check -- child template registered, CA-signed, not revoked, not DISABLED, and owned by the spawning agent's organization or granted to it? NO --> DENY, audit log YES --> continue 3. Policy check -- child template in the SpawnTargets of the policy in force for the spawning agent? NO --> DENY, audit log YES --> continue 4. Scope check -- requested scope subset of parent scopes? NO --> DENY, audit log YES --> continue 5. MaxChildren check -- current children < MaxChildren, and no live certificate for the child template already? NO --> DENY, audit log YES --> spawn approved 6. Template Registry CA issues the child certificate with: - parent identity embedded (delegation chain) - scope equal to requested scope (not exceeding parent) - spawn timestamp and nonce (replay prevention) - grant identifier, when spawned under a grant - audit log entry written ]]>

The count compared against MaxChildren in step 5 is held by the Template Registry, which is the only party that observes every spawn under a template. The Registry MUST perform that comparison as part of Check 2 of , atomically with recording the new child, so that two concurrent spawn requests cannot both observe a count one below the limit and both succeed. The second condition of step 5 follows from : a template defines one agent, one identity never holds two valid certificates, and the Registry MUST therefore refuse to spawn a child whose template already has an unexpired, unrevoked certificate. A relying party validating a chain document counts only the children that document names, and MUST refuse a document in which that count exceeds the parent's MaxChildren; that is a consistency check on the document, not the enforcement of the cap, and an implementation MUST NOT present it as such. The Template Registry CA performs steps 1 through 5 and issues the certificate in step 6. The spawning agent presents a spawn request -- the child template's subject, the requested scopes, a timestamp, and a nonce per -- and receives the issued certificate; it signs nothing, because forbids an agent certificate from issuing. Steps 1 and 4 are evaluated against the spawning agent's own Agent Template extension, which the Registry reads from the certificate it presented. Step 3 is evaluated against the policy in force for the spawning agent, which the Registry retrieves through the PolicyRef of that extension; a policy the agent supplies with its request MUST NOT be consulted. If the policy store cannot be reached, or no policy is in force, the request is refused under .

Scope Constraint A child agent's AllowedScopes MUST be a subset of the parent agent's AllowedScopes: every scope granted to the child MUST also be held by the parent. A child MUST NOT be granted any scope the parent does not itself hold; scope escalation across agent hops is explicitly prohibited. Equality is permitted -- a child MAY be granted the same scope set as its parent, or fewer. Example:

A scope is an opaque token. Two scopes are the same scope when their octets are identical, and a relying party MUST NOT apply case folding, Unicode normalization, prefix matching, wildcard expansion, or any hierarchy: write:data does not imply read:data, and admin:* names nothing. A scope MUST be between 1 and 64 octets, each from the set of lowercase ASCII letters, ASCII digits, colon, underscore, and hyphen. A relying party MUST refuse a document carrying a scope outside that syntax; the syntax is constrained so that byte comparison is also visual comparison, and a confusable character cannot name a scope that looks like another. What a scope grants access to -- a secrets store, a data set, a tool -- is resource-layer authorization and is outside this document, as the Abstract states. This document bounds which scopes an agent may hold and how that bound narrows across a spawn; it does not define what any scope means. A deployment that needs to express "this agent may read vault A" does so with a scope such as secrets:vault-a:read, carried in allowed_scopes, bounded by the parent's allowed_scopes, and interpreted by the resource that owns vault A. The registry of exists so that such names can eventually mean the same thing across organizations. A collection of scopes is a set. The order in which its members appear is not significant to any comparison in this document, and a collection carrying the same scope twice is malformed and MUST be refused. The subset test above is therefore set containment, and two conforming implementations reach the same answer for the same two collections regardless of ordering. Order is significant only to serialization: preserves array order, so the octets a signature covers depend on it. An implementation that reorders a collection before verifying it has changed those octets, and the signature fails; reordering is therefore not a normalization step. Comparison is performed on the parsed set, verification on the octets as received. A request for no scopes MUST be refused. The empty set is a subset of every set, so an empty request satisfies the containment test vacuously while declaring no intent for the test to bound. A child's ttl_seconds SHOULD NOT exceed its parent's. A delegation that outlives its delegator holds authority derived from an agent that no longer exists; the parent's certificate may be renewed, but a child sized to outlast it was sized on the assumption that it would not need to be.

Audit Requirements Every spawn event, accepted or refused, MUST be recorded as an audit log entry: a JSON object carrying exactly the following members, subject to the presence rules the table states, serialized as requires and hashed as requires. The entry has no display names; wire names are given directly. Audit Log Entry Members

Member	Type	Content
spawning_agent_id	string	Identifier of the spawning agent, in the form of
child_template_id	string	Subject of the requested child template, in the same form
requested_scopes	array of string	The scopes the request asked for
granted_scopes	array of string	The scopes issued; empty when outcome is DENIED
spawn_nonce	string	The nonce of the request, per
grant_id	string	The GrantID of when the spawn was requested under a grant; MUST be absent otherwise
timestamp	string	The instant the Registry recorded the outcome, per , in UTC
outcome	string	ALLOWED or DENIED, exactly
reason	string	The step of that refused the request, and why; REQUIRED when outcome is DENIED, MUST be absent otherwise
previous_hash	string	The entry_hash of the preceding entry, lowercase hexadecimal; sixty-four zero digits for the first entry of a log
entry_hash	string	SHA-256 over the canonical form of every other member of this entry, lowercase hexadecimal, per

A refused request is recorded for the same reason an accepted one is: a sequence of refusals is the evidence of an attempt, and a log that records only successes cannot show one.

Encoding of Spawn Provenance Step 5 of issues a child certificate carrying its parent's identity, the time of the spawn, and the nonce of the request that produced it. These MUST be carried in a single X.509 extension, marked critical for the reason given in , identified by the object identifier 2.25.316124730704531463413455892107752909312 and referred to in this document as the Agent Spawn extension. It is encoded exactly as the Agent Template extension of : a DER OCTET STRING containing the UTF-8 JCS serialization of a JSON object, subject to the same rules on criticality, duplicate members, duplicate extensions, size limits, and parse ordering. Agent Spawn Extension Members

Member	Type	Content
parent_agent_id	string	The parent's identifier, in the form required by
spawned_at	string	The instant of issuance, per , in UTC
spawn_nonce	string	The nonce of the spawn request, per
grant_id	string	The GrantID of the grant under which the spawn was authorized (); REQUIRED when the child template is owned by an organization other than the spawning agent's, MUST be absent otherwise

parent_agent_id, spawned_at and spawn_nonce are REQUIRED when the extension is present; grant_id is present exactly when the spawn was cross-organizational, and a relying party MUST refuse a certificate that carries it for a child owned by the parent's own organization or omits it for one that is not. A certificate for an agent that has a parent MUST carry the extension; a certificate for an agent that has none -- a root orchestrator -- MUST NOT. A relying party validating a chain MUST refuse a certificate whose parent_agent_id names no agent in the chain, MUST refuse one whose parent_agent_id differs from the parent the chain document names for it, and MUST refuse a root whose certificate carries the extension. This is what makes a spawn chain cryptographically traceable rather than merely asserted. A parent identifier carried only in a chain document is an unsigned claim beside a signed certificate: a child could name any parent it liked, and the containment of would be evaluated against whichever parent it chose. Carrying the link in the certificate means the CA that issued the child attested to which agent spawned it, and that attestation is what the scope and spawn checks are evaluated against. The parent's Agent Template extension, not the child's Agent Spawn extension, is where the child's authority is bounded. The Agent Spawn extension says who the parent is; the parent's certificate says what the parent may delegate. The absence of the Agent Spawn extension asserts that no agent spawned this one; it does not exempt the certificate from anything. A root is legitimate for the same reason any agent certificate is: it was issued by the Template Registry CA from a template attested under , and it chains to that CA under . No party can declare itself a root, because no party other than the CA can issue a certificate that validates, and the CA issues only from attested templates. A relying party verifies a root exactly as it verifies any other agent certificate. spawned_at and spawn_nonce record the request the Registry accepted. The freshness window of applies to that request, at the Registry, at the time it is made. A relying party validating an issued certificate later MUST NOT apply the window to spawned_at: a certificate an hour old is as valid as one a second old, and its currency is governed by its validity period and its revocation state, not by when it was requested. A relying party MUST, however, refuse a chain in which two certificates carry the same spawn_nonce. That is a consistency check on the document, in the sense gives the term: what makes a nonce unique across every chain the Registry ever issues is that the Registry accepts each nonce once, under , and a relying party holding one chain cannot observe another. An implementation MUST NOT present the document-local check as the enforcement of uniqueness. grant_id is what makes enforceable. A grant can be revoked by its Grantor alone, and every certificate issued under it must then become untrusted; without a member naming the grant, nothing identifies those certificates. With it, the Registry that issued them can revoke them, and a relying party in either organization learns of it through the revocation state the certificate already points to.

Dynamic Policy Governance

Two-Lane Model Template certificate (static): WHO the agent is and WHO it can spawn. Changes require full re-certification. Dynamic policy (fast lane): WHAT the agent can do within the bounds of the template certificate. Changes require dual signature (). Dynamic policies MUST NOT exceed the bounds defined in the static template certificate.

Ownership Template ownership MUST be established at certificate signing time and embedded in the Owner and OrgID fields. Only the verified owner of the organization that signed the template MAY submit policy changes. Verified means holding the private key of the Owner certificate of , whose subject common name equals the template's Owner field; no other form of verification is defined by this document.

Dual Signature Requirement Every policy change MUST be signed by two independent parties:

1. Owner -- proves the right to change the policy.
2. Policy Authority -- proves the policy passed automated validation gates.

Neither signature alone is sufficient. Both MUST be present and valid for a policy to be accepted.

Dynamic Policy Document Structure A dynamic policy document MUST contain the following fields. This is the complete set; a document containing any other field MUST be refused, since an unrecognized field is either meaningless or an attempt to convey authority the profile does not define. Dynamic Policy Document Fields

Field	Type	Required	Description
Subject	string	REQUIRED	Identifier of the agent this policy governs; MUST match the Subject of the template certificate
Owner	string	REQUIRED	Submitting owner; MUST match Owner in the template certificate
OrgID	string	REQUIRED	Submitting organization; MUST match OrgID in the template certificate
Scopes	array of string	REQUIRED	Scopes granted by this policy; bounded by AllowedScopes
SpawnTargets	array of string	OPTIONAL	Spawn targets granted by this policy, each a template Subject in the form of ; bounded by CanSpawn. Absent means none are granted, and a spawn request is then refused at step 3 of
Version	integer	REQUIRED	Monotonically increasing integer, scoped to Subject
IssuedAt	string	REQUIRED	Timestamp of issuance, per
NotAfter	string	OPTIONAL	Expiry of this policy, per ; MUST NOT be later than the notAfter of the certificate the policy governs. Absent means equal to it

Version is scoped to the Subject, not global. A relying party MUST refuse a policy whose Version is not strictly greater than the Version of the policy currently in force for that Subject. A policy is never valid beyond the notAfter of the certificate it governs, whether or not NotAfter is present. NotAfter can only shorten that period. A relying party MUST treat an absent NotAfter as equal to the certificate's notAfter, MUST refuse a policy whose NotAfter is later than it, and MUST refuse a policy presented after either has passed.

Canonicalization Signatures and hashes defined by this document are computed over bytes, so the mapping from a policy document to those bytes MUST be deterministic and identical across implementations. Wherever this document requires a canonical form -- of a policy document, of any field subset thereof, or of an audit log entry -- that canonical form MUST be the JSON Canonicalization Scheme (JCS) serialization defined in . A single canonical form is specified for all of them deliberately: an implementation carrying two serializations will eventually apply the wrong one, and the resulting failure presents as a signature or integrity error with no indication that serialization was the cause. JCS is specified rather than described here because a bespoke serialization would require this document to define property ordering, string escaping, and number formatting correctly and completely, and any error in that definition surfaces to implementers as a signature failure that appears to be a cryptographic fault. Serializations that differ only in whitespace, key order, or the escaping of non-ASCII characters produce different bytes and therefore different signatures; implementers MUST NOT assume a language's default JSON encoder produces the canonical form, as most do not.

Signature and Hash Coverage Both signatures required by are computed over the preimage defined in : the canonical form () of body. Because makes its table the complete content of body, every field in that table is inside the preimage and none is excluded from either signature. This section and describe the same octets. In particular, Version MUST be inside the signed preimage. Version exists to prevent replay, and it cannot serve that purpose while it remains modifiable without invalidating a signature: an attacker holding no key can otherwise take a superseded but validly signed policy, increment its Version, and present it as current. Both signatures verify, the content hash matches, and the version reads as current. The same reasoning applies to Subject: a signature that does not bind the policy to the agent it governs permits a policy issued for one agent to be presented for another. The content hash is a member of the envelope of a dynamic policy document only. It is REQUIRED there, because step 4 of stores the policy and step 5 re-reads it, and a stored document wants an integrity value that is cheaper to check than two signatures; it MUST be absent from the envelope of a template or a grant, which are verified on presentation and whose signatures already cover the same octets. The content hash MUST be SHA-256, or a stronger digest, computed over the same canonical form and the same field set as the signatures. The hash field itself is stored alongside the policy document and MUST NOT be included in its own preimage. The content hash is a derived value: a relying party MUST recompute it from body and refuse the document on a mismatch, and MUST NOT use the envelope's content_hash as an input to any decision. A modified content_hash therefore causes a refusal and nothing else; it is not a value a signature needs to protect, because the signature already covers everything the hash summarizes. The signatures and the content hash are carried in the envelope of , outside the policy document they attest to. A relying party MUST refuse a policy document that carries any of them as a policy field: they are not in , and a value inside body would be inside its own preimage.

Policy Change Sequence

rejected, audit logged 2. Automated gate (policy engine): - scope within AllowedScopes? - spawn targets within CanSpawn? - no conflicts with active policies? ANY FAIL --> rejected 3. Dual signature applied: Owner signs, Policy Authority countersigns 4. Policy stored with dual signature, version, timestamp, and content hash 5. Relying party validates at runtime: - both signatures valid? - version current? (replay prevention) - hash matches? (tamper detection) - policy within template certificate bounds? ANY FAIL --> DENY, audit logged ]]>

Threat Coverage

Scenario	Single Sig Gap	Dual Sig Fix
Rogue Policy Authority	Pushes bad policy	Owner key missing
Rogue owner	Bypasses automated gates	PA won't countersign
Compromised owner key	Attacker modifies	Automated gates enforced
Compromised Policy Auth	Pushes bad policy	Owner key missing

The table above concerns the dual signature. The following concerns the encodings this document specifies, and the attack each one closes. Encoding Threat Coverage

Scenario	Without the encoding	With it
Replayed Owner signature	An Owner signature over anything other than the policy body verifies for every later policy on that agent; a rogue Policy Authority reuses it	Both signatures cover the same body (); a signature is specific to one policy
Replayed policy	A superseded but validly signed policy is presented as current	Version is inside the preimage and must exceed the version in force ()
Swapped template	A valid certificate is presented beside a template granting authority the CA never issued	Static fields live in the certificate (); there is no separate template to swap
Forged parent	A child names whichever parent gives it the widest scope; containment is evaluated against that parent	The parent link is in the child's certificate, attested by the CA ()
Mismatched identity	A chain names one agent and presents a certificate issued to another; both validate on their own terms	Every restatement must equal the subject CN ()
Silent parser disagreement	Two parsers keep different duplicates of a key and both report success	Duplicate detection is a parser requirement ()
Unlocatable revocation	Revocation must be consulted but the certificate does not say where	cRLDistributionPoints or OCSP is required ()
Spawn under a revoked grant	A grant is revoked and nothing identifies the certificates issued under it	grant_id in the Agent Spawn extension; the issuing Registry revokes them ()
Spawn the policy withdrew	A policy grants no spawn targets and the agent spawns everything its certificate's CanSpawn allows	SpawnTargets is a step of the spawn sequence ()

Template Versioning

Full Re-Verification Required A new template version MUST undergo full re-verification from scratch. Trust MUST NOT be inherited from a previous version. Rationale: inheriting trust from v1 would allow a compromised v1 certificate to bootstrap trust for v2. A new version keeps the template's Subject and receives a new certificate. The Registry MUST revoke the prior certificate when it issues the new one, so that one identity never has two valid certificates; a relying party that encounters two unrevoked certificates for one Subject MUST refuse both.

Versioning Principle Everything on the old template chain continues to work unchanged as long as the certificate is valid. New connections and functionality are opt-in -- only available after the new template chain is fully verified and explicitly adopted.

Non-Inheritance Rules The following MUST NOT be inherited from a previous version:

• Trust chain
• Cross-organizational grants
• CanSpawn list
• Dynamic policies

Template Lifecycle

ACTIVE:

Template is trusted. New spawns accepted.

DISABLED:

No new spawns. Existing agents run to TTL expiry. Reversible.

DELETED:

Certificate revoked, CRL updated, registry entry removed. Irreversible. Audit log preserved.

DISABLED is a Registry state, not a revocation. It is reported by the Registry in Check 2 of and is not carried in a CRL. Because only the Registry performs spawns, no other party needs to distinguish DISABLED from ACTIVE: a relying party validating an existing agent's certificate consults revocation state as usual, and an agent issued under a template that is later DISABLED remains valid until its TTL or its revocation. Disable SHOULD precede delete. Implementations SHOULD enforce a mandatory waiting period between DISABLED and DELETED.

Cross-Organizational Grant Re-Issuance Cross-organizational grants MUST be explicitly re-issued for each new template version. Grants MUST NOT automatically roll over on version upgrade.

Cross-Organizational Agent Interaction

Explicit Grant Requirement Cross-organizational agent spawning MUST be explicitly authorized by the resource-owning organization. No implicit trust exists between organizations.

Grant Structure A cross-organizational grant MUST contain exactly the following fields: Cross-Organizational Grant Fields

Field	Type	Description
GrantID	string	Identifier of this grant: a UUID in the form of , unique among the grants the Grantor has issued
Grantor	string	OrgID of the resource-owning organization
Grantee	string	OrgID of the requesting organization
Template	string	Subject of the template granted, in the form of
AllowedScopes	array of string	MUST be a subset of the template's AllowedScopes
IssuedAt	string	Instant of issuance, per , in UTC
TTL	integer	Grant validity period in seconds, counted from IssuedAt
MaxSpawns	integer	Maximum concurrent agents permitted under this grant

Wire names are given in . A grant is signed as specified in , by the grantor's Owner and Policy Authority; the signatures are envelope members and are not fields of the grant. A grant expires at IssuedAt plus TTL seconds. A relying party MUST refuse a grant whose expiry has passed, and MUST refuse one whose IssuedAt is later than its own clock by more than the freshness window of . A duration with no stated origin has no expiry two parties can agree on; IssuedAt is the origin. A cross-organizational spawn is evaluated and issued by the Grantor's Registry, which owns the template and the CA that issues against it. That Registry holds the count compared against MaxSpawns and MUST enforce it atomically with recording the spawn, exactly as requires of MaxChildren. The Grantee's organization performs no part of the issuance and cannot enforce the cap.

Trust Anchor Options

Federated CA:

Both organizations trust a shared root CA.

Explicit CA trust:

Org-B explicitly trusts Org-A's CA.

Third-party CA:

Both organizations use a public CA.

Which option applies is deployment policy. Under each, a relying party in the Grantee organization MUST hold a trust anchor for the Grantor's Template Registry CA and MUST validate the Grantor's Owner and Policy Authority certificates to it, as requires, before accepting a grant's signatures. A grant whose signatures cannot be validated to a trust anchor the relying party holds MUST be refused.

Unilateral Revocation The granting organization MAY revoke a cross-organizational grant without the cooperation of the receiving organization. Upon revocation, all agents spawned under the affected grant MUST be treated as untrusted on next validation. The Grantor's Registry issued every such certificate, and each carries the grant's GrantID in its Agent Spawn extension (). On revoking a grant the Registry MUST revoke, under , every unexpired certificate whose grant_id names it, and MUST refuse further spawn requests under it. A relying party in either organization then learns of the revocation through the revocation state the certificate itself points to (), and needs no channel to the Grantor beyond that.

Federated Audit Each organization MUST maintain its own independent audit trail. Audit records MUST NOT depend on the other organization's systems.

Revocation

Template Revocation Template revocation MUST be performed by recording the template certificate as revoked in the CA's revocation state -- an X.509 CRL, an OCSP responder, or an equivalent revocation registry consulted on every validation. All agent certificates derived from a revoked template MUST be treated as untrusted on the next revocation check.

Individual Agent Revocation Individual agents MAY be revoked by explicit certificate revocation or, outside this document, by removal of authorization relationships at the resource layer.

Automation Requirement Routine revocation (TTL expiry, task completion) MUST be fully automated. Human involvement SHOULD be reserved for incident response and high-impact decisions.

Locating Revocation State Every certificate issued under this specification, other than a self-signed trust anchor, MUST carry either the cRLDistributionPoints extension or the authorityInfoAccess extension with an id-ad-ocsp accessMethod, both as defined in . A relying party MUST refuse a certificate carrying neither, because the obligation in to consult revocation state on every validation cannot be discharged against a certificate that does not say where that state lives. A relying party MUST NOT treat an unreachable revocation source as an absence of revocation. This restates and is stated again here because it is the requirement implementations most often relax under operational pressure.

Failure Model

Fail Closed Any verification step that cannot be completed MUST result in DENY. This includes:

• CA unreachable
• Registry unreachable
• CRL unreachable
• Certificate expired or revoked
• Policy store unreachable, or no policy in force
• Scope escalation attempt
• Policy invalid or unsigned
• Dual signature missing or invalid

Implementations MUST NOT provide a degraded mode that allows partial spawning or execution when verification infrastructure is unavailable.

Conformance Requirements

Field Placement Implementations MUST place every field in the location specified by this document: , , , , , and . Variable placement is not permitted.

CSR Validation Non-conforming CSRs MUST be rejected by the CA. A non-conforming template MUST NOT be signed.

Test Vectors Implementations MUST provide test vectors -- concrete examples of valid and invalid template chains -- for conformance validation.

Conformance Claims No conformance certification authority exists for this document. An implementation claiming conformance MUST state the revision it claims, as describes, and SHOULD publish the results of running the test vectors of against that revision. A claim without a stated revision is not a conformance claim.

Reference Implementation A reference implementation SHOULD be made available including:

• Template Registry CA
• Spawn chain validation
• SDK with certificate chain validation, registry lookup, and CRL check handling
• Template linter for pre-submission CSR validation

Known implementations are listed in .

IANA Considerations

Object Identifier The Agent Template extension of and the Agent Spawn extension of each use an object identifier under the joint-iso-itu-t UUID arc (2.25), which is self-assigning from a UUID and requires no registration. This document requests no allocation from any IANA-managed OID arc. Should this document be adopted, the author is willing to replace them with OIDs under an arc the responsible working group prefers.

Media Type Registration IANA is requested to register the following media type in the "Media Types" registry, per .

Type name:

application

Subtype name:

a2a-policy+json

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary; JSON is UTF-8 encoded and serialized per

Security considerations:

See of this document.

Interoperability considerations:

N/A

Published specification:

This document

Applications that use this media type:

Multi-agent systems exchanging dynamic policy documents.

Fragment identifier considerations:

N/A

Additional information:

N/A

Person and email address to contact for further information:

Tony Trujillo, founder@phalanxaisec.com

Intended usage:

COMMON

Restrictions on usage:

None

Author:

Tony Trujillo

Change controller:

IETF

Agent Scope Registry IANA is requested to create a registry titled "A2A Agent Scopes", with a registration policy of Specification Required . Each entry carries a scope name, a description, and a reference. The registry is initially empty; scope names not registered here are private to a deployment and MUST NOT be assumed to carry the same meaning across organizational boundaries.

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting, as described in . It is meant to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit." This section is to be removed before publishing as an RFC. Three independent implementations exist at the time of writing. Each states the revision it was written and verified against, and continues to state that revision until someone re-reads the newer text and re-runs the vectors. An implementation pinned to an earlier revision remains a correct implementation of that revision; a version string is a conformance claim rather than a label, and advancing one without re-verifying asserts conformance nobody has tested. Each is tagged in its repository at the commit implementing the revision named here. Known Implementations

Implementation	Revision	Notes
a2a-trust-playground	-03	Browser implementation, no installation or backend. Mints a Registry, attests and issues templates, and validates a chain against every check in this document, reporting the clause governing each refusal. Tagged impl/draft-03; the implementation of -02 remains retrievable at tag impl/draft-02. Source: https://github.com/tonyt68/a2a-trust-playground
ietf-a2a-trust-poc	-00	Registry CA, spawn validation and policy governance services. Tagged impl/draft-00. Source: https://github.com/tonyt68/ietf-a2a-trust-poc
hack-my-own-code	-00	Adversarial implementation that attacks its own conformance. Canonicalizes with a language-specific JSON serialization rather than the scheme required by , so it does not conform to that section. Tagged impl/draft-00. Source: https://github.com/tonyt68/hack-my-own-code

All three are maintained by the author of this document. They are independent in the sense that they share no code and were written against the specification text rather than against each other; they are not independent in the sense most values, and a reviewer should weigh them accordingly. An implementation by an unrelated party would be more informative than all three, and is actively sought.

Security Considerations

Scope Escalation Implementations MUST enforce at every hop that child agent scopes are a subset of parent scopes: child scopes are contained within parent scopes, and no scope may be introduced that the parent does not already hold. Failure to enforce this allows privilege escalation across the agent chain.

Replay Attacks A spawn request MUST carry a timestamp and a nonce, both generated by the spawning agent. The timestamp MUST be an instant in UTC. The nonce MUST be at least 128 bits of output from a cryptographically secure random number generator, encoded as base64 . The nonce and timestamp of an accepted request are recorded in the child's Agent Spawn extension (); those of every request, accepted or refused, are recorded in the audit log entry of . The Registry is the relying party for a spawn request. It MUST record the nonce when the request carrying it is received, before any step of is evaluated, and MUST refuse a later request carrying the same nonce whatever became of the first. A nonce is spent by being presented, not by being accepted: a request refused at any step has consumed its nonce, and a retry MUST carry a fresh one. Recording only accepted nonces would let a refused request be replayed until something changed and it was accepted, and a fresh nonce costs nothing to generate. A relying party MUST refuse a spawn request whose timestamp is more than 60 seconds from the relying party's own clock in either direction, and MUST refuse a request whose nonce it has already seen within that window. A relying party MUST retain seen nonces for at least twice the freshness window. Retaining them for exactly the window leaves a request replayable at the boundary, when the record has been discarded but the timestamp is still inside the window at the receiver. The window is specified rather than left to the deployment because a value chosen independently at each end is not a shared window, and the wider of the two is the one an attacker gets. Accepting a request from the future by the same margin accommodates clock skew; an implementation that accepts only past timestamps will reject legitimate requests from a peer whose clock is marginally ahead. The window assumes clocks synchronized to within a small fraction of it. An operator whose clocks cannot meet that assumption MUST treat it as a failure condition under rather than widen the window; a wider window is a longer replay opportunity for every party, not a fix for one party's clock. Sixty seconds tolerates the skew of any correctly administered clock -- NTP holds hosts within milliseconds -- and bounds the nonce retention obligation of a Registry to two minutes. It is deliberately tighter than the five minutes Kerberos adopted: that tolerance was sized for human-operated hosts with unsynchronized clocks, and a spawn request is a sub-second exchange between machines. A window sized for the former is a longer replay opportunity than the latter needs, and a peer whose clock is more than a minute wrong is not a peer to be accommodated.

Compromised Templates A compromised template certificate MUST be revoked immediately. A single CRL update invalidates all downstream agent certificates derived from that template.

Single Point of Compromise The dual signature requirement () ensures no single compromised party can push unauthorized policy changes. CA compromise requires full ecosystem re-issuance. Compromise of an Owner or Policy Authority key is handled by revoking its certificate under . Policies and templates signed under the compromised key MUST be re-signed under replacement keys, because a relying party cannot distinguish a signature made before the compromise from one made after it; a revoked signing certificate invalidates every signature it ever produced, not only the fraudulent ones.

Cross-Organizational Trust Cross-organizational grants MUST be explicitly issued. Implicit trust between organizations is prohibited.

PKI Does Not Enforce Authorization Because agent identity is carried in X.509 certificates and the chain is verified on every validation, it is natural to assume the certificate chain also constrains what an agent may do. It does not, and an implementation built on that assumption is unprotected while appearing rigorous. X.509 carries no representation of the scopes defined by this document. AllowedScopes, CanSpawn and MaxChildren are conveyed in the template, and no certificate path validation algorithm inspects them. A conformant X.509 validator presented with an agent certificate whose associated template claims scopes far beyond those its parent holds will report success, because the certificate is genuinely valid and correctly issued. The over-scoping is not a defect the validator is looking for. The nameConstraints extension does not close this gap. It constrains the namespace within which a CA may issue, not the authority a subject may claim once issued. Likewise certificatePolicies expresses which policies a chain supports, not whether a child exceeded its parent, and policy processing is disabled by default in common implementations. Consequently and are load-bearing implementation logic. They are not restatements of a property the certificate chain already guarantees, and an implementation that omits them because "the chain verifies" has no containment at all. Certificate validity establishes identity. Authorization is evaluated separately, every time.

Audit Integrity Audit logs MUST be tamper-evident. Logs MUST NOT be deletable by agents or orchestrators. Audit log infrastructure SHOULD be outside the control of the agent ecosystem itself. Each entry's hash MUST be computed as SHA-256, or a stronger digest, over the canonical form () of every member of other than entry_hash -- that is, including previous_hash and excluding the entry's own hash. As with policy documents, an unspecified preimage is not a detail: two implementations hashing different field sets each read the other's chain as broken, and a chain that cannot be verified across implementations provides no evidence to anyone but its author.

Privacy Considerations The Owner member of a template is carried inside a certificate that is presented to every relying party the agent ever contacts. An Owner value that identifies a person -- an email address, as the examples in this document use for readability -- is therefore personal data disclosed to every counterparty. Deployments SHOULD populate Owner with an identifier that is opaque outside the owning organization, and resolve it to a person only within that organization. A version 7 agent identifier discloses the agent's creation time to every party that sees the identifier, as describes. Audit records required by carry agent identifiers and scopes, and places one such record in each organization party to a cross-organizational spawn; the OrgID of each is disclosed to the other by the grant itself.

Algorithm Agility The signature algorithms of and the key strength floor of are classical. This document does not specify a post-quantum signature algorithm, because no X.509 profile for one had reached the stability this document requires at the time of writing. The per-key-type mapping is the extension point: a future revision adds a row for a post-quantum key type without changing the envelope or any other structure, and a relying party that does not recognize a key type refuses the signature, which is the fail-closed outcome requires.

Parsing Untrusted Input Every document this specification defines reaches a relying party from the party whose authority it describes, and is attacker-controlled input until a signature over it has been verified. states this for the two certificate extensions; it applies equally to a signature envelope, a chain document, and a grant. Three rules of this document exist for that reason and are restated here so that they are read as one defence. The shape rules of -- flat objects, no duplicate members, exact wire names, a fixed member set -- mean a conforming parser accepts only the shapes this document defines and has nothing else to be confused by. The size limits of bound what a parser is asked to read. And the ordering that section requires -- for a certificate, verify the issuer's signature before decoding an extension; for an envelope, verify the signatures over the body octets before acting on any member of body -- means input nobody signed is discarded before it is interpreted. A relying party that parses first and verifies afterwards has exposed its parser to every party able to present a certificate, which is every party.

References Normative References Informative References SPIFFE Project OpenFGA Project HashiCorp

Changes since draft-tonyai-a2a-trust-02 As with the previous revision, every change here was surfaced by implementing the -02 text rather than by re-reading it. Three implementations of one specification produced three different answers to the same questions, which is what the changes below exist to prevent.

• Specified how documents are encoded on the wire (). Field tables throughout -02 gave display names only, so implementations invented their own member names and produced signatures no other implementation could reproduce.
• Specified the signature envelope (). -02 required two signatures but never said where they live, how they are encoded, or that they are excluded from the body they sign. It also declared that a policy document carrying any undefined field must be refused, which forbade the signature fields the same document requires.
• Specified the encoding of the static template fields (). -02 listed which fields a template carries but never said where in the certificate they live, so two implementations conforming to the text could not validate each other's certificates.
• Specified the binding between an agent's identity and its certificate (), and required every restatement of an agent identifier to agree with the certificate subject. -02 carried the identifier in three places and required no agreement among them, so a chain naming one agent while presenting a certificate issued to another validated cleanly.
• Specified the form of an agent identifier (). -02 did not mention UUIDs at all, while one implementation refused anything that was not a lowercase version 4; an implementation reading only the text could have used any string and been conformant.
• Specified how a template is authored and attested before issuance (). -02 described what a template contains and how an issued certificate is validated, but not how a template comes to exist, so the conformance gate and dual attestation that existing implementations perform were unspecified.
• Specified the nonce and freshness window for replay prevention (). -02 required "a timestamp and nonce" and a "defined freshness window" without defining either, which a conforming implementation could satisfy with an eight-bit nonce and a window of a day.
• Required certificates to say where their revocation state lives (). -02 required revocation to be consulted on every validation without requiring any means of finding it.
• Specified the encoding of spawn provenance (). -02 issued a child certificate "with parent identity embedded" and a nonce, and gave neither a location. The link from child to parent lived in an unsigned chain document, so the provenance the Introduction calls cryptographically traceable was asserted rather than attested.
• Corrected the certificate chain figure (), which showed an agent certificate issuing a child certificate -- forbidden by -- and non-UUID subjects, forbidden by .
• Typed the cross-organizational grant fields () and removed the row that listed a signature as a field of the grant; signatures are envelope members. Bounded a policy's NotAfter by the certificate's notAfter rather than by a duration it could not be compared against.
• Stated who holds the count that MaxChildren is compared against (). -02 required the comparison and named no party to perform it, so a distributed deployment had no defined owner of the state and two concurrent spawns could both succeed. The Registry enforces the cap atomically; a relying party's document-local count is a consistency check.
• Made duplicate-member detection a requirement on the parser (), not only a property of the document. A stock JSON parser silently keeps one of two duplicates and reports success, which satisfied the -02 wording while defeating its purpose.
• Defined scope syntax and set semantics (). -02 required byte comparison of wire names and said nothing about scope values, so whether Read:Data equalled read:data, whether array order mattered, and whether an empty request satisfied the subset test were all implementation-defined.
• Named the party that performs the spawn sequence and issues the child certificate (). -02 stated the issuance in the passive voice, and the only party a reader would guess is the one forbids.
• Defined the value space of PermittedOperations and tied spawn to the right to spawn (, ). -02 required the field, typed it, showed values in examples, and assigned no meaning to any of them.
• Stated what makes a root legitimate (), gave an absent NotAfter a meaning (), gave a grant an issuance instant so its TTL has an origin (), and bound a certificate's validity period to its ttl_seconds () so that the TTL is enforced by path validation. Clarified that the bounds check of is independent of signature validity but not prior to it.
• Added threat coverage for the encodings this revision specifies (), stated the rationale for the freshness window (), clarified that the window governs the request and not later validation (), and stated that what a scope grants access to is outside this document ().
• Specified the signature algorithm per signer key type (): RSASSA-PSS or ECDSA with a fixed-width value, and no algorithm identifier in the envelope. -02 said "raw signature value" and "SHA-256 or stronger" with no way to signal which, so two implementations could not verify each other's signatures.
• Specified how a relying party trusts the Owner and Policy Authority keys (, ) and bound the Owner field to the Owner certificate's subject. -02 required the signatures and said nothing about the keys.
• Defined Relying Party, Owner, and Root Orchestrator, stated that a template defines exactly one agent, and stated that the Registry and its CA are one logical entity (). Stated that a new template version keeps its Subject and revokes the prior certificate (), that DISABLED is a Registry state reported in Check 2 rather than a CRL entry (), and which organizations may own a child template under Check 2 ().
• Replaced the conformance certification requirement, which named no certifying body, with a conformance claim (). Added Privacy Considerations and Algorithm Agility, and the handling of a compromised Owner or Policy Authority key. Adopted the BCP 14 boilerplate of and moved the document to the IETF stream and the Security Area.
• Hardened the profile with no allowance for prior implementations, which are retained under tags. Both certificate extensions are now critical (), so a validator that does not implement this document refuses the certificate instead of treating it as an ordinary client certificate. The key strength floor rose to 128 bits, RSA-2048 is refused, EC and Ed25519 are recommended, keyUsage is restricted to digitalSignature, and serial numbers require 64 bits of entropy (). Ed25519 joined the signature algorithms. The two-roles-one-key rule now compares keys rather than signature octets, which a randomized scheme made necessary (). Certificate lifetime is capped at seven days (). Timestamps require the Z designator and the JSON objects are declared flat (). The Grantor's Registry was named as the enforcer of MaxSpawns ().
• Replaced the IANA Considerations section, which previously declared no actions. Specifying the dynamic policy as a standalone JSON document made a media type necessary, and defining scope syntax made a scope registry possible.
• Promoted the implementation table to a top-level Implementation Status section per .
• Made the dynamic policy govern spawning (, ). The policy document carried a SpawnTargets member that no check consulted, so a policy granting no spawn targets left an agent able to spawn everything its certificate's CanSpawn allowed. The spawn sequence now has a policy step, and each of its steps is assigned to one of the two checks so that an implementer reading the rule alone builds all of them.
• Stated who generates the spawn nonce and when it is spent (, ). The text had the agent supplying the nonce in one place and the Registry issuing it in another. The agent generates it; the Registry records it on receipt, whether or not the request is then refused; and the document-local uniqueness check is a consistency check rather than the enforcement of uniqueness, which a relying party holding one chain cannot perform.
• Bounded MaxChildren by the size of CanSpawn () and required the Registry to refuse a second live certificate for one child template (). A template defines one agent, so a cap above the number of named children was a cap on nothing, and the example in showed exactly that.
• Removed Issuer from the static field table (). It was REQUIRED there and declared to have no member in the extension two sections later, so the conformance gate demanded a value that could never be supplied.
• Tied an issued certificate to the grant that authorized it: a grant carries a GrantID (), a cross-organizational spawn records it in the Agent Spawn extension (), and revoking the grant revokes those certificates (). The requirement that agents spawned under a revoked grant be treated as untrusted recorded nothing that identified them.
• Gave the audit log entry a member table (), the extension size limit a value (), the policy document table a type column (), the content hash a stated scope (), string equality one rule (), and the serial number its DER encoding (). Redrew the CSR flow () to show the dual attestation that requires, added , listed every field-bearing section in , and moved OAuth 2.0 and Token Exchange to the informative references, since neither is needed to implement anything here.

Changes since draft-tonyai-a2a-trust-01 Section numbers in this appendix are those of draft-tonyai-a2a-trust-02, the revision these changes produced. Several sections were renumbered in -03; see . All changes in this revision were surfaced by building a second, independent implementation of the -01 text and attacking it. Changes are described below by their effect on a conformant implementation rather than by intent: where an implementation conforming to -01 must change to remain conformant, this is stated plainly, because an implementer reading this appendix is deciding whether re-verification is required. Four changes below are breaking. Two implementations exist at the time of writing, both under the author's control; the cost of these changes is at its minimum now and rises permanently once a third-party implementation ships. Security fix -- breaking.

• Section 9.6 (Signature and Hash Coverage) is new, and requires that Version and Subject be inside the signed preimage. In -01 the policy version was listed in Section 9.4 as a value stored alongside the signature, and the text never required the signature to cover it. Both existing implementations read it that way and neither signed the version, which defeats the replay prevention that Section 9.4 assigns to that field: an attacker holding no key can take a superseded but validly signed policy, increment the version, and have it accepted -- both signatures verify, the content hash matches, and the version reads as current. Implementations MUST re-sign existing policies under the new coverage. Signatures produced under -01 do not verify under -02.

Interoperability -- breaking.

• Section 9.5 (Canonicalization) is new, and normatively specifies JCS (RFC 8785) as the serialization for all signatures and hashes. -01 contained no canonicalization text of any kind, which made Section 9.3 impossible to implement interoperably: a signature is over bytes, and nothing in -01 said how those bytes are produced. The only way to implement -01's dual signature was to read an existing implementation's source. JCS differs from what both current implementations do, so both must change and all existing signatures and test vectors are invalidated. An existing implementation is not conformant to -02 by default.
• Section 9.4 (Dynamic Policy Document Structure) is new. -01 required the dynamic policy to be signed, hashed, stored and integrity-checked without ever defining what it contains, leaving each implementer to invent a field set. Different invented sets produce different signatures and different hashes for the same policy, and each implementation reads the other's documents as tampered with. Implementations whose field set differs from the table in Section 9.4 must change.

New normative requirements -- additive.

• Section 6.3 (Certificate Profile) is new. -01 mandated X.509 and specified no profile: no key strength, no digest floor, and no basicConstraints requirement. Three certificates that verify under a conformant X.509 validator were accepted as agent identities by an implementation conforming to -01 -- one asserting cA = TRUE, one signed with SHA-1, and one carrying no basicConstraints at all. The first is also a containment failure: an agent whose certificate permits it to issue certificates can create children without presenting a request to the CA, which removes both checks in Section 8.1 from the spawn path without invalidating any signature. Implementations already issuing cA = FALSE, SHA-256, RSA-2048 leaves satisfy this section unchanged, but MUST add the corresponding checks on validation.
• Section 7.2 now states who enforces the dynamic policy bounds, when, and with what result. -01 stated the rule and named no enforcement point, so an implementation that never checked it and one that checked it before signature verification both read as conformant while returning different results for the same document. The bounds MUST now be evaluated independently of signature validity and refused before the policy is applied.

Rename -- breaking.

• The Section 7.1 static field KeyUsage is renamed PermittedOperations. The field carries the operations an agent may perform -- spawn, delegate, read -- and is unrelated to the X.509 keyUsage extension, whose values are digitalSignature, keyCertSign and the rest of the RFC 5280 set. The collision was latent while this document never referred to the X.509 extension; Section 6.3 now does, normatively, so a single document used one name for two unrelated things. RFC 5280 owns the name keyUsage, so the template field is the one that moves. The new name is the description this document already gave the field. Implementations MUST rename the corresponding metadata field; the value space is unchanged.

Removal -- breaking for any implementation reading the field.

• The ScopeInherit field is removed from the Section 7.1 static field table. It was REQUIRED in -00 and -01 with no defined value space, and the value both existing implementations populate it with, "strict-subset", contradicts Section 8.3 as clarified in -01, which explicitly permits equality. Neither implementation reads the value, so the field conveyed no capability; Section 8.3 already determines inheritance completely. An implementation that enforced the field literally would deny a child legitimately holding its parent's full scope set, which is the misreading -01 was published to prevent.

Non-normative.

• Section 16.7 (PKI Does Not Enforce Authorization) is new. It states that certificate validity establishes identity and not authorization, that neither nameConstraints nor certificatePolicies closes that gap, and that Sections 7.2 and 8.3 are therefore load-bearing implementation logic rather than restatements of a guarantee the chain already provides. No behaviour changes; the omission was judged the most likely to cause an implementer to build something that verifies correctly and contains nothing.

Changes since draft-tonyai-a2a-trust-00 Section numbers in this appendix are those of draft-tonyai-a2a-trust-01, the revision these changes produced. Clarified two areas identified as ambiguous during development of a reference implementation:

• Section 8.3/16.1 scope-subset language now explicitly permits equality between a child's requested scope and its parent's granted scope; only escalation (a superset) is prohibited. The prior wording could be misread as requiring a strict/proper subset, which would wrongly deny a child that legitimately needs the same scope as its parent.
• Section 12.1 revocation-check language now explicitly accepts an X.509 CRL, an OCSP responder, or an equivalent revocation registry, rather than implying a CRL specifically. The normative requirement is that revocation state is consulted on every validation, not the specific mechanism used to represent it.

Neither change alters the normative requirements themselves; both make explicit what the -00 text intended. Both were surfaced by building and red-teaming a conformance reference implementation against the -00 text.