How verification works, end to end

Eleven steps, in plain language. Each one links to the normative step in §3.5.2 of the specification, which is the text that binds; this page is the story of why each step exists.

1. Parse the DID. did:aria: plus a method-specific id in one of four shapes. Anything that does not match the grammar stops here (invalidDid).
2. Locate the pointer. For a domain-form DID, ask DNS over HTTPS for _aria.<domain>; for a registry-form DID, ask the registry host, or go straight to its resolver. A missing pointer for a domain-form DID means the domain does not back this agent.
3. Check the pointer. It must say v=ARIA1, name the same DID you asked about, carry a hash and an HTTPS URL. A pointer that names a different DID is a mismatch, not a redirect.
4. Fetch the document. Over HTTPS, as opaque bytes. Nothing is parsed yet.
5. Pin it. SHA-256 of the bytes must equal the hash in the pointer. If not, stop: a document that does not match its anchor is not evaluated further, no matter how valid it looks inside.
6. Bind it. credentialSubject.id must be the DID you started from. A valid credential for a different agent is still a mismatch.
7. Verify the two signatures. Canonicalise the credential without its proof, decode proofValue, check the ML-DSA-65 half against the issuer's post-quantum key and the Ed25519 half against the classical key. Both must pass. Why two is explained below.
8. Check validity. validFrom ≤ now < validUntil.
9. Check status. Fetch the status list the credential points to, verify its signature, read the bit. A set bit means revoked. Status evidence older than your freshness bound (ATP fresh=, floor 60 seconds) means stale, which is a failure, not a pass.
10. Check accreditation. The issuer must have been accredited to assert this level when it issued. Withdrawing an accreditation is forward-only: it does not unmake credentials issued while it stood (AUD-02).
11. Derive. The DID Document is a projection of the AID, computed by rule; nobody stores it. It is the result of resolution — a resolver that stops at step 10 and hands back the AID has verified a credential, not resolved a DID. The AID travels in the resolution metadata for clients that want it.

Why two signatures, and not one

A signature made today can be verified for years. That is the point of it, and also the problem: an adversary who records signed credentials now and waits for a large quantum computer can forge the classical half later — the harvest now, decrypt later pattern. ML-DSA-65 (FIPS 204) is designed so that this does not work. Ed25519 is kept alongside it because it is small, fast, and has fifteen years of scrutiny that ML-DSA does not yet have. Requiring both means an attacker has to break both: the credential is no weaker than the stronger of the two schemes.

This is why the check in step 7 is an AND and not an OR. A verifier that accepted either signature alone would be exactly as strong as the weaker one, and would let an attacker who broke one scheme drop the other. It is also why the composite mode has an end date (December 31, 2029) after which ML-DSA-only credentials are required: the classical half is a bridge, not a destination.

NIST's transition guidance (IR 8547, draft) describes the same direction — deprecating classical signatures for quantum-vulnerable uses over the next decade. ARIA does not claim conformance to it; it is cited here as the reference for why a bridge period exists at all.

Where each step lives

Steps 1–6 are the DID method (§3). Step 7 is the cryptosuite (§5.1). Steps 8–9 are lifecycle (§7); step 10 is trust bootstrap (§5.2); step 11 is the DID Document derivation (§3.2). To run steps 7–9 yourself: Verify a credential offline.