ARIA

Six composable layers, each on a proven standard. DNS is the root; nothing below introduces a new cryptographic primitive.

Four levels, two independent axes: the person who answers and the entity represented. The level is not declared; it is recalculated from the evidence. An AID never guarantees the present or future conduct of the agent or its holder; it states what was verified, how, against which source and when (DPV-02).

The normative basis is the Verification Requirements (Appendix E). Each card cites the IDs it rests on; the cards state what a level asserts, the Requirements state what it demands.

Canonical method: did:aria. Compatibility bridge: did:web. Self-generated. Zero cost. No permission required to create.

§3.1 — Method Syntax (ABNF). The did:aria method-specific identifier follows this grammar, using ABNF as defined in RFC 5234 with the ALPHA and DIGIT core rules.

Four identifier shapes result from combining the two subject kinds (agent, principal) with the two anchoring modes (verified DNS domain, registry-namespaced fallback):

§3.2 — Resolution and the DID Document. The result of did:aria resolution is a DID Document in the sense of W3C DID Core 1.0 §5. It is not stored anywhere: a resolver derives it deterministically from the Agent Identity Document (AID) defined in §4 — a W3C Verifiable Credential secured by the composite mldsa65-ed25519-2026 proof — after obtaining the AID through the DNS TXT pointer (§3.4) and verifying its SHA-256 hash and composite signature. The AID is the signed source artifact; the DID Document is its projection, and the AID travels alongside it in the DID Document Metadata (§3.5.2). This is the same pattern as did:key (derived from the identifier) and did:webvh (derived from a log): derivation is resolution, the derived document is the result.

The derivation, applied to the currently-active AID:

Derivation rules — given an AID retrieved via §3.4 and the URL from which it was served:

§3.3 — Compatibility bridge: did:web. A did:web MAY act as a bridge for verifiers that already support did:web but not did:aria. The principal publishes the derived DID Document at https://<domain>/.well-known/did.json, which allows did:web:<domain> to resolve to the same document as did:aria:<domain>:org. The bridge is a compatibility measure; the canonical identifier remains did:aria.

§3.4 — DNS TXT pointer model. ML-DSA-65 public keys are 1,952 bytes raw (~2,603 bytes base64) — too large for a DNS TXT record (255 bytes per string). ARIA uses a two-component model: a TXT pointer at _aria.<domain> carrying the DID, a SHA-256 hash of the expected AID, and the HTTPS URL where the AID is served.

The hash pins the served AID to the TXT record — an adversary that substitutes the HTTPS response cannot match the hash the domain owner published, so tampering is detected before signature evaluation. TXT pointers for registry-form identifiers are published by the registry under its own zone (e.g. _aria.aria.bar); TXT pointers for domain-form identifiers are published by the principal under its verified zone. A name MAY hold several pointer records — one per agent anchored there (e.g. several agents under _aria.example.com, or every registry-form agent under _aria.aria.bar); a resolver selects the record whose did= equals the identifier being resolved and ignores the rest.

§3.5 — Method operations. did:aria defines the four DID Core operations. The registry holds the namespace and signs; the controller holds the keys. No operation requires the controller to reveal a private key to anyone.

§3.5.1 — Create.

Errors. malformed (fails §3.1), alreadyIssued (terminal), heldByAnother (live reservation by a different caller), reservationExpired, manifestSignatureInvalid, levelNotPermitted (the registry is not accredited for the requested level).

§3.5.2 — Read (Resolve). Input: a did:aria string. Output: a DID Resolution result — the derived DID Document (§3.2) as didDocument, the verified AID and its provenance in didDocumentMetadata, and didResolutionMetadata. The DID Document is the result; the AID is metadata. A resolver that returns the AID without the DID Document has not resolved the DID. A conforming resolver MUST perform every step; skipping one is a resolution failure, not a degraded success.

Resolution metadata. A resolver returns, alongside the document: retrieved (timestamp), source (dns | registry), dnssec (secure | insecure | bogus | indeterminate), statusChecked (timestamp of the status evidence), credentialId and, when present, previousCredentialId. A historical instance is resolvable by its credential-instance URL (GET /v1/credentials/{id}) so a verifier can walk the issuance chain.

Resolution result. Every field of DID Core §7 is present. didDocument carries the derivation of §3.2. didDocumentMetadata carries the AID and what was checked: versionId is the credential id, created and updated are the validFrom of the first and of the current credential at this DID, deactivated reflects §3.5.4, and the aria map names the URL the AID was fetched from, its SHA-256, the derived level and the age of the status evidence used. A client whose important artifact is the AID dereferences didDocumentMetadata.aria.aid, or passes the resolution option aria-aid=embed to receive the full credential inside that map; in both cases didDocument is returned. didResolutionMetadata carries contentType, the DNSSEC outcome of step 2, and on failure exactly one error from the codes above.

