1) Accountable entity rejestruje FQDN agenta (np. `billing-agent-acme.example`). 2) Publikuje rekord TXT pod `_dnsid.<fqdn>` z tagami: v=DNSid1, oi (governance identifier), ku (URI JWKS), lr (referencja ledgera), su (URI statusu), sg (podpis rekordu). 3) Agent posiada JWKS endpoint pod `.well-known/jwks.json` z aktualnymi kluczami. 4) Immutable ledger (blockchain, CT-log, SCITT) zapisuje wszystkie zdarzenia cyklu zycia (ISSUANCE, KEY_ROTATION, REVOCATION, RETIREMENT, MIGRATION, optional DELEGATION i CONTENT_SIG), sygnowane kluczem accountable entity. 5) Verifier: rezolwuje `_dnsid.<fqdn>`, pobiera JWKS, weryfikuje podpis rekordu, sprawdza status endpoint, ustanawia HTTPS/mTLS z FQDN agenta. Dla operacji wysokiego zaufania: dodatkowo pyta ledger o zdarzenie ISSUANCE oraz brak REVOCATION.
Zaden istniejacy standard identyfikacji (OAuth 2.1, OIDC, SPIFFE/SPIRE, SCIM, NGAC, MCP) nie odpowiada na pytanie: kto jest odpowiedzialny za tego agenta AI i czy dowolny system moze zweryfikowac to niezaleznie. Autonomicznie dzialajace agenty AI negocjuja, transaktuja, deleguja i tworza artefakty pozostajace po zakonczeniu ich runtime. Wymaga to trwalej, governance-backed kotwicy wlasnosci — czego istniejacy stack IAM nie zapewnia.
Wybor implementacji ledgera: blockchain (Algorand, Ethereum), Merkle-tree CT-style log, SCITT transparency service, prywatny append-only log. DNSid jest ledger-neutral.
ES256 (MUST, ECDSA P-256), Ed25519 (SHOULD), ML-DSA (post-quantum, SHOULD po zarejestrowaniu z JWS). Wyrazane w polu `alg` JWK.
24h / 7d / 30d / 90d / unbounded. Kompromis miedzy security (czestszy rotation) a operational overhead.
mtls (wymus mutual TLS), logchk (wymus ledger inclusion check przed operacja high-value). Rozszerzalny slownik.
Dedicated registrable domain per agent (max pseudonimowosc + governance separation) vs shared organizational subdomain (operational simplicity + shared accountability scope).
Bez DNSSEC (verifier polega tylko na sg — obnizone assurance) vs z DNSSEC (strongest — DNS transport integrity + entity signature).
Verifikacja jest warunkowa — flags (`fl=logchk,mtls`) i `ka=<age>` decyduja o skali sprawdzen (samego rekordu, JWKS, statusu, ledgera). Wiele ciezkich krokow (ledger lookup) uruchamia sie tylko dla operacji wysokiego zaufania.
Weryfikacja DNSid jest w pelni rownoleglosowalna — kazdy verifier moze niezaleznie resolvowac DNS, pobierac JWKS, weryfikowac podpisy i pytac ledger, bez wspoldzielonego stanu.
