AID-1: A Cryptographically Bindable Identity and Provenance Architecture for AI Systems

Introduction AI systems increasingly participate in software development, content production, scientific workflows, operational control, and autonomous or semi-autonomous execution. Existing identifiers such as model names, deployment IDs, API credentials, or embedded public keys do not by themselves establish trusted identity, delegated authority, execution context, or provenance. AID-1 defines a compositional verification architecture in which a cryptographic signature is only one element of a larger trust chain. The architecture is intentionally provider-independent and does not require any specific hardware root of trust. The core doctrine is: A conforming implementation MUST preserve this separation.

Conventions and Terminology 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 and when, and only when, they appear in all capitals, as shown here.

Actor: An identity, human or machine, that is represented as performing or requesting an action.
Trusted Key Registry: An external trust source that resolves a key identifier to key material and binding status.
Delegation: A signed grant permitting one subject to exercise specified capabilities on behalf of another subject.
Authorization: A policy decision determining whether an operation is permitted for a subject, resource, audience, and time.
Attestation: Independently verifiable evidence about an execution environment, workflow, or identity assertion.
Provenance: Evidence describing the origin, transformation, integrity, or lineage of an artifact or action.

Design Principles AID-1 implementations MUST preserve the following non-equivalences: Successful verification in one trust domain MUST NOT be treated as implicit success in another trust domain.

Trust Domains

Identity The identity domain answers "Who is the actor?" An implementation MUST NOT treat self-asserted identity metadata as sufficient trusted identity evidence unless policy explicitly allows that trust model.

Key Binding The key-binding domain answers "Which trusted key represents the actor?" A public key supplied inside the artifact being verified MUST NOT be treated as its own trust anchor.

Delegation The delegation domain answers "May this delegate act for the issuer?" Delegation MUST be represented and validated independently from the underlying signature.

Authorization The authorization domain answers "May this actor perform this operation on this resource now?" Authorization SHOULD bind at least the operation, resource, subject, audience, time, delegation state, and revocation state.

Action Evidence Action evidence identifies what was requested or performed, including content-addressed inputs, outputs, commit identifiers, environment identifiers, and other execution-relevant context.

Execution Attestation Execution attestation answers "Where and under what trusted workflow was the action executed?" Claims copied into a signed payload remain signer assertions unless independently verified against the relevant attestation authority.

Governance Governance determines whether evidence is presently accepted under revocation, rotation, supersession, retention, and audit policy.

Core AID-1 Objects

Signed Envelope A signer MUST sign the JSON Canonicalization Scheme (JCS) representation of the envelope as specified in . Ed25519 is specified in . The signature operation is: The unsigned transport representation MAY include informational public key material, but a verifier MUST resolve keyId through an independent trusted source before treating the key as trusted.

Trusted Key Record If the required registry cannot be consulted, a verifier MUST NOT return ALLOW solely on the basis of an artifact-supplied key.

Delegation Credential

Authorization Decision

Typed Provenance Claims { value: T; source: ClaimSource; verified: boolean; evidenceRef?: string; verifier?: string; checkedAt?: string; } ]]> Implementations SHOULD distinguish self-asserted values from independently verified evidence.

Canonicalization and Hashing AID-1 signed JSON objects MUST use JCS as specified in prior to signing or signature verification. Implementations MUST reject non-JSON values before canonicalization. Rejected values include undefined values, NaN, infinities, Date instances, Map, Set, Buffer, typed arrays, class instances, accessors, and cyclic structures. Binary content SHOULD be represented using explicit encodings or, preferably, by content digests.

Temporal Validation Time values used for authority-bearing decisions MUST be unambiguous instants. Implementations SHOULD require canonical UTC timestamps. Unless policy specifies a bounded clock-skew allowance, the required relation is: Invalid or unparsable timestamps MUST NOT fail open.

Revocation and Key Status ; } ]]> For authority-bearing operations, a required revocation status of "unknown" MUST result in either DENY or INDETERMINATE according to policy. It MUST NOT result in ALLOW. Historical verification SHOULD distinguish evidence that was valid when issued and later revoked from evidence that had already been revoked at the claimed execution time.

Replay Protection Authority-bearing AID-1 envelopes MUST include a nonce, stable actionId, audience, and bounded validity period. Where policy requires single-use authorization, the verifier MUST reject a previously consumed nonce/action pair. Implementations SHOULD bind replay protection to the relevant repository, workflow, deployment, environment, or equivalent execution scope when such context exists.

External Attestation When GitHub OIDC or another external attestation mechanism is required, a verifier MUST validate the attestation against the appropriate issuer, expected audience, trusted workflow or workload identity policy, and any required repository, workflow reference, workflow SHA, commit SHA, triggering actor, environment, and subject constraints. Merely copying those values into an AID-1 signed object proves only that the signer asserted them. It does not independently verify the attestation.

