DNS-Anchored Identity Discovery for Autonomous Agents

1.1. Design Principles

Groundmark is designed around the following principles:¶

• Authenticate the minimum necessary. The intent is to enable permissionless interaction by default and to make stronger attestations available only where a relying party's risk profile demands them.¶
• DNS is a discovery layer, not a claims database. TXT records publish cryptographic material and point to where attestations are held. Attestations themselves are served over HTTPS.¶
• No single point of control. DNS is the common substrate, but no single entity controls which operators may publish agent identities, and the attestation framework defined in the companion document permits a diversity of Identity Service Providers.¶

1.2. Non-Goals

This specification explicitly does not:¶

• Define legal identity, human identification, or any form of personal attribution requirement.¶
• Define a global trust framework, governance regime, or compliance requirement.¶
• Mandate participation. An operator may decline to publish Groundmark records; a relying party may decline to require them.¶
• Replace decentralized identifiers (DIDs), Verifiable Credentials, OAuth, OpenID Connect, MCP, or any other identity, authorization, or capability protocol. Groundmark is designed to compose with these systems and MAY act as a discovery and bootstrap layer for any of them.¶
• Define a new cryptographic primitive. Request authentication uses HTTP Message Signatures [RFC9421] with conventional algorithms.¶
• Define attestation semantics, IDSP obligations, attestation levels, or claim vocabularies. Those are the subject of the companion document [I-D.noss-jeftovic-groundmark-attestation].¶

A consequence of the first three of these non-goals is that anonymous and pseudonymous agent operation remains a first-class deployment mode under Groundmark. The presence of an agent's public key in DNS does not, by itself, identify or accountably link the operator to a legal person; that linkage is the subject of optional attestations described in the companion document, and is opt-in by both the operator (who chooses whether to obtain and publish an attestation) and the relying party (which chooses whether to require one).¶

1.3. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3.1. Worked Example

The following non-normative example illustrates a complete Groundmark exchange. An operator deploys an agent under the domain "purchasing.acmecorp.example", publishing one identity record and one attestation reference:¶

_agentid.purchasing.acmecorp.example. 300 IN TXT
  "v=gm1; k=ed25519; p=oW8nN1xJxGv...HzG"

_agentclaim.purchasing.acmecorp.example. 300 IN TXT
  "v=gm1; claim=operator-verified;
   idsp=verify.example.net;
   ref=https://verify.example.net/a/4f9f3e1c7ab93d4f8d22;
   exp=2026-12-01"

When the agent issues an HTTP POST to a relying party, the request carries Signature-Input, Signature, and Content-Digest header fields per [RFC9421] and [RFC9530]:¶

POST /orders HTTP/1.1
Host: api.supplier.example
Content-Type: application/json
Content-Digest: \
  sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
Signature-Input: gm=("@method" "@authority" "@target-uri" \
    "content-digest");created=1747654321;\
    expires=1747654621;\
    keyid="purchasing.acmecorp.example";alg="ed25519"
Signature: gm=:9R...base64url...==:

{"sku":"X-42","quantity":3}

The relying party:¶

1. Parses Signature-Input and confirms required components and parameters.¶
2. Resolves _agentid.purchasing.acmecorp.example via a DNSSEC-validating resolver.¶
3. Verifies the Content-Digest against the request body.¶
4. Reconstructs the [RFC9421] signature base from the covered components.¶
5. Verifies the Ed25519 signature against the public key from the _agentid record.¶

If the relying party's policy requires more than Level 0, it additionally retrieves _agentclaim.purchasing.acmecorp.example, fetches the attestation at the ref= URL, verifies it per [I-D.noss-jeftovic-groundmark-attestation], and applies its policy.¶

4.1. The _agentid TXT Record

The _agentid TXT record is published at:¶

_agentid.<agent-domain>. IN TXT
  "v=gm1; k=ed25519; p=<base64url-public-key>"