§3.5.3 — Update. The DID is stable; the credential is not. Every update is a re-issuance at the same DID: a new credential instance with a new top-level id, credentialSubject.previousCredentialId pointing to the superseded instance, and the superseded instance moved to superseded (§7). What MAY change: holder key (rotation), scopes, level (upward after verification, downward on Flag), principal metadata. What MUST NOT change: credentialSubject.id. For domain-form identifiers the controller MUST update hash= in the TXT pointer; a resolver that fetches the new document against the old hash fails at step 5, which is the intended behaviour until the pointer is updated. The registry records the re-issuance in the issuance record with both credential ids.

§3.5.4 — Deactivate. Two independent, non-exclusive signals; a verifier MUST honour either.

• Status list. The registry sets the credential's bit in the W3C Bitstring Status List v1.0 credential it publishes (§7). The new list is published within the COM-05 bound (§7). This is the authoritative signal: it works for every identifier form and survives the loss of the controller's DNS.
• Pointer removal. The controller of a domain-form identifier removes or empties _aria.<domain>. Resolution fails at step 2. This signal is under the controller's sole authority and needs no registry.

Deactivation is terminal for the identifier: a deactivated DID is never re-issued to a different controller, so a new agent cannot inherit the history or the trust of a retired one. The registry records the event with the revoking authority and reason code. Cascade — deactivating everything one registry ever vouched for — is never automatic; it is a distinct, human-authorized decision reserved for a proven compromise of the registry's attestation key.

Security and privacy of the operations. Reservation tokens are single-use, expire, and are stored only as a digest. The namespace never learns who the customer is — only which registry asked. No operation transmits a private key. Hash pinning (step 5) defeats substitution of the served document; the composite proof (step 7) defeats forgery even by a party able to alter DNS; accreditation-at-issuance (step 10) bounds the damage of a misbehaving registry to the window in which it was trusted.

The Agent Identity Document (AID) is ARIA's core data structure — the passport. A W3C Verifiable Credential containing everything a counterparty needs to verify an agent's identity, authorization, and intent.

ARIA defines three identity roles — analogous to DNS registrant vs. admin contact:

Post-quantum from the first credential, not retrofitted: the Harvest-Now-Decrypt-Later threat makes retroactive protection the requirement.

§5.1 — Cryptosuite mldsa65-ed25519-2026. A W3C Data Integrity cryptosuite is defined by its transformation, hashing and proof-serialization algorithms. What follows is what the deployed issuer and the published verifier implement; credentials in the wild are signed this way and cannot be re-signed, so this text is descriptive of the wire format, not aspirational.

1. Transformation. Take the credential as a JSON object, remove the proof member, and serialize it as canonical JSON: object members sorted by key (UTF-16 code-unit order, as Array.prototype.sort orders JavaScript strings, recursively at every depth), arrays in document order, no whitespace, strings escaped as JSON.stringify does (the two mandatory characters, the five short escapes, and remaining control characters below U+0020 as \u00xx; all other characters, including non-ASCII, emitted literally), numbers as JSON.stringify renders them. Encode as UTF-8. This form is intentionally narrower than RFC 8785 (JCS): for every credential ARIA issues the two coincide, but conformance is defined against the golden vectors in aria-protocol/conformance/, not against RFC 8785.
2. Hashing. None. Both algorithms sign the transformed bytes directly. ML-DSA-65 is used in pure mode with an empty context string; Ed25519 is pure Ed25519 (RFC 8032 §5.1, SHA-512 internal) with no pre-hash and no context. There is no additional domain-separation tag.
3. Proof serialization. proofValue is the unpadded base64url (RFC 4648 §5) encoding of u32be(pq_len) ‖ pq_signature ‖ ed_signature: a four-byte big-endian length of the ML-DSA-65 signature (3,309 bytes for FIPS 204 ML-DSA-65), the ML-DSA-65 signature, then the 64-byte Ed25519 signature. Suite 1.0 emits it multibase-encoded: the prefix u (base64url, no padding) per the multibase registry, because the VC v2 context types proofValue as sec:multibase and a bare base64 string declaring that datatype is not one. Credentials issued before the 1.0 cutover carry the same bytes with no prefix; a verifier MUST accept both. The two are decidable without guessing: the length header of this suite is always 0x00000CED, so a bare proofValue always begins AAAM and never u. A verifier MUST validate the header against the byte count that follows it rather than trusting the first character. The proof object carries type: DataIntegrityProof, cryptosuite: mldsa65-ed25519-2026, created, verificationMethod and proofPurpose: assertionMethod.
4. Verification. Decode proofValue; a value that is not base64url, shorter than four bytes, or whose declared length exceeds the remainder is MALFORMED. Recompute the transformation. Verify the ML-DSA-65 half against the issuer's ML-DSA-65 public key (1,952 bytes) and the Ed25519 half against the issuer's Ed25519 public key (32 bytes). Both MUST verify. A verifier MUST report which half failed, so tampering can be distinguished from implementation disagreement, and MUST NOT accept a credential on one half alone (ATP-11).
5. Determinism. FIPS 204 permits deterministic and hedged signing; the two produce different bytes for the same input. Byte-identical signatures across implementations are therefore not required and MUST NOT be asserted as a conformance property; what is required is that a signature produced by either variant verifies under the other's verifier.

