DNS-Anchored Identity Discovery for Autonomous Agents
draft-noss-jeftovic-groundmark-core-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | elliot noss , Mark E. Jeftovic | ||
| Last updated | 2026-05-24 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-noss-jeftovic-groundmark-core-00
Independent Submission E. Noss
Internet-Draft Groundmark
Intended status: Experimental M. Jeftovic
Expires: 25 November 2026 easyDNS Technologies Inc.
24 May 2026
DNS-Anchored Identity Discovery for Autonomous Agents
draft-noss-jeftovic-groundmark-core-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 November 2026.
Noss & Jeftovic Expires 25 November 2026 [Page 1]
Internet-Draft Groundmark Core May 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4
1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Worked Example . . . . . . . . . . . . . . . . . . . . . 7
4. DNS Record Formats . . . . . . . . . . . . . . . . . . . . . 8
4.1. The _agentid TXT Record . . . . . . . . . . . . . . . . . 8
4.1.1. ABNF Grammar . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Processing Requirements . . . . . . . . . . . . . . . 9
4.2. The _agentclaim TXT Record . . . . . . . . . . . . . . . 9
4.2.1. ABNF Grammar . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Processing Requirements . . . . . . . . . . . . . . . 11
5. Request Authentication . . . . . . . . . . . . . . . . . . . 11
5.1. Signing Algorithm . . . . . . . . . . . . . . . . . . . . 12
5.2. Key Identification . . . . . . . . . . . . . . . . . . . 12
5.3. Required Covered Components . . . . . . . . . . . . . . . 12
5.4. Required Signature Parameters . . . . . . . . . . . . . . 13
5.5. Verification Steps . . . . . . . . . . . . . . . . . . . 13
6. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. DNSSEC Requirement . . . . . . . . . . . . . . . . . . . 15
7.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 16
7.3. Body Integrity . . . . . . . . . . . . . . . . . . . . . 16
7.4. ref= URL Entropy . . . . . . . . . . . . . . . . . . . . 16
7.5. Subdomain Takeover and Endpoint Decommissioning . . . . . 17
7.6. Key Compromise . . . . . . . . . . . . . . . . . . . . . 17
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. Organizational Disclosure Model . . . . . . . . . . . . . 18
8.2. Individual Operator Considerations . . . . . . . . . . . 18
8.3. Selective Disclosure . . . . . . . . . . . . . . . . . . 19
8.4. Resolver-Side Observation . . . . . . . . . . . . . . . . 19
9. Operational Considerations . . . . . . . . . . . . . . . . . 19
Noss & Jeftovic Expires 25 November 2026 [Page 2]
Internet-Draft Groundmark Core May 2026
9.1. Caching and Resolver Load . . . . . . . . . . . . . . . . 19
9.2. Coexistence with Other Protocols . . . . . . . . . . . . 20
10. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. HTTP Message Signatures (RFC 9421) . . . . . . . . . . . 20
10.2. DKIM and DMARC . . . . . . . . . . . . . . . . . . . . . 20
10.3. W3C Decentralized Identifiers and Verifiable
Credentials . . . . . . . . . . . . . . . . . . . . . . 21
10.4. Agent Name Service (ANSv2) and DNS-AID . . . . . . . . . 21
10.5. x402 and IoDNS . . . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11.1. Underscored and Globally Scoped DNS Node Names
Registry . . . . . . . . . . . . . . . . . . . . . . . . 21
11.2. HTTP Signature Algorithms . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. 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 [X402], 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) [RFC6376], 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.
Noss & Jeftovic Expires 25 November 2026 [Page 3]
Internet-Draft Groundmark Core May 2026
* Request authentication: binding an HTTP request to an agent's key
using HTTP Message Signatures [RFC9421].
* 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
[I-D.noss-jeftovic-groundmark-attestation].
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.
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.
Noss & Jeftovic Expires 25 November 2026 [Page 4]
Internet-Draft Groundmark Core May 2026
* 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.
2. 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.
Noss & Jeftovic Expires 25 November 2026 [Page 5]
Internet-Draft Groundmark Core May 2026
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
[I-D.noss-jeftovic-groundmark-attestation]; 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.
3. 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
[RFC9421] as profiled in Section 5. 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 [RFC6376] and DMARC [RFC7489].
Noss & Jeftovic Expires 25 November 2026 [Page 6]
Internet-Draft Groundmark Core May 2026
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.
Noss & Jeftovic Expires 25 November 2026 [Page 7]
Internet-Draft Groundmark Core May 2026
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. 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.
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.
4.1.1. ABNF Grammar
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 / "-" )
Noss & Jeftovic Expires 25 November 2026 [Page 8]
Internet-Draft Groundmark Core May 2026
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 Section 6.1).
4.1.2. 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
[RFC4648] 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 Section 6.1); 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 Section 7.1.
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.
Noss & Jeftovic Expires 25 November 2026 [Page 9]
Internet-Draft Groundmark Core May 2026
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.
4.2.1. ABNF Grammar
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 / "-" )
Noss & Jeftovic Expires 25 November 2026 [Page 10]
Internet-Draft Groundmark Core May 2026
4.2.2. 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 Section 7.4).
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.
5. Request Authentication
Groundmark profiles HTTP Message Signatures [RFC9421] 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
[RFC9421]. This section specifies which of the choices left open by
[RFC9421] are constrained for Groundmark implementations.
The use of [RFC9421] provides body integrity, authority binding,
nonce semantics, and a well-reviewed canonicalization, and avoids
introducing a novel cryptographic construction.
Noss & Jeftovic Expires 25 November 2026 [Page 11]
Internet-Draft Groundmark Core May 2026
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
Noss & Jeftovic Expires 25 November 2026 [Page 12]
Internet-Draft Groundmark Core May 2026
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.
Noss & Jeftovic Expires 25 November 2026 [Page 13]
Internet-Draft Groundmark Core May 2026
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. 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 [I-D.noss-jeftovic-groundmark-attestation].
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.
Noss & Jeftovic Expires 25 November 2026 [Page 14]
Internet-Draft Groundmark Core May 2026
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. Security Considerations
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.
Noss & Jeftovic Expires 25 November 2026 [Page 15]
Internet-Draft Groundmark Core May 2026
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.
Noss & Jeftovic Expires 25 November 2026 [Page 16]
Internet-Draft Groundmark Core May 2026
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.
Noss & Jeftovic Expires 25 November 2026 [Page 17]
Internet-Draft Groundmark Core May 2026
8. Privacy Considerations
This section addresses the privacy properties of the protocol defined
in this document, in the spirit of [RFC6973]. Privacy considerations
arising from specific attestation types are the subject of the
companion document.
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
Noss & Jeftovic Expires 25 November 2026 [Page 18]
Internet-Draft Groundmark Core May 2026
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. Operational Considerations
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.
Noss & Jeftovic Expires 25 November 2026 [Page 19]
Internet-Draft Groundmark Core May 2026
* 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. 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.
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.
Noss & Jeftovic Expires 25 November 2026 [Page 20]
Internet-Draft Groundmark Core May 2026
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. IANA Considerations
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]:
Noss & Jeftovic Expires 25 November 2026 [Page 21]
Internet-Draft Groundmark Core May 2026
+=========+=============+===============+
| RR Type | _NODE NAME | Reference |
+=========+=============+===============+
| TXT | _agentid | This document |
+---------+-------------+---------------+
| TXT | _agentclaim | This document |
+---------+-------------+---------------+
Table 1: Groundmark underscore label
registrations
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].
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005,
<https://www.rfc-editor.org/rfc/rfc4033>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
Noss & Jeftovic Expires 25 November 2026 [Page 22]
Internet-Draft Groundmark Core May 2026
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, March 2019,
<https://www.rfc-editor.org/rfc/rfc8552>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, February 2024,
<https://www.rfc-editor.org/rfc/rfc9421>.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
February 2024, <https://www.rfc-editor.org/rfc/rfc9530>.
12.2. Informative References
[Cameron2005]
Cameron, K., "The Laws of Identity", May 2005,
<https://www.identityblog.com/?p=352>.
[I-D.noss-jeftovic-groundmark-attestation]
Noss, E. and M. Jeftovic, "Groundmark Attestation
Framework and Identity Service Provider Profile", Work in
Progress, Internet-Draft, draft-noss-jeftovic-groundmark-
attestation-00, 2026,
<https://datatracker.ietf.org/doc/html/draft-noss-
jeftovic-groundmark-attestation-00>.
[IoDNS] Jeftovic, M., "Intelligence-over-DNS (IoDNS)", 2025,
<https://github.com/easydns/iodns>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, September 2011,
<https://www.rfc-editor.org/rfc/rfc6376>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July
2013, <https://www.rfc-editor.org/rfc/rfc6973>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, March 2015,
<https://www.rfc-editor.org/rfc/rfc7489>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
Noss & Jeftovic Expires 25 November 2026 [Page 23]
Internet-Draft Groundmark Core May 2026
[X402] Coinbase, "x402: An HTTP-Native Payment Protocol", 2025,
<https://x402.org>.
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 [Cameron2005] 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 [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.
Authors' Addresses
Elliot Noss
Groundmark
Email: elliot@noss.org
URI: https://groundmark.org
Mark Jeftovic
easyDNS Technologies Inc.
Email: markjr@easydns.com
Noss & Jeftovic Expires 25 November 2026 [Page 24]