The record declares the agent's signing public key and algorithm. It is the root of cryptographic verification for the agent identity.¶

agentid-record  = version 1*( ";" SP agentid-param )
version         = "v=gm1"
agentid-param   = key-alg-param / pubkey-param / keyid-param /
                  ext-param
key-alg-param   = "k=" key-alg
key-alg         = "ed25519" / x-token
pubkey-param    = "p=" base64url-value
keyid-param     = "kid=" 1*( ALPHA / DIGIT / "-" / "_" / "." )
ext-param       = param-name "=" param-value
param-name      = 1*( ALPHA / DIGIT / "-" )
param-value     = *( %x21-3A / %x3C-7E )
                  ; printable ASCII excluding ";"
base64url-value = 1*( ALPHA / DIGIT / "-" / "_" / "=" )
x-token         = "x-" 1*( ALPHA / DIGIT / "-" )

4.2. The _agentclaim TXT Record

The _agentclaim TXT record points to an externally hosted attestation about the operator or agent. The semantics of attestations themselves are defined in [I-D.noss-jeftovic-groundmark-attestation]; this document defines only the DNS record format and processing requirements.¶

The most common form references an IDSP-hosted attestation:¶

_agentclaim.<agent-domain>. IN TXT
  "v=gm1; claim=<type>; idsp=<domain>;
   ref=<https-url>; exp=<ISO8601-date>"

A self-asserted variant uses "val=" instead of "ref=" and "idsp=", and carries no IDSP signature:¶

_agentclaim.<agent-domain>. IN TXT
  "v=gm1; claim=operator-contact;
   val=ops@acmecorp.example"

Relying parties MUST treat self-asserted claims as unverified operator assertions. The companion document specifies how such records are incorporated into the attestation level taxonomy.¶

Multiple _agentclaim records MAY be present at the same label. Each represents an independent claim from a potentially different IDSP and is evaluated independently.¶

agentclaim-record = version 1*( ";" SP agentclaim-param )
version           = "v=gm1"
agentclaim-param  = claim-param / idsp-param / ref-param /
                    exp-param / val-param / ext-param
claim-param       = "claim=" claim-type
claim-type        = token / x-token
idsp-param        = "idsp=" hostname
ref-param         = "ref=" https-url
exp-param         = "exp=" date-value
val-param         = "val=" param-value
ext-param         = param-name "=" param-value
token             = 1*( ALPHA / DIGIT / "-" )
hostname          = 1*( ALPHA / DIGIT / "." / "-" )
https-url         = "https://" *( %x21-7E )
date-value        = 4DIGIT "-" 2DIGIT "-" 2DIGIT
                    [ "T" 2DIGIT ":" 2DIGIT ":" 2DIGIT
                      [ "Z" /
                        ( ( "+" / "-" ) 2DIGIT ":" 2DIGIT ) ] ]
param-name        = 1*( ALPHA / DIGIT / "-" )
param-value       = *( %x21-3A / %x3C-7E )
x-token           = "x-" 1*( ALPHA / DIGIT / "-" )

5.1. Signing Algorithm

Groundmark implementations MUST support Ed25519 [RFC8032], identified in Signature-Input by the algorithm name "ed25519" as registered in the "HTTP Signature Algorithms" registry established by [RFC9421]. Other algorithms MAY be used where both signer and verifier support them, but Ed25519 is the only mandatory-to-implement algorithm in this document.¶

5.2. Key Identification

The keyid signature parameter in Signature-Input MUST be one of the following two forms:¶

• The agent's fully qualified domain name (FQDN), in lowercase ASCII, with no "#" suffix. In this form, the relying party retrieves the _agentid record at the named domain; verification proceeds if and only if exactly one record is present at the label. (Equivalently, the bare-FQDN form is only valid outside of a key-rotation window.)¶
• The agent's FQDN followed by "#" and an opaque key identifier; for example, "purchasing.acmecorp.example#k2". In this form, the relying party retrieves the _agentid records at the named domain and selects the record whose "kid=" parameter matches the identifier after the "#". This form MUST be used whenever multiple _agentid records are concurrently published during key rotation.¶

