Groundmark

elliot@noss.org https://groundmark.org

easyDNS Technologies Inc.

markjr@easydns.com

Applications Independent Submission DNS agents identity HTTP Message Signatures DNSSEC This document defines the core of Groundmark, a protocol for DNS-anchored identity discovery and request authentication for autonomous software agents. Operators publish an agent's signing public key in a DNS TXT record under a reserved label, and optionally publish references to externally hosted attestations under a second reserved label. Agents authenticate HTTP requests using HTTP Message Signatures (RFC 9421) with a key identifier that resolves through DNS. DNSSEC is required for all Groundmark DNS lookups. The protocol provides operator accountability discovery without a central registry, and is designed to compose with existing identity, authorization, and payment systems rather than to replace them. The attestation framework, including the role of Identity Service Providers, the attestation level taxonomy, and the claim vocabulary, is defined in a companion document.

Introduction Autonomous software agents are increasingly conducting transactions on the Internet on behalf of human and organizational principals. Existing work addresses several adjacent concerns: HTTP-native payment flows , per-session delegated authorization protocols, and tool invocation frameworks. None of these answers a prior question: when an agent presents itself to a counterparty, is there an accountable party behind it, and how is that established without a central registry? This document defines Groundmark, a protocol that uses the Domain Name System (DNS) as the discovery anchor for agent identity. DNS is well suited to this role: it is open and well-governed; domain registrants are verified by registrars operating under established policy; the infrastructure is universally deployed; and any domain holder can publish agent identity records without any new global registry or delegation. The approach is modelled on DomainKeys Identified Mail (DKIM) , which established the pattern of publishing a public key in a DNS TXT record under a reserved label for the purpose of verifying cryptographic assertions in an application-layer protocol. Groundmark separates three concerns:

• Identity discovery: locating an agent's signing public key in DNS.
• Request authentication: binding an HTTP request to an agent's key using HTTP Message Signatures .
• Attestation discovery: pointing relying parties to externally hosted attestations describing what has been verified about the operator.

The first two are specified in this document. The third is introduced mechanically here, by defining a DNS record that references attestation endpoints; the trust semantics of those attestations are defined in the companion document . The semantics of the agent's domain string itself are not material to this protocol. An agent at "agent47.example.com" carries the same protocol weight as one at "x7q.example.com". What matters is the verifiable chain of control from the DNS root through a registrar-verified registrant to the holder of the agent's subdomain.

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.

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 with conventional algorithms.
• Define attestation semantics, IDSP obligations, attestation levels, or claim vocabularies. Those are the subject of the companion document .

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

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 when, and only when, they appear in all capitals, as shown here.

Terminology

Operator

Any person or organization that deploys and controls an autonomous agent. The operator is the principal whose accountability is at issue in the attestation framework defined by the companion document.

Agent

An autonomous software instance acting on behalf of an operator. An agent holds a cryptographic key pair; its public key is published in DNS under its agent domain.

Agent Domain

A fully qualified domain name (FQDN) that serves as the agent's identity anchor in DNS. Typically a subdomain under the operator's registered domain (e.g., "purchasing.acmecorp.example") but MAY be a second-level domain.

Identity Service Provider (IDSP)

A trusted third party that verifies a claim about an operator or agent and issues a signed attestation. Defined fully in ; referenced here only insofar as the _agentclaim record points to attestations issued by IDSPs.

Relying Party

An agent, API endpoint, or service that receives an agent's request, verifies the request signature against the agent's DNS-published key, and optionally evaluates attestations referenced from DNS.

System Overview A Groundmark-enabled HTTP request proceeds as follows.

1. The operator publishes an _agentid TXT record at the agent domain, containing the agent's signing public key, and OPTIONALLY one or more _agentclaim TXT records referencing externally hosted attestations. All such records MUST be published in a DNSSEC-signed zone.
2. The agent signs each HTTP request using HTTP Message Signatures as profiled in . The signature uses the agent's private key and identifies the corresponding public key through a keyid parameter that resolves to the agent domain.
3. The relying party retrieves the _agentid TXT record for the agent domain using a DNSSEC-validating resolver and verifies the request signature against the published public key. A successful verification establishes that the request originated from a party that controls the agent domain.
4. If the relying party's policy requires attestations beyond what is established by signature verification alone, it retrieves _agentclaim records for the agent domain, fetches the referenced attestations, and evaluates them according to the framework specified in the companion document.