§5.2 — Trust bootstrap: issuer keys and accreditation. Verification in §3.5.2 needs two inputs that are not in the credential: the issuer's public keys (step 7) and evidence that the issuer was accredited for the level at issuance time (step 10). This is ARIA's equivalent of a root store.

• Today. The issuer's ML-DSA-65 and Ed25519 public keys for did:aria:registry.aria.bar are pinned in the published verifier SDK (@aria-registry/verify) and overridable at runtime for other registries. The credential's verificationMethod (did:aria:registry.aria.bar#key-1) names the key but there is no live endpoint that serves it; api.aria.bar/.well-known/aria advertises the issuer DID, suite and status list URL but not the key material. No signed accreditation list is published: a verifier today trusts the pinned issuer for every level, which is acceptable only while a single registry issues and only L0 is issued.
• Consequence (invariant #4). Because the keys are compiled into every published SDK version, the issuer key cannot rotate for as long as any of those versions is in use. Key discovery must ship before rotation is even possible.
• [PLANNED] Key discovery. A signed key document resolvable from the issuer DID (the #key-1 fragment), served at a well-known location and mirrored in the SDK as a fallback, with explicit validity windows so rotation becomes a first-class operation.
• [PLANNED] Accreditation list. A TLF-signed list of accredited registries carrying, per registry, its attestation public key, ceiling level, accredited_from and any distrust_after cut-off — the data step 10 evaluates. Verifiers fetch it like a status list: cacheable, with a freshness bound.
• [PLANNED] TLF root distribution. The TLF root key that signs the accreditation list, distributed out of band (pinned in SDK releases, published fingerprint, offline ceremony record) so the chain closes at a key nobody obtains from the network it is meant to protect.

Scopes. Format namespace:resource:action: three colon-separated segments, wildcard only in the last. Eight immutable actions combine with admin-defined namespaces and resources. Every reference pins a version (commerce:purchase_order:read@v0.2); versions are immutable once published, with a 24-month minimum deprecation window.

Delegation. Authority flows from a human. An agent MAY delegate to a sub-agent; when it does, every hop MUST be signed, scope can only narrow, and the original principal stays traceable. Maximum depth: 4. credentialSubject.delegationDepth is signed by the issuer and is what ATP’s depth= compares against.

Human approval has three tiers declared in the delegation chain and enforced at resolution time: pre-authorized (routine), categorical (approve once per category), explicit (a human approves this specific action).

A person authorizes an agent on Tuesday and resigns on Wednesday; on Thursday the agent must not be acting with nobody behind it. On principal change the credential is suspended pending re-authorization. A designated successor principal is [PLANNED]: schema 1.0 has no field for it yet.

Every credential is in exactly one of six states:

Validity and renewal per level: §2.

Revocation. The registry sets the credential’s bit in the W3C Bitstring Status List v1.0 credential it publishes; the new list is available to verifiers in under 60 seconds from the event, and conforming verifiers do not accept status evidence older than 60 seconds unless the receiver’s policy is stricter (COM-05). The list credential is signed by the registry with the same composite suite as an AID, carries the id that issued credentials name in credentialStatus.statusListCredential, and is re-signed on every change; its validFrom is the moment that version was signed, which is the age a verifier measures against the freshness bound. A verifier MUST check the list credential’s proof before reading a bit from it: an unsigned list is a revocation claim over transport security, not evidence. Revocation is terminal for the credential; the identifier never returns to the pool (§3.5.1) and may be re-issued only to the same controller (§3.5.4).

Trust Ledger. The permanent, append-only, SHA-256 hash-chained record of every credential lifecycle event — issuance, renewal, suspension, revocation, expiry, tombstone — modeled on Certificate Transparency (RFC 9162). One event, one Trust Record; every record carries the delegation-chain snapshot at the time of the action. It records the registry that asked and the identifier concerned, never who the customer is (§9).

ATP defines what happens when an agent presents its credential to a receiving system: a three-phase handshake — Declare (the agent presents its AID and a signed Intent Declaration), Evaluate (the receiver checks both against its configured admission policy, the same one it publishes as a DNS TXT record), Admit (a result code, with a literal reason). The published record informs agents in advance and MUST match the configured policy. The explanatory guide, with deployment patterns and the DMARC parallel, is at /protocol; this section is the normative reference.

Intent Declaration. An Intent Declaration MUST be present in the Declare phase (ATP/1 §6.1) and is signed by the holder key. The three MUST fields below are the protocol minimum for it to be valid at all; a receiver’s intent= parameter adds required fields on top of that minimum, never below it.

Agent Trust Policy — the DNS record. ATP/1 grammar (RFC 5234): v=ATP1 first; enforce= mandatory in a published record; an unknown parameter is ignored unless written !name= (critical), in which case a processor that does not understand it MUST treat the policy as unsatisfiable. A record that fails to parse, or is absent, means “no usable published policy”.

Freshness. All checks are local after the first hash-pinned fetch. Status evidence MUST be no older than fresh (default 3600 s, floor 60 s): the receiver-side consumer of the COM-05 bound (§7).

Deployment layers. A conforming receiver runs three layers that add up; they are not alternatives to choose between. Every admission runs on the first; the second is reached only when the status evidence has aged past fresh; the third never participates in an admission at all.

Presented material. The evaluator receives an authenticated presentation: the agent’s DID, the audience it is presenting to, a fresh proof of possession, and the signed Intent Declaration, alongside the AID and the status evidence (ATP/1 §6.1). Steps 2 and 3 of the algorithm check the proof and the audience before the credential is looked at, which is what makes a copied AID useless to a third party.

Evaluation algorithm. Eleven checks in fixed order, cheapest and most local first, state-dependent last. Every check MUST be performed; the first failure ends the evaluation and its code is the result. The order is not a preference: a receiver that checked scopes before the signature would be reasoning about a document it has not authenticated.

Result codes. Every denial carries exactly one code — the first failing step — and a literal reason; both are part of the conformance contract.

Enforcement modes — graduated adoption, the pattern DMARC established:

Agent identity metadata is organizational, not personal. Agent DIDs identify software entities. The principal identity is held by the registry operator that performed the verification, under data controller obligations; TrustLayer Foundation stewards the standard and does not hold it. The authority’s own records name the registry that asked and the identifier issued, never the customer.

GDPR tension: the right to erasure (Article 17) conflicts with the Trust Ledger’s append-only immutability. Resolution: Trust Ledger entries can be redacted — the event record remains, personally identifiable fields are replaced with a redaction marker. Because the ledger never holds personal data in the first place (§7), redaction is a safeguard, not the design.

Spoofing. Cryptographic identity replaces self-reported user-agent strings; a DID resolves identically across clouds, so the identity fabric does not depend on any provider’s trust domain.

Accountability, as a design statement. ARIA is designed so that when a regulator, a court or a board asks “who authorized this agent to do this?” there is a signed, timestamped answer whose provenance can be checked. It is a property of the records, not a legal guarantee.

Prompt injection. ARIA’s contribution is not prevention (a model-layer problem) but damage containment through identity infrastructure:

Semantic versioning (major.minor). Minor changes (1.x) are backward-compatible; major changes (vN.0) may break. TLF supports all credentials under supported major versions for a minimum of 36 months. Preview-line credentials (labeled 1.0–1.2, April–August 2026) are outside this commitment and are sunset at the issuance cutover. API: v1 endpoints stable for a minimum of 5 years.

TrustLayer Foundation A.C. is the independent nonprofit that stewards the protocol, issues credentials from the issuance cutover (today the operating registry issues), maintains the Trust Ledger and governs the open standard under Apache 2.0 (code) and CC-BY-4.0 (documentation). Composition of the Technical Steering Committee, decision process and anti-capture provisions: /governance.

The 80 citable requirements that §2 rests on are published at aria.bar/requirements: version 1.3-draft, 10 requirements changed from v1.2, each marked with its reason; adoption by TLF [PLANNED]. The canonical text is Spanish; an English translation is [PLANNED], and until it is published the Spanish text governs. Every ID cited in this specification resolves there.