A relying party MUST reject a signature whose keyid does not resolve to exactly one usable _agentid record under the rules above.¶

5.3. Required Covered Components

A Groundmark-compliant signature MUST cover, at minimum, the following [RFC9421] derived components:¶

• @method¶
• @authority¶
• @target-uri¶

A Groundmark-compliant signature on any HTTP request that carries a request body MUST additionally cover the Content-Digest HTTP field as defined in [RFC9530]. The signer MUST include a Content-Digest field in the signed request and MUST select an algorithm from the "Hash Algorithms for HTTP Digest Fields" registry; the algorithm "sha-256" is mandatory to implement for both signers and verifiers.¶

A signature on a request with no body (for example, most GET requests) MAY omit Content-Digest.¶

5.4. Required Signature Parameters

The Signature-Input header field MUST include the following parameters:¶

• "created": the time of signing, as a UNIX timestamp in seconds.¶
• "keyid": as specified in Section 5.2.¶
• "alg": present and matching the algorithm associated with the public key in the _agentid record. (As a profile of [RFC9421], this document REQUIRES "alg" to be present, although [RFC9421] itself permits the algorithm to be derived from the key.)¶

The Signature-Input header field SHOULD include "expires", set to a time no more than 300 seconds after "created". Relying parties MUST reject signatures whose "created" time differs from the verifier's current clock by more than 300 seconds in either direction, and MUST reject signatures whose "expires" time, if present, is in the past.¶

For higher-risk transactions, relying parties SHOULD require a "nonce" parameter, MUST track recently observed nonces for the duration of the verification window, and MUST reject a signature whose nonce has been observed within that window. Maintenance of a nonce cache is a relying-party concern; the size of the cache and its eviction policy are out of scope for this specification.¶

5.5. Verification Steps

A relying party verifying a Groundmark request signature MUST perform the following steps. Failure of any step MUST result in rejection of the signature.¶

1. Parse the Signature-Input and Signature header fields per [RFC9421]. Confirm that the required covered components and signature parameters specified in Section 5.3 and Section 5.4 are present.¶
2. Verify that "created" is within 300 seconds of the verifier's current clock, and that "expires", if present, is in the future.¶
3. Resolve the agent domain from the keyid parameter and retrieve the appropriate _agentid TXT record using a DNSSEC-validating resolver. If DNSSEC validation fails or no usable record is present, reject the request.¶
4. If a request body is present, verify that the value in the Content-Digest header field matches a digest of the received body, computed using an algorithm the verifier supports.¶
5. Reconstruct the signature base per [RFC9421] from the covered components in the order indicated by Signature-Input.¶
6. Verify the signature in the Signature header field against the reconstructed signature base using the public key from the _agentid record.¶
7. If the verifier's policy requires attestations beyond identity verification, proceed to retrieve and evaluate _agentclaim records per [I-D.noss-jeftovic-groundmark-attestation].¶

6.1. Key Rotation

Operators rotating an agent signing key SHOULD use the following procedure to avoid request rejection during transition.¶

If the operator's current _agentid record does not carry a "kid=" parameter, the operator MUST first publish a replacement of the current record that includes a "kid=" parameter, and wait at least one TTL period before proceeding. This is because, during rotation, the validity rule of Section 4.1.2 requires every published record to carry a "kid=".¶

The rotation itself proceeds as follows:¶

1. Generate the new key pair.¶
2. Publish a second _agentid record at the agent domain, with a "kid=" parameter distinct from the existing record.¶
3. Begin issuing requests with the new key. Requests MUST identify the new key via the keyid signature parameter using the "<FQDN>#<kid>" form specified in Section 5.2.¶
4. After a transition period not less than twice the published _agentid TTL, remove the previous _agentid record.¶