Verification Algorithm A conforming verifier evaluating an authority-bearing AID-1 object MUST perform the following checks in an order that preserves the same security dependencies. An implementation MAY internally optimize checks, provided that no optimization can turn a required failed or unavailable prerequisite into ALLOW.

Parse input without coercion.
Validate the applicable wire schema.
Canonicalize the signed envelope.
Resolve keyId through an external trusted source.
Verify key status and identity binding.
Verify the Ed25519 signature.
Verify the payload digest.
Verify issuer and audience constraints.
Verify external attestation when required.
Verify the delegation chain and delegation depth.
Verify operation and resource authorization.
Verify temporal constraints and clock policy.
Verify revocation status.
Verify replay constraints.
Verify provenance and artifact hashes.
Return the final verification decision.

Decision Semantics

ALLOW: Every trust domain required by policy completed successfully.
DENY: At least one required domain definitively failed.
INDETERMINATE: No definitive failure has been established, but at least one required verification step could not be completed.

INDETERMINATE MUST NOT be interpreted as ALLOW. Examples include: an unavailable revocation registry, which SHOULD yield INDETERMINATE or DENY; an invalid signature, which MUST yield DENY; and a trusted key already revoked at the relevant time, which MUST yield DENY.

Failure Taxonomy Implementations SHOULD return structured per-domain verification status and MAY include additional implementation-specific warnings.

Wire Schemas AID-1 deployments SHOULD maintain versioned machine-readable schemas for at least the following object families: Schema validation is structural. Cross-object trust and policy constraints MUST be enforced by conformance logic and not assumed from schema validity alone.

Explicit Downstream Admissibility Boundary AID-1 verifies identity, authority-related evidence, and provenance according to the policy applied by an AID-1 verifier. It does not determine scientific truth or downstream scientific admissibility. The following conformance boundary is normative and is referred to as replay case R5 by the companion AID-1 conformance specification: An AID-1 implementation MUST NOT infer downstream scientific admissibility solely from successful AID-1 verification. A downstream admissibility system MUST remain free to reject evidence that is structurally and cryptographically valid under AID-1.

Operational State and Authorization Operational state MAY constrain authorization, but state alone MUST NOT be treated as a complete permission decision. A reference state matrix is: Reference State Matrix

State	Effect
SAFE	Policy-dependent.
QUIESCING	No new work or delegation; restricted modification; evidence reads allowed by policy.
ISOLATED	No execute, delegate, modify, or publish; restricted evidence access.
FORENSIC	No action; evidence access limited to authorized investigators.
DENY_NEW	No new work, delegations, or changes; evidence access policy-dependent.
REVOKED	No action; audit-only access.

Security Considerations The principal security risk addressed by AID-1 is trust-domain collapse: treating one valid signal, especially a cryptographic signature, as sufficient proof of identity, authority, execution environment, provenance, or semantic correctness. Implementations MUST defend against key substitution, confused-deputy attacks, audience confusion, cross-resource replay, delegation escalation, stale credentials, forged attestations, invalid temporal data, unavailable revocation infrastructure, and artifact mutation. Implementations SHOULD use constant-time comparison primitives for security-sensitive digest comparisons where applicable. Audit systems SHOULD be append-only or cryptographically chained so that deletion, reordering, and mutation can be detected.

Privacy Considerations AID-1 may carry identifiers, repository information, workflow context, public keys, delegation relationships, execution metadata, and provenance links. These can enable correlation across systems. Implementations SHOULD minimize collected identity and network context, SHOULD avoid embedding unnecessary personal information, SHOULD apply data-retention limits, and SHOULD separate public provenance evidence from sensitive operational metadata. Pseudonymous identifiers MAY be used when policy does not require disclosure of a civil identity, provided that trusted binding and revocation requirements remain enforceable.

IANA Considerations This document requests no IANA actions at this time. Future revisions may define registries for AID-1 algorithms, claim sources, failure codes, schema identifiers, or attestation types if interoperability experience demonstrates that shared registries are required.

Conformance Implementations claiming AID-1 conformance MUST preserve the trust-domain boundaries, decision semantics, external key-resolution rule, fail-closed or indeterminate handling of unavailable required trust services, and the downstream admissibility boundary defined in this document. Provider-independent conformance vectors and the reference execution model are defined in the companion document "AID-1 Provider-Independent Conformance Requirements".

Implementation Independence AID-1 does not mandate TPM, TEE, HSM, secure enclave, or software-only key storage. Implementations MAY use such technologies, but provider conformance is determined by externally observable AID-1 behavior rather than implementation mechanism.

Acknowledgements This document reflects an architecture developed to keep identity, authority, action evidence, attestation, provenance, governance, and downstream admissibility as independently testable trust domains.