Register did:aria DID method

[ivmtuno]

Register the did:aria DID method for verifiable AI agent identity.

• Method name: aria
• Specification: https://aria.bar/spec#did-method
• Maintainer: TrustLayer Foundation A.C.
• Status: Registered
• Verifiable data registry: DNS TXT + HTTPS endpoint
• Resolution:
  • L0 (Anchored): direct HTTPS fetch from api.aria.bar/v1/aids/{did} → signature verify against the registry's published key set
  • L1+ (Identified, Certified, Sovereign): DNS TXT lookup at _aria.<domain> returning a pointer (v=ARIA1; id=<did>; h=sha256:<hash>; r=<url>) → HTTPS fetch from the resolution URL → SHA-256 hash compare against the TXT record → composite signature verify
• Cryptography: ML-DSA-65 + Ed25519 composite (FIPS 204 + RFC 8032), suite mldsa65-ed25519-2026
• Credential format: W3C Verifiable Credential 2.0 (JSON-LD)
• Revocation: W3C Bitstring StatusList 2021
• Implementation: Live at https://api.aria.bar
• SDK: https://www.npmjs.com/package/@aria-registry/verify
• License: Apache 2.0 (code) + CC-BY-4.0 (specification)

The did:aria method provides DNS-anchored decentralized identity for AI agents operating across organizational boundaries. The trust model inherits 40 years of DNS governance — agents at L1 and above prove control of a domain via a published TXT record; the same hash that anchors the AID to the domain also pins the served document, so the AID cannot be silently substituted between DNS resolution and HTTPS retrieval. L0 credentials resolve via HTTPS only and serve as a zero-cost on-ramp without claiming domain control.

Filed with NIST PQC Implementation Registry as NIST-2025-0035 (March 2026).

[gatemezing]

• Please, check the references in Context - In the DID documentation, VC uses the following context URI - "https://www.w3.org/ns/credentials/v2"
• It would be great to detail CRUD operations using the method, elaborate on privacy and security considerations.

[ivmtuno]

Thanks for the review @gatemezing.

1. @context URI

Fixed — the AID example on the published spec at https://aria.bar/spec#did-method now references https://www.w3.org/ns/credentials/v2 (the VC 2.0 canonical context), matching the rest of the implementation (issuer, status list, JSON Schemas, conformance fixtures).

2. CRUD operations

The four DID-Core operations are documented in §03 — DID Method:

• Create — generate ML-DSA-65 + Ed25519 keypair, mint AID; at L1+ publish a TXT pointer at _aria.<domain>.
• Resolve — DNS TXT lookup → HTTPS fetch from the pointer URL → SHA-256 hash compare → composite signature verify.
• Update — re-issue AID at the same endpoint; the TXT record hash is updated atomically.
• Deactivate — remove the TXT record or flip the StatusList 2021 bit.

3. Privacy & Security Considerations

Covered across §18 (Security Architecture), §19 (Prompt Injection Defense), §20 (Auditing & Non-Repudiation), and §21 (Privacy & Data Governance) of the v1.0 spec. Topics include DNS-anchored trust model and DNSSEC interaction, hash pinning between TXT and the served AID, scope/delegation containment as damage-control under prompt injection, append-only audit ledger with redaction semantics for GDPR Art. 17, and the data-controller treatment of principal metadata.

Happy to expand any of these inline in the spec if helpful for the registration.

[github-actions]

🤖 AI Preliminary Specification Review

This is an advisory, automated review of the DID Method specification(s) referenced in this pull request, checked against the registration checklist. It does not replace review by the registry editors.

✅ All reviewed submissions passed the preliminary checklist review. A registry editor will still perform the final review.

methods/did-aria.json — method did:aria

Specification: https://aria.bar/spec#did-method

Preliminary verdict: ✅ PASS

The ARIA (did:aria) specification is a substantive, well-structured DID Method spec that defines syntax, CRUD operations, and includes security and privacy content. All MUST criteria are satisfied, though the Privacy and Security sections are somewhat thin relative to a dedicated treatment.

	Item	Level	Status	Notes
✅	M1. Specification is reachable and is a DID Method specification	MUST	pass
✅	M2. DID Method Syntax is defined	MUST	pass
✅	M3. CRUD operations are defined	MUST	pass
✅	M4. Security Considerations section is present and substantive	MUST	pass
✅	M5. Privacy Considerations section is present and substantive	MUST	pass
✅	M6. Method name is indicative and non-generic	MUST	pass
✅	M7. No unreasonable legal, security, moral, or privacy harms	MUST	pass
✅	M8. Human-readable description of the addition	MUST	pass
✅	S1. contactEmail present	OPTIONAL	pass
✅	S2. verifiableDataRegistry present	OPTIONAL	pass
✅	S3. Intellectual-property posture is clear	SHOULD	pass

[msporny]

Happy to expand any of these inline in the spec if helpful for the registration.

Yes, please do. The spec is pretty light on the DID Document part (but is very verbose on many other things). I couldn't find the ABNF for the syntax either.

[ivmtuno]

Thanks @msporny — expanded §03 to address both points. Live at https://aria.bar/spec#did-method.

§03.1 — Method Syntax (ABNF). Added the RFC 5234 grammar covering the four identifier shapes the reference implementation actually issues:

did-aria             = "did:aria:" method-specific-id
method-specific-id   = agent-id / principal-id
agent-id             = agent-domain-form / agent-registry-form
agent-domain-form    = domain ":" agent-slug
agent-registry-form  = registry-host ":" registry-account ":" agent-slug
principal-id         = principal-domain-form / principal-registry-form
principal-domain-form   = domain ":org"
principal-registry-form = registry-account ":org"

registry-account     = "u-" 8(ALPHA / DIGIT)
agent-slug           = 1*64(lowercase / DIGIT / "-")

The literal :org suffix is reserved so principal identifiers are unambiguously distinguishable from agent identifiers by inspection.

§03.2 — DID Document. Speccified as a deterministic derivation of the currently-active AID rather than a separate served resource. The AID is what the composite mldsa65-ed25519-2026 proof covers, so making the DID Document a projection of it eliminates any risk of the two drifting apart. The derived shape uses Multikey for the holder verification method, with explicit derivation rules for id, controller, verificationMethod, authentication, assertionMethod, and service.

The verificationMethod publishes only the Ed25519 holder key — the operations it signs (holder proofs over ATP challenges, presentation binding) are ephemeral; the composite post-quantum signature lives at the issuer layer in the AID, where retroactive forgeability actually matters. Any future PQ-native verification method type may be added alongside the Multikey entry without changing the resolution algorithm.

A forward-compatibility note explicitly leaves the door open to a future revision that serves a signed DID Document at a well-known endpoint alongside or in place of the derivation model — since the derivation is deterministic and the AID contains all the material the DID Document needs, that would be additive rather than breaking.

Let me know if further expansion is useful.