Register did:aria DID method

[ivvmoreno]

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.

[ivvmoreno]

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 complete, recognizable DID Method spec with a defined ABNF grammar, full CRUD operations, and substantive security and privacy content. All MUST criteria are satisfied; minor concerns are surfaced as warnings.

	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	warn	Licensing is stated (Apache 2.0 for code + CC-BY-4.0 for docs) and governance is a nonprofit, which is positive; however the spec markets tight coupling to a single foundation/registry (aria.bar, api.aria.bar) and trademark posture is not explicitly addressed. Minor advisory concern only.

[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.

[ivvmoreno]

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.

[ivvmoreno]

@gatemezing @msporny — both review threads have been addressed; flagging here since I don't have permission to re-request review directly.

@gatemezing (25 May): @context now references https://www.w3.org/ns/credentials/v2 throughout, CRUD operations are in §03.5, and privacy/security considerations are in §18–§21.

@msporny (4 Jul): §03.1 adds the RFC 5234 ABNF for the method-specific identifier, covering the four shapes the reference implementation issues. §03.2 specifies the DID Document as a deterministic derivation of the AID, with explicit derivation rules for id, controller, verificationMethod, authentication, assertionMethod and service.

Both live at https://aria.bar/spec#did-method. Branch is up to date with main and all checks pass.

Happy to expand either section further if that would help.

[mcypb24w9k-crypto]

Helo aria how can we HELp YOU.

[ivvmoreno]

Hi @ottomorac, @swcurran — I see you've been handling the recent method registrations, so flagging this one in case it has slipped past the queue.

Both review threads here have been addressed, but the reviews still show as changes requested and I don't have permission to re-request review, so I suspect this reads as blocked from the outside.

Where it stands:

• gatemezing (25 May) — @context now references https://www.w3.org/ns/credentials/v2 throughout; CRUD operations in §03.5; privacy and security considerations in §18–§21.
• msporny (4 Jul) — §03.1 adds the RFC 5234 ABNF for the method-specific identifier; §03.2 specifies the DID Document as a deterministic derivation of the AID.

Both are live at https://aria.bar/spec#did-method. The branch is current with main, checks pass, and the automated checklist review passed all eight MUST criteria.

Would one of you be able to take a look, or let me know if anything is still outstanding? Happy to keep iterating — I'd just rather not leave it sitting if what remains is only the stale review state.

Thanks for keeping the registry moving.

[ottomorac]

Hi @ivmtuno,

Thanks for flagging this. I have reviewed the spec, the main issue I see at the moment is that your CRUD methods are too brief (3.5 — Method operations (CRUD).

Would you be able to add more detail to them?

For each DID method operation that you support (Create, Read, Update, and Deactivate DID Method Operations). You should provide more details of how they function. See some examples here:

• https://docs.cheqd.io/product/architecture/adr-list/adr-001-cheqd-did-method#verification-method
• https://identity.foundation/didwebvh/v1.0/#did-method-operations
• https://github.com/iden3/did-iden3/blob/main/did-iden3-method.md#basic-operations

Let us know once you have addressed this. Thanks.

[ivvmoreno]

Thanks @ottomorac — that's exactly the kind of feedback that's useful, and the three references make the target clear.

You're right that §03.5 is thin. Rather than patch it in isolation, I'd rather fold it into a spec revision already in progress, so §03 lands as one coherent pass instead of two edits a few weeks apart. Realistic horizon is 2–3 weeks.

One ask while you have the document in front of you: is there anything else you'd want covered in the same pass? If something beyond the CRUD operations reads thin from a registry editor's perspective, I'd rather handle it in one submission than come back for a second round.

I'll comment here once the revised §03 is live.