1) The accountable entity registers the agent FQDN (e.g. `billing-agent-acme.example`). 2) It publishes a TXT record at `_dnsid.<fqdn>` with tags: v=DNSid1, oi (governance identifier), ku (JWKS URI), lr (ledger reference), su (status URI), sg (record signature). 3) The agent has a JWKS endpoint at `.well-known/jwks.json` with current keys. 4) An immutable ledger (blockchain, CT-log, SCITT) records all lifecycle events (ISSUANCE, KEY_ROTATION, REVOCATION, RETIREMENT, MIGRATION, optional DELEGATION and CONTENT_SIG), signed by the accountable entity's key. 5) A verifier resolves `_dnsid.<fqdn>`, fetches the JWKS, verifies the record signature, checks the status endpoint, and establishes HTTPS/mTLS with the agent FQDN. For high-trust operations: additionally queries the ledger for the ISSUANCE event and the absence of a REVOCATION.
No existing identity standard (OAuth 2.1, OIDC, SPIFFE/SPIRE, SCIM, NGAC, MCP) answers the question: who is accountable for this AI agent, and can any system verify that independently. Autonomously operating AI agents negotiate, transact, delegate, and produce artifacts that persist beyond their runtime. This requires a durable, governance-backed ownership anchor โ something the existing IAM stack does not provide.
Choice of ledger implementation: blockchain (Algorand, Ethereum), a Merkle-tree CT-style log, a SCITT transparency service, or a private append-only log. DNSid is ledger-neutral.
ES256 (MUST, ECDSA P-256), Ed25519 (SHOULD), ML-DSA (post-quantum, SHOULD after registration with JWS). Expressed in the JWK's `alg` field.
24h / 7d / 30d / 90d / unbounded. Trade-off between security (more frequent rotation) and operational overhead.
mtls (require mutual TLS), logchk (require a ledger inclusion check before a high-value operation). An extensible vocabulary.
Dedicated registrable domain per agent (maximum pseudonymity + governance separation) vs shared organisational subdomain (operational simplicity + shared accountability scope).
No DNSSEC (verifier relies on sg alone โ reduced assurance) vs DNSSEC (strongest โ DNS transport integrity + entity signature).
Verification is conditional โ flags (`fl=logchk,mtls`) and `ka=<age>` determine the extent of checks (record itself, JWKS, status, ledger). Many expensive steps (ledger lookup) only run for high-trust operations.
DNSid verification is fully parallelisable โ each verifier can independently resolve DNS, fetch JWKS, verify signatures, and query the ledger, with no shared state.