DNS in this design is a discovery layer. It points to where keys and attestations are found; it does not itself host claim content. This mirrors the role DNS already plays for email authentication mechanisms such as DKIM and DMARC .

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: When the agent issues an HTTP POST to a relying party, the request carries Signature-Input, Signature, and Content-Digest header fields per and : 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 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 , and applies its policy.

DNS Record Formats Groundmark defines two TXT record formats published under reserved underscore labels at the agent domain. Both share the version tag "v=gm1" to distinguish them from other TXT record uses at the same domain. The use of two distinct labels reflects a deliberate separation of concerns: _agentid carries the cryptographic material that is the root of request authentication, and is expected to be small, stable, and aggressively cached only within a short TTL. _agentclaim carries references to attestations whose lifecycle is independent of the signing key and which may be added, removed, or replaced without affecting the agent's underlying identity.

The _agentid TXT Record The _agentid TXT record is published at: . IN TXT "v=gm1; k=ed25519; p=" ]]> The record declares the agent's signing public key and algorithm. It is the root of cryptographic verification for the agent identity.

ABNF Grammar The OPTIONAL "kid=" parameter allows an operator to publish an explicit key identifier matching the keyid parameter used in the request signature, which supports key rotation by deploying multiple _agentid records during transition (see ).

Processing Requirements The "k=" (key algorithm) and "p=" (public key) parameters MUST be present. The version tag "v=gm1" MUST appear first. This document defines "ed25519" as the only mandatory-to-implement algorithm. The "p=" field MUST contain the Base64url-encoded raw public key bytes for the specified algorithm (32 bytes for Ed25519). Support for additional algorithms MAY be added by future documents updating this specification. An operator publishing a single signing key MUST publish exactly one _agentid record. An operator may publish multiple _agentid records only as part of a key rotation procedure (see ); in that case, every published record MUST carry a distinct "kid=" value, and request signatures MUST identify the intended key by keyid. A relying party MUST treat the identity as invalid, and MUST NOT proceed with signature verification against any record at the label, if any of the following conditions hold at the time of lookup:

• More than one _agentid record is present at the label and any of them lacks a "kid=" parameter.
• More than one _agentid record is present and two or more of them share the same "kid=" value.

Operators SHOULD set the TTL of the _agentid record to 300 seconds or less to enable timely revocation. Relying parties MUST respect DNS TTL values and MUST NOT cache _agentid records beyond their TTL. Relying parties MUST use a DNSSEC-validating resolver when retrieving _agentid records. A response that fails DNSSEC validation MUST be treated as an invalid identity. See .

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 ; this document defines only the DNS record format and processing requirements. The most common form references an IDSP-hosted attestation: . IN TXT "v=gm1; claim=; idsp=; ref=; exp=" ]]> A self-asserted variant uses "val=" instead of "ref=" and "idsp=", and carries no IDSP signature: . 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.

ABNF Grammar

Processing Requirements The "claim=" field MUST be present in all _agentclaim records. When "ref=" is present, "idsp=" MUST also be present. When "val=" is present, "ref=" and "idsp=" MUST NOT be present. A record that satisfies neither shape MUST be ignored. Relying parties MUST ignore records with unrecognized "claim=" values rather than treating them as errors, to preserve forward compatibility. "ref=" URLs MUST use the HTTPS scheme. The path component of a "ref=" URL MUST contain at least 128 bits of cryptographically random entropy (for example, a UUIDv4 or 22-character Base64url-encoded random string). This document does not treat "ref=" URLs as confidential, but the entropy requirement defends against enumeration attacks against IDSP attestation endpoints (see ). Operators SHOULD set the TTL of _agentclaim records to 300 seconds or less. The "exp=" value provides claim-level expiry that is independent of DNS TTL; relying parties MUST NOT use a claim whose "exp=" time has passed, regardless of cache state. Relying parties MUST use a DNSSEC-validating resolver when retrieving _agentclaim records. A response that fails DNSSEC validation MUST be treated as an absent record.

