AID-1: A Cryptographically Bindable Identity and Provenance Architecture for AI Systems
draft-watts-ai-identity-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Deonté Watts | ||
| Last updated | 2026-10-11 (Latest revision 2026-10-10) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Additional academic profile
Author GitHub account: DeontewattsV1 Author ORCID Author research profile Research archive profile Research bibliography profile Research discovery profile Research standards and metadata profile |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-watts-ai-identity-00
Internet Engineering Task Force D. Watts
Internet-Draft Independent Researcher
Intended status: Informational 9 October 2026
Expires: 12 April 2027
AID-1: A Cryptographically Bindable Identity and Provenance Architecture
for AI Systems
draft-watts-ai-identity-00
Abstract
This document specifies AID-1, a provider-independent architecture
for representing and verifying cryptographically bindable identity,
delegation, authorization, action evidence, execution attestation,
provenance, and governance information associated with AI systems and
AI-mediated actions. AID-1 intentionally separates signature
validity, identity binding, authority, execution evidence,
provenance, and downstream admissibility. The specification defines
trust domains, signed envelopes, external key resolution, delegation
credentials, authorization decisions, temporal and revocation checks,
replay protection, typed provenance claims, and a deterministic
verification order with ALLOW, DENY, and INDETERMINATE outcomes.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Watts Expires 12 April 2027 [Page 1]
Internet-Draft AID-1 October 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
4. Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Key Binding . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Delegation . . . . . . . . . . . . . . . . . . . . . . . 4
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 4
4.5. Action Evidence . . . . . . . . . . . . . . . . . . . . . 4
4.6. Execution Attestation . . . . . . . . . . . . . . . . . . 5
4.7. Governance . . . . . . . . . . . . . . . . . . . . . . . 5
5. Core AID-1 Objects . . . . . . . . . . . . . . . . . . . . . 5
5.1. Signed Envelope . . . . . . . . . . . . . . . . . . . . . 5
5.2. Trusted Key Record . . . . . . . . . . . . . . . . . . . 6
5.3. Delegation Credential . . . . . . . . . . . . . . . . . . 6
5.4. Authorization Decision . . . . . . . . . . . . . . . . . 6
5.5. Typed Provenance Claims . . . . . . . . . . . . . . . . . 7
6. Canonicalization and Hashing . . . . . . . . . . . . . . . . 7
7. Temporal Validation . . . . . . . . . . . . . . . . . . . . . 8
8. Revocation and Key Status . . . . . . . . . . . . . . . . . . 8
9. Replay Protection . . . . . . . . . . . . . . . . . . . . . . 9
10. External Attestation . . . . . . . . . . . . . . . . . . . . 9
11. Verification Algorithm . . . . . . . . . . . . . . . . . . . 9
12. Decision Semantics . . . . . . . . . . . . . . . . . . . . . 10
13. Failure Taxonomy . . . . . . . . . . . . . . . . . . . . . . 10
14. Wire Schemas . . . . . . . . . . . . . . . . . . . . . . . . 11
15. Explicit Downstream Admissibility Boundary . . . . . . . . . 11
16. Operational State and Authorization . . . . . . . . . . . . . 12
17. Security Considerations . . . . . . . . . . . . . . . . . . . 12
18. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
20. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 13
21. Implementation Independence . . . . . . . . . . . . . . . . . 14
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
23. Normative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
Watts Expires 12 April 2027 [Page 2]
Internet-Draft AID-1 October 2026
1. 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:
Identity != Authority != Action Evidence
A conforming implementation MUST preserve this separation.
2. 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 [RFC2119] and [RFC8174] 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.
Watts Expires 12 April 2027 [Page 3]
Internet-Draft AID-1 October 2026
3. Design Principles
AID-1 implementations MUST preserve the following non-equivalences:
Signature validity != identity proof
Identity proof != delegation
Delegation != authorization
Authorization != execution attestation
Execution attestation != artifact truth
Artifact integrity != semantic correctness
Successful verification in one trust domain MUST NOT be treated as
implicit success in another trust domain.
4. Trust Domains
4.1. 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.
4.2. 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.
4.3. Delegation
The delegation domain answers "May this delegate act for the issuer?"
Delegation MUST be represented and validated independently from the
underlying signature.
4.4. 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.
4.5. Action Evidence
Action evidence identifies what was requested or performed, including
content-addressed inputs, outputs, commit identifiers, environment
identifiers, and other execution-relevant context.
Watts Expires 12 April 2027 [Page 4]
Internet-Draft AID-1 October 2026
4.6. 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.
4.7. Governance
Governance determines whether evidence is presently accepted under
revocation, rotation, supersession, retention, and audit policy.
5. Core AID-1 Objects
5.1. Signed Envelope
export interface SignedEnvelopeV1 {
schema: "miseos.signed-envelope/v1";
algorithm: "Ed25519";
keyId: string;
payloadDigest: {
algorithm: "sha256";
value: string;
};
issuedAt: string;
expiresAt?: string;
nonce: string;
audience: string;
actionId: string;
authorizationId: string;
delegationId?: string;
}
export interface DetachedSignatureV1 {
envelope: SignedEnvelopeV1;
signature: string;
}
A signer MUST sign the JSON Canonicalization Scheme (JCS)
representation of the envelope as specified in [RFC8785]. Ed25519 is
specified in [RFC8032]. The signature operation is:
Ed25519.Sign(sk, JCS(envelope))
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.
Watts Expires 12 April 2027 [Page 5]
Internet-Draft AID-1 October 2026
5.2. Trusted Key Record
export interface TrustedKeyRecord {
keyId: string;
subjectId: string;
publicKeyPem: string;
fingerprintSha256: string;
status: "active" | "rotated" | "revoked" | "suspended";
validFrom: string;
validUntil?: string;
bindingMethod:
| "github-oidc"
| "github-ssh"
| "github-gpg"
| "organization-registry"
| "manual-root-verification";
}
If the required registry cannot be consulted, a verifier MUST NOT
return ALLOW solely on the basis of an artifact-supplied key.
5.3. Delegation Credential
export interface DelegationCredentialV1 {
schema: "miseos.delegation/v1";
delegationId: string;
issuerSubjectId: string;
delegateSubjectId: string;
capabilities: string[];
resourcePatterns: string[];
notBefore: string;
expiresAt: string;
revocationId: string;
audience: string;
maxDelegationDepth: number;
}
5.4. Authorization Decision
Watts Expires 12 April 2027 [Page 6]
Internet-Draft AID-1 October 2026
export type Operation =
| "execute"
| "delegate"
| "modify"
| "publish"
| "read-evidence"
| "create-credential";
export interface AuthorizationDecision {
effect: "allow" | "deny" | "indeterminate";
operation: Operation;
reasons: string[];
evaluatedAt: string;
}
5.5. Typed Provenance Claims
export type ClaimSource =
| "signed-by-key"
| "github-oidc"
| "git-object"
| "artifact-digest"
| "external-attestation"
| "self-asserted";
interface ProvenanceClaim<T> {
value: T;
source: ClaimSource;
verified: boolean;
evidenceRef?: string;
verifier?: string;
checkedAt?: string;
}
Implementations SHOULD distinguish self-asserted values from
independently verified evidence.
6. Canonicalization and Hashing
AID-1 signed JSON objects MUST use JCS as specified in [RFC8785]
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.
Watts Expires 12 April 2027 [Page 7]
Internet-Draft AID-1 October 2026
Binary content SHOULD be represented using explicit encodings or,
preferably, by content digests.
export function hashChain(values: JsonValue[]): string {
return sha256Jcs({
schema: "miseos.hash-sequence/v1",
values,
});
}
7. Temporal Validation
Time values used for authority-bearing decisions MUST be unambiguous
instants. Implementations SHOULD require canonical UTC timestamps.
export function parseInstant(value: string): Date | null {
const date = new Date(value);
if (
!Number.isFinite(date.getTime()) ||
date.toISOString() !== value
) {
return null;
}
return date;
}
Unless policy specifies a bounded clock-skew allowance, the required
relation is:
notBefore <= issuedAt <= verificationTime <= expiresAt
Invalid or unparsable timestamps MUST NOT fail open.
8. Revocation and Key Status
export interface RevocationRegistry {
getStatus(
revocationId: string,
at: string,
): Promise<"valid" | "revoked" | "unknown">;
}
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.
Watts Expires 12 April 2027 [Page 8]
Internet-Draft AID-1 October 2026
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.
9. 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.
10. 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.
11. 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.
1. Parse input without coercion.
2. Validate the applicable wire schema.
3. Canonicalize the signed envelope.
4. Resolve keyId through an external trusted source.
5. Verify key status and identity binding.
6. Verify the Ed25519 signature.
Watts Expires 12 April 2027 [Page 9]
Internet-Draft AID-1 October 2026
7. Verify the payload digest.
8. Verify issuer and audience constraints.
9. Verify external attestation when required.
10. Verify the delegation chain and delegation depth.
11. Verify operation and resource authorization.
12. Verify temporal constraints and clock policy.
13. Verify revocation status.
14. Verify replay constraints.
15. Verify provenance and artifact hashes.
16. Return the final verification decision.
12. 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.
13. Failure Taxonomy
Watts Expires 12 April 2027 [Page 10]
Internet-Draft AID-1 October 2026
export type VerificationFailureCode =
| "IDENTITY_BINDING_UNVERIFIED"
| "KEY_NOT_TRUSTED"
| "KEY_REVOKED"
| "KEY_SUSPENDED"
| "SIGNATURE_INVALID"
| "DELEGATION_MISSING"
| "DELEGATION_INVALID"
| "DELEGATION_EXPIRED"
| "DELEGATION_DEPTH_EXCEEDED"
| "AUTHORIZATION_DENIED"
| "TEMPORAL_INVALID"
| "REVOCATION_UNKNOWN"
| "REPLAY_DETECTED"
| "AUDIENCE_MISMATCH"
| "ATTESTATION_UNVERIFIED"
| "PROVENANCE_MISMATCH"
| "SCHEMA_INVALID"
| "DIGEST_MISMATCH";
Implementations SHOULD return structured per-domain verification
status and MAY include additional implementation-specific warnings.
14. Wire Schemas
AID-1 deployments SHOULD maintain versioned machine-readable schemas
for at least the following object families:
schemas/
developer-identity.v1.schema.json
trusted-key-record.v1.schema.json
signature-envelope.v1.schema.json
delegation-credential.v1.schema.json
authorization-snapshot.v1.schema.json
provenance.v1.schema.json
revocation-event.v1.schema.json
Schema validation is structural. Cross-object trust and policy
constraints MUST be enforced by conformance logic and not assumed
from schema validity alone.
15. 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.
Watts Expires 12 April 2027 [Page 11]
Internet-Draft AID-1 October 2026
The following conformance boundary is normative and is referred to as
replay case R5 by the companion AID-1 conformance specification:
R5
AID-1 verification: VALID
Downstream D6 admissibility: REJECT
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.
16. 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:
+===========+=================================================+
| 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. |
+-----------+-------------------------------------------------+
Table 1: Reference State Matrix
17. 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.
Watts Expires 12 April 2027 [Page 12]
Internet-Draft AID-1 October 2026
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.
18. 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.
19. 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.
20. 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".
Watts Expires 12 April 2027 [Page 13]
Internet-Draft AID-1 October 2026
21. 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.
22. Acknowledgements
This document reflects an architecture developed to keep identity,
authority, action evidence, attestation, provenance, governance, and
downstream admissibility as independently testable trust domains.
23. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, BCP 14, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
Author's Address
Deonte Watts
Independent Researcher
Email: deonte@goodshyt.fun
URI: https://orcid.org/0009-0005-8586-3650
Watts Expires 12 April 2027 [Page 14]