Relying parties supporting key rotation MUST select the _agentid record matching the keyid value carried in the signature. Relying parties MAY cache multiple _agentid records concurrently up to their respective TTLs.¶

7.1. DNSSEC Requirement

All DNS lookups in the Groundmark verification flow MUST be performed using a DNSSEC-validating resolver [RFC4033]. Without DNSSEC validation, DNS cache poisoning attacks could substitute an attacker's public key for the legitimate agent's key, rendering the entire verification flow meaningless. Implementations MUST treat any of the following as a fatal verification failure: a SERVFAIL response from a validating resolver, an explicit AD=0 response from a recursive resolver that the implementation relies on for validation, or any other condition in which the implementation cannot confirm a validated answer.¶

This DNSSEC requirement applies to operators publishing _agentid and _agentclaim records, and to IDSPs publishing their own signing keys. It does not require DNSSEC adoption across the general Internet. Entities making the deliberate decision to participate in Groundmark are the appropriate population to bear this operational requirement, and the requirement is proportionate to the trust being claimed.¶

Implementations MAY use DNS-over-HTTPS [RFC8484] or other authenticated transport to a trusted recursive resolver as part of their DNSSEC strategy, but the validation chain itself MUST be verified end-to-end.¶

7.2. Replay Attacks

The 300-second "created" window in [RFC9421] signatures limits replay exposure. Relying parties servicing high-value transactions SHOULD require a "nonce" parameter and maintain a nonce cache for the duration of the verification window; this prevents replay within the window at the cost of relying-party state.¶

The "@authority" covered component, required by Section 5.3, binds the signature to a specific target host, preventing cross-service replay even if the signature is otherwise valid.¶

7.3. Body Integrity

For requests with a body, the Content-Digest covered-component requirement of Section 5.3 provides body integrity: an intermediary that modifies the request body will invalidate the signature. Implementations MUST verify the Content-Digest value against the received body before accepting the signature as valid.¶

7.4. ref= URL Entropy

"ref=" URLs function as opaque bearer references to attestation content. The minimum 128-bit entropy requirement in Section 4.2.2 defends against enumeration of IDSP attestation endpoints. IDSPs MUST use cryptographically random URL path components and MUST NOT use sequential, predictable, or low-entropy identifiers. Implementations SHOULD avoid unnecessary exposure of "ref=" URLs in logs, telemetry, or third-party-accessible interfaces.¶

The high-entropy "ref=" design does not by itself render attestation content confidential at the network layer; rather, it ensures that relying parties retrieve attestations by reference rather than by guessable enumeration. Confidentiality properties of attestation content are specified by the companion document.¶

7.5. Subdomain Takeover and Endpoint Decommissioning

"ref=" URLs are embedded in DNS TXT records and may be cached by relying parties. If an IDSP decommissions a subdomain referenced by outstanding attestations without first invalidating those attestations, a third party who later acquires the subdomain could serve fraudulent attestations at existing URLs. To mitigate this:¶

• IDSPs MUST NOT release a hostname used in attestation "ref=" URLs until all attestations referencing that hostname have either expired (per "exp=" in their _agentclaim records) or been explicitly revoked.¶
• IDSPs SHOULD serve HTTP 410 Gone responses at decommissioned attestation paths for a minimum of 90 days before releasing the hostname.¶
• Relying parties MUST treat a TLS certificate change or unreachable endpoint at a previously valid "ref=" URL as cause for re-checking the corresponding _agentclaim record and the IDSP's identity-discovery records.¶

Additional revocation and decommissioning guidance specific to the IDSP role is given in [I-D.noss-jeftovic-groundmark-attestation].¶

7.6. Key Compromise

Compromise of an agent signing key permits an attacker to impersonate the agent until the corresponding _agentid record is removed and caches expire. To minimize exposure:¶