Request Authentication Groundmark profiles HTTP Message Signatures for the purpose of authenticating agent requests. This document does not define a bespoke signing mechanism: the signature base, the Signature-Input header field, and the Signature header field are all as defined by . This section specifies which of the choices left open by are constrained for Groundmark implementations. The use of provides body integrity, authority binding, nonce semantics, and a well-reviewed canonicalization, and avoids introducing a novel cryptographic construction.

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

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.

Required Covered Components A Groundmark-compliant signature MUST cover, at minimum, the following 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 . 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.

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 .
• "alg": present and matching the algorithm associated with the public key in the _agentid record. (As a profile of , this document REQUIRES "alg" to be present, although 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.

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 . Confirm that the required covered components and signature parameters specified in and 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 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 .

Revocation Two independent revocation mechanisms are available to operators.

DNS-layer revocation

The operator deletes or rotates the _agentid record. The agent identity becomes invalid within the record's TTL. Operators performing emergency revocation SHOULD also publish an empty replacement record or otherwise serve a known-unusable value during the TTL window, and SHOULD set TTLs to 300 seconds or less in normal operation to minimize the worst-case revocation delay.

Claim-layer revocation

The IDSP marks a specific attestation as revoked at the attestation endpoint or its associated revocation endpoint. The agent identity remains usable; only the specific claim is invalidated. The mechanics of claim-layer revocation are specified in .

These mechanisms are independent: deletion of an _agentid record revokes the entire agent identity (and implicitly invalidates all attestations referencing it); revocation of a single _agentclaim leaves the underlying identity intact.

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

Security Considerations

DNSSEC Requirement All DNS lookups in the Groundmark verification flow MUST be performed using a DNSSEC-validating resolver . 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 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.

Replay Attacks The 300-second "created" window in 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 , binds the signature to a specific target host, preventing cross-service replay even if the signature is otherwise valid.

Body Integrity For requests with a body, the Content-Digest covered-component requirement of 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.

ref= URL Entropy "ref=" URLs function as opaque bearer references to attestation content. The minimum 128-bit entropy requirement in 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.

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 .

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

Privacy Considerations This section addresses the privacy properties of the protocol defined in this document, in the spirit of . Privacy considerations arising from specific attestation types are the subject of the companion document.

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.

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.

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.

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

Operational Considerations

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.

Coexistence with Other Protocols _agentid and _agentclaim are scoped underscored node names under . 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 . An operator MAY simultaneously publish Groundmark identity records and IoDNS metadata records under the same agent domain without interaction at the DNS layer.

Related Work This section positions Groundmark relative to other work in adjacent problem spaces. Groundmark is designed to compose with these specifications rather than to replace them.

HTTP Message Signatures (RFC 9421) Groundmark uses for request authentication. It does not modify or extend ; it specifies a profile (covered components, required signature parameters, key identification convention) suitable for DNS-anchored agent identity.

DKIM and DMARC Groundmark's DNS publication pattern is modelled on DKIM , 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. (DMARC) demonstrates the extension of this pattern to policy publication. Groundmark applies the same pattern to agent identity rather than email authentication.

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.

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.

x402 and IoDNS defines an HTTP-native payment protocol in which an agent receiving an HTTP 402 response pays in stablecoins and retries the request. 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.

IANA Considerations

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 : Groundmark underscore label registrations

RR Type	_NODE NAME	Reference
TXT	_agentid	This document
TXT	_agentclaim	This document

The registry operates under Expert Review per .

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

References Normative References Informative References Coinbase

Acknowledgements The authors thank Doc Searls for substantive review of earlier drafts, and the broader registrar and DNS community whose infrastructure makes this approach viable. The authors thank Kim Cameron, whose Laws of Identity informed the design of the attestation framework defined in the companion document.

Change Log

-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 including required coverage of @method, @authority, @target-uri, and Content-Digest 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.