• Operators SHOULD set _agentid TTLs to 300 seconds or less.¶
• Operators SHOULD provision the rotation procedure of Section 6.1 in advance so that emergency key replacement can be performed without delay.¶
• Relying parties MUST NOT cache _agentid records beyond their DNS-declared TTL.¶

This document defines no mechanism for an emergency "kill" signal distinct from DNS-level deletion. Operators requiring more aggressive revocation guarantees should consider running their authoritative nameservers with the capacity to make rapid zone updates and short TTLs.¶

8.1. Organizational Disclosure Model

Groundmark's primary deployment model is organizational. The operator is, in the typical case, a company or other organization deploying agents in a commercial or operational context, under domains that already publish substantial public metadata: MX records, SPF, DKIM selectors, DMARC policy, CAA records, and (subject to applicable law) registrant data. The addition of _agentid and _agentclaim records extends this existing organizational-disclosure model, rather than introducing a new category of disclosure.¶

What is publicly visible when an operator publishes Groundmark records is:¶

• The fact that the named agent domain participates in Groundmark.¶
• The agent's signing public key.¶
• The type of any attestations available for the agent (the "claim=" field) and the identity of the IDSP issuing them (the "idsp=" field).¶

Attestation content itself is not in DNS. It is reachable only by following the high-entropy "ref=" URL, which is not enumerable from the DNS record alone.¶

8.2. Individual Operator Considerations

The organizational framing above does not address the case of an individual operator (sole proprietor, freelancer, or hobbyist) deploying agents under a personal domain. A _agentclaim record indicating, for example, that a kyc-basic attestation exists under the operator's personal domain reveals compliance posture in a way that is qualitatively different from the same record under a corporate domain.¶

For this case, the recommended pattern is provider-hosted agent identities, analogous to the WHOIS privacy proxy model long used in domain registration. An individual operator participating in Groundmark SHOULD publish agent identity records under a provider's domain rather than under a personal domain, where the provider's underlying relationship with the operator preserves the accountability chain that an IDSP-issued attestation depends on. This keeps the operator's personal domain outside the public record while preserving the attestation framework's accountability semantics.¶

This is a recommendation, not a normative requirement; nothing in this specification prevents an individual operator from publishing Groundmark records under a personal domain if they choose.¶

8.3. Selective Disclosure

The protocol publishes only public keys in _agentid and only attestation references (not values) in _agentclaim. The attestation framework specified in the companion document is built around minimal disclosure: attestation values are bounded predicates such as "the operator is over 18", not the underlying personal data.¶

8.4. Resolver-Side Observation

DNS resolution of _agentid and _agentclaim records is, like any DNS lookup, observable by network operators on the path between the relying party and the authoritative servers. Relying parties concerned about this leakage SHOULD use authenticated, encrypted transports to their recursive resolver (such as DNS-over-HTTPS [RFC8484]).¶

9.1. Caching and Resolver Load

Groundmark verification is designed to be amortized through caching, not performed in full on every request. A relying party that has recently verified a request from a given agent domain may have its _agentid record cached at the local resolver; an attestation fetched once may be valid for hours or days, subject to its "exp=" time and the IDSP's Cache-Control directives.¶

To support this:¶

• IDSPs MUST set Cache-Control max-age values on attestation responses consistent with the attestation's expected freshness, and MUST NOT set values so short as to force effectively per-request revalidation. Specific normative guidance for IDSPs is given in the companion document.¶
• Relying parties SHOULD cache _agentid records and attestation payloads up to the lesser of the resource's stated lifetime and any local cache policy.¶
• Implementations operating at high transaction volumes (for example, serving requests from AI agent fleets) SHOULD prefer a resolver architecture that aggregates DNS lookups for an agent domain rather than re-resolving per request.¶

The two-level structure (cheap, near-constant _agentid lookups; less frequent, cacheable attestation fetches) is intended to make Groundmark workable at scales characteristic of automated agent deployments.¶

9.2. Coexistence with Other Protocols

_agentid and _agentclaim are scoped underscored node names under [RFC8552]. They do not conflict with other underscore-labeled records published at the same domain, including _dmarc, _dkim, DANE TLSA records, or vendor-defined labels such as those used by [IoDNS]. An operator MAY simultaneously publish Groundmark identity records and IoDNS metadata records under the same agent domain without interaction at the DNS layer.¶

10.1. HTTP Message Signatures (RFC 9421)

Groundmark uses [RFC9421] for request authentication. It does not modify or extend [RFC9421]; it specifies a profile (covered components, required signature parameters, key identification convention) suitable for DNS-anchored agent identity.¶

10.2. DKIM and DMARC

Groundmark's DNS publication pattern is modelled on DKIM [RFC6376], which established the practical pattern of publishing a public key in a DNS TXT record under a reserved label for the purpose of application-layer signature verification. [RFC7489] (DMARC) demonstrates the extension of this pattern to policy publication. Groundmark applies the same pattern to agent identity rather than email authentication.¶

10.3. W3C Decentralized Identifiers and Verifiable Credentials

Groundmark and the W3C identity ecosystem operate at different layers. Groundmark addresses operator-accountability discovery: a stable, DNS-anchored pointer to who stands behind an agent. Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) address identifier resolution and credential format and presentation. The two are composable: an IDSP operating within the Groundmark framework MAY issue a Verifiable Credential as its attestation payload and reference it via a Groundmark "ref=" URL, and an operator MAY publish a DID in addition to or instead of a domain-anchored identity by extending _agentid semantics under future versions of this specification. Nothing in Groundmark precludes any of these compositions.¶

10.4. Agent Name Service (ANSv2) and DNS-AID

Several other DNS-anchored agent-discovery proposals exist as Internet-Drafts at the time of writing. ANSv2 addresses agent naming and versioning; DNS-AID addresses DNS-based agent discovery using SVCB records. Groundmark addresses operator identity and attestation under different underscored DNS labels and may coexist with these protocols at the same domain. The architectural distinction is that ANSv2 and DNS-AID address what an agent is and how it is reached, while Groundmark addresses who is accountable for the agent and what has been verified about that accountable party.¶

10.5. x402 and IoDNS

[X402] defines an HTTP-native payment protocol in which an agent receiving an HTTP 402 response pays in stablecoins and retries the request. [IoDNS] is a DNS metadata framework that publishes structured machine-readable documents at a domain, including payment endpoint discovery as one document type. Groundmark's _agentid and _agentclaim records coexist with IoDNS metadata records and with any x402 discovery records at the same agent domain, under different underscored labels. An agent presenting both Groundmark request signatures and IoDNS-advertised payment capability provides relying parties with operator accountability and payment routing from a single DNS hierarchy.¶

11.1. Underscored and Globally Scoped DNS Node Names Registry

IANA is requested to add the following entries to the "Underscored and Globally Scoped DNS Node Names" registry established by [RFC8552]:¶

The registry operates under Expert Review per [RFC8552].¶

11.2. HTTP Signature Algorithms

This document does not define new entries in the "HTTP Signature Algorithms" registry established by [RFC9421]. Groundmark implementations use registered algorithms only; the mandatory-to-implement algorithm "ed25519" is already registered by [RFC9421].¶

-00

• Initial submission.¶
• Split from prior draft draft-noss-groundmark-agent-identity-dns into a narrow core protocol document plus a companion attestation framework document.¶
• Replaced the bespoke Agent-Identity HTTP header with a profile of HTTP Message Signatures [RFC9421] including required coverage of @method, @authority, @target-uri, and Content-Digest [RFC9530] for requests with bodies.¶
• Added explicit Non-Goals section.¶
• Added Privacy Considerations and Operational Considerations sections.¶
• Added Related Work section.¶
• Specified key rotation procedure using a "kid=" parameter and the keyid signature parameter.¶