Groundmark Attestation Framework and Identity Service Provider Profile
draft-noss-jeftovic-groundmark-attestation-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-attestation-00
Independent Submission E. Noss
Internet-Draft Groundmark
Intended status: Experimental M. Jeftovic
Expires: 25 November 2026 easyDNS Technologies Inc.
24 May 2026
Groundmark Attestation Framework and Identity Service Provider Profile
draft-noss-jeftovic-groundmark-attestation-00
Abstract
This document defines the Groundmark attestation framework and the
profile of Identity Service Providers (IDSPs) that issue Groundmark
attestations. It is the companion document to the Groundmark core
protocol, which specifies DNS publication and request-signature
mechanics. This document specifies the role and obligations of
Identity Service Providers, a four-level taxonomy of attestation
strength, an initial vocabulary of claim types, the JSON schema and
signature construction for attestation payloads, the method-
disclosure discipline that defines an IDSP's accountability
obligation, and revocation semantics for the attestation layer.
The core protocol document defines the discovery mechanisms (the
_agentclaim DNS TXT record and the HTTP retrieval of attestation
payloads) on which this document depends. Together the two documents
specify Groundmark.
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 Attestation 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. Relationship to the Core Protocol . . . . . . . . . . . . 4
1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 4
1.3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. The Identity Service Provider Role . . . . . . . . . . . . . 6
3.1. Method Disclosure . . . . . . . . . . . . . . . . . . . . 7
3.2. IDSP Trust Anchors . . . . . . . . . . . . . . . . . . . 7
4. Attestation Level Taxonomy . . . . . . . . . . . . . . . . . 8
4.1. Level 0 - Permissionless . . . . . . . . . . . . . . . . 8
4.2. Level 1 - Operator Accountability . . . . . . . . . . . . 8
4.3. Level 2 - Claim-Specific Verification . . . . . . . . . . 9
4.4. Level 3 - Regulatory-Grade . . . . . . . . . . . . . . . 9
4.5. Level Stacking and Composability . . . . . . . . . . . . 10
5. Claim Type Vocabulary . . . . . . . . . . . . . . . . . . . . 10
5.1. operator-verified . . . . . . . . . . . . . . . . . . . . 10
5.2. age-over-18, age-over-21 . . . . . . . . . . . . . . . . 11
5.3. jurisdiction-licensed . . . . . . . . . . . . . . . . . . 11
5.4. kyc-basic . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5. kyc-enhanced . . . . . . . . . . . . . . . . . . . . . . 12
5.6. operator-contact . . . . . . . . . . . . . . . . . . . . 12
6. Attestation Payload Schema . . . . . . . . . . . . . . . . . 13
6.1. Transport and Caching . . . . . . . . . . . . . . . . . . 13
6.2. Top-Level Fields . . . . . . . . . . . . . . . . . . . . 13
6.3. The method_disclosure Object . . . . . . . . . . . . . . 15
6.4. Worked Example . . . . . . . . . . . . . . . . . . . . . 15
7. Signature Construction and Verification . . . . . . . . . . . 16
7.1. Verification Steps . . . . . . . . . . . . . . . . . . . 17
8. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Fail-Mode Behaviour . . . . . . . . . . . . . . . . . . . 18
8.2. Audit Logging of Fail-Open Decisions . . . . . . . . . . 19
8.3. Short-Lived Status Tokens . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Endpoint Portability Attacks . . . . . . . . . . . . . . 20
Noss & Jeftovic Expires 25 November 2026 [Page 2]
Internet-Draft Groundmark Attestation May 2026
9.2. Display Name Impersonation . . . . . . . . . . . . . . . 20
9.3. Cross-Claim Consistency . . . . . . . . . . . . . . . . . 21
9.4. IDSP Compromise . . . . . . . . . . . . . . . . . . . . . 21
9.5. Denial of Service via Revocation Endpoint . . . . . . . . 21
9.6. Method Disclosure Misrepresentation . . . . . . . . . . . 22
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
10.1. Minimal Disclosure by Construction . . . . . . . . . . . 22
10.2. Public Visibility of Attestation Existence . . . . . . . 22
10.3. Linkability Across Relying Parties . . . . . . . . . . . 23
11. Governance Considerations . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12.1. Groundmark Claim Types Registry . . . . . . . . . . . . 24
12.2. Groundmark Method Identifier Registry . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
-00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
The Groundmark core protocol [I-D.noss-jeftovic-groundmark-core]
specifies how an agent's signing public key and references to
externally hosted attestations are published in DNS, and how relying
parties verify HTTP request signatures using the published key. The
core protocol intentionally treats attestation content as opaque: DNS
publishes a reference, the relying party retrieves it over HTTPS, and
the question of what an attestation says and how it should be
evaluated is deferred to this document.
This document specifies that evaluation framework. It defines:
* The role of an Identity Service Provider (IDSP), an entity that
verifies a claim about an operator or agent and publishes a signed
attestation under the Groundmark framework.
* A four-level taxonomy of attestation strength, from cryptographic-
only Level 0 through regulatory-grade Level 3.
* An initial vocabulary of claim types, with structured value
schemas and registration policy for extensions.
* The JSON schema and canonical signature construction for an
attestation payload served at a "ref=" URL.
Noss & Jeftovic Expires 25 November 2026 [Page 3]
Internet-Draft Groundmark Attestation May 2026
* The method-disclosure obligation: an IDSP's primary duty is to
accurately characterize the verification it performed, not to
assert a conclusion. This obligation is what makes Groundmark
attestations evaluable rather than reducible to brand recognition.
* Revocation semantics specific to the attestation layer, including
fail-mode behaviour for unreachable revocation endpoints.
The design is informed by Kim Cameron's Laws of Identity
[Cameron2005], reframed for a setting in which the principal whose
identity is being attested is an organizational operator (or, in the
individual-operator case, a hosted-identity provider) rather than a
human individual interacting directly.
1.1. Relationship to the Core Protocol
This document depends on the core protocol
[I-D.noss-jeftovic-groundmark-core] for:
* DNS record format and publication for _agentclaim records.
* DNSSEC requirements for all Groundmark DNS lookups.
* The HTTPS retrieval transport for attestation payloads.
* Request-signature mechanics, against which an attestation is
ultimately evaluated.
A relying party implementing Groundmark MUST implement the core
protocol. Implementing this document additionally is OPTIONAL: a
relying party may choose to require only signature verification
(Level 0) without evaluating attestations, in which case the
mechanisms in this document are not exercised. The core protocol's
permissionless default mode remains available to all participants.
1.2. Design Principles
The framework defined here is shaped by three principles, in addition
to those stated in the core protocol.
* Authenticate the minimum necessary. The right attestation level
for any transaction is the lowest that meets the relying party's
legitimate risk profile. The framework is designed so that most
transactions can proceed at Level 0; higher levels are available
but not encouraged.
Noss & Jeftovic Expires 25 November 2026 [Page 4]
Internet-Draft Groundmark Attestation May 2026
* IDSPs attest to methods, not conclusions. An IDSP's primary
accountability obligation is to characterize what verification it
performed and to stake its reputation on the accuracy of that
characterization. The trust decision belongs to the relying
party. This is what allows a relying party to make a contextual
judgment rather than a binary accept/reject decision based on the
IDSP's brand alone.
* No single point of control. The framework permits a diversity of
IDSPs operating under different trust frameworks, jurisdictions,
and competence areas. No central authority designates which IDSPs
are authoritative. Recognition of an IDSP for any specific
purpose is a property of the relying party's policy and, where
applicable, the relying party's regulatory framework.
1.3. Non-Goals
This document does not:
* Designate, certify, or otherwise centrally validate IDSPs. The
framework specifies what an IDSP does and the obligations it
accepts; recognition is a matter of relying-party policy or
external trust framework.
* Define the substantive content of any specific regulatory
framework. Level 3 attestations may exist within frameworks (for
example, FINTRAC PCMLTFA for Canadian KYC, or applicable
professional licensing regimes); this document specifies how a
Level 3 attestation is structured and verified, not the underlying
regulatory standard.
* Replace any existing credential or attestation system. An IDSP
MAY use Verifiable Credentials, JWTs, or other formats internally;
the Groundmark attestation payload is the format in which an
attestation is presented to a Groundmark relying party.
1.4. 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.
Noss & Jeftovic Expires 25 November 2026 [Page 5]
Internet-Draft Groundmark Attestation May 2026
2. Terminology
The terminology of the core protocol
[I-D.noss-jeftovic-groundmark-core] applies. The following
additional terms are used in this document.
Attestation A signed statement by an IDSP that a specific claim
about an operator or agent has been verified to a stated standard
using stated methods. Serialized as a JSON document per
Section 6.
Claim A bounded predicate about an operator or agent that an
attestation verifies (for example, "the operator has passed
FINTRAC tier-basic KYC", or "the operator holds an active real-
estate licence in Ontario, Canada").
Claim Type A registered identifier denoting the predicate structure
of a claim. The initial vocabulary is defined in Section 5.
Identity Service Provider (IDSP) A trusted third party that performs
verification of a claim and publishes a signed attestation.
Defined more fully in Section 3.
Level An integer from 0 to 3 indicating the strength of verification
associated with a Groundmark attestation, as defined in Section 4.
Method Disclosure The structured description, present in every
Groundmark attestation, of the verification methods the IDSP
engaged. Defined in Section 3.1.
Relying Party As in the core protocol. In this document's context,
a relying party evaluating attestations decides which IDSPs it
trusts and for what purposes, and which attestation levels and
claim types it requires.
3. The Identity Service Provider Role
An IDSP under Groundmark is an entity that:
1. Performs verification of a specific claim about an operator or
agent, using methods the IDSP discloses in each attestation it
issues.
2. Publishes attestations as signed JSON documents over HTTPS, at
the URLs referenced by _agentclaim "ref=" fields.
Noss & Jeftovic Expires 25 November 2026 [Page 6]
Internet-Draft Groundmark Attestation May 2026
3. Publishes its own signing public key in DNS using the _agentid
convention defined by the core protocol, under a DNSSEC-signed
zone.
4. Operates a revocation mechanism per Section 8.
Any person, organization, or institution with appropriate competence
may operate as an IDSP for claims within its competence. No central
designation is required. Recognition of an IDSP by a relying party,
or by a regulatory framework whose requirements a relying party is
attempting to satisfy, is independent of this specification.
3.1. Method Disclosure
An IDSP's primary obligation under Groundmark is method disclosure:
each attestation MUST contain a structured description of the
verification methods the IDSP performed. This obligation is what
distinguishes an IDSP from a conventional certificate authority. A
certificate authority asserts a conclusion ("this entity controls
this domain"); a Groundmark IDSP asserts a conclusion together with a
disclosure of how that conclusion was reached, allowing the relying
party to make a contextual trust decision.
The structure of the method_disclosure object is specified in
Section 6.3. The IDSP is responsible for the accuracy of this
disclosure; misrepresentation of methods is the principal failure
mode against which the IDSP's reputation is exposed.
3.2. IDSP Trust Anchors
This document does not specify how a relying party comes to trust a
specific IDSP for a specific purpose. The expected mechanisms
include:
* Direct evaluation by the relying party of an IDSP's public
practices statement, audit reports, and method disclosures.
* Recognition by a regulator or industry body whose rules the
relying party operates under.
* Inclusion in a curated list maintained by a community or trust
framework operator.
These are out of scope for this specification. What this
specification provides is the substrate that makes any of these
evaluation modes possible: every Groundmark attestation includes the
IDSP's identity, the methods it performed, and the cryptographic
material needed to verify the IDSP's signature.
Noss & Jeftovic Expires 25 November 2026 [Page 7]
Internet-Draft Groundmark Attestation May 2026
4. Attestation Level Taxonomy
Groundmark defines four attestation levels indicating the strength of
verification associated with a claim. The level is a floor, not a
ceiling: a relying party requiring Level 1 MAY accept a Level 2 or
Level 3 attestation for the same claim type. A relying party
requiring Level 2 MUST NOT accept a Level 1 attestation in its place.
The levels do not aggregate. Three Level 2 attestations do not
constitute a Level 3 attestation. Each claim stands on its own
merits.
4.1. Level 0 - Permissionless
No attestation required. The relying party verifies an HTTP request
signature against the agent's DNS-published key per the core
protocol; domain ownership establishes the accountability chain
through DNS and (if DNSSEC-validated) through the registrar-verified
registrant.
This is the default mode under Groundmark and is expected to cover
the majority of agent transactions. Self-asserted _agentclaim
records using the "val=" form (for example, operator-contact) are
Level 0 disclosures: they are operator assertions, not third-party
verifications.
A relying party operating at Level 0 CAN conclude that the request
originated from a party that controls the agent domain. It CANNOT
conclude anything about the operator's identity, legal standing,
location, or compliance.
4.2. Level 1 - Operator Accountability
A real, identifiable party stands behind the agent. Level 1
establishes that an operator exists, that the operator demonstrably
controls the agent domain, and that the operator has accepted
accountability under the IDSP's trust framework. The claim is about
existence and accountability, not capability or compliance: if
something goes wrong, there is a known party to contact.
Required verification, performed by the IDSP:
* Operator existence: the operator is a real person or organization.
* Operational control: the operator demonstrably controls the agent
domain.
Noss & Jeftovic Expires 25 November 2026 [Page 8]
Internet-Draft Groundmark Attestation May 2026
* Acceptance of terms: the operator has agreed to the IDSP's
accountability framework.
Acceptable methods are at the IDSP's discretion subject to the
method-disclosure obligation. Typical methods include business
registration lookup, confirmation messaging to an organizational
domain, or credential binding to a verified account.
A relying party operating at Level 1 CAN conclude that an
identifiable operator is accountable for the agent's actions, and
that the operator accepted terms establishing accountability. It
CANNOT conclude that the operator is compliant with any specific
regulation or legal standard.
4.3. Level 2 - Claim-Specific Verification
A bounded, specific fact about the operator or agent has been
attested. Each Level 2 attestation is a single predicate: "the
operator is over 18", "the operator holds a valid Ontario real estate
licence", "the agent has passed basic financial-services onboarding".
The minimal-disclosure principle is operationally critical at this
level: the IDSP attests to the predicate, not to the underlying data.
A relying party operating at Level 2 CAN conclude that the stated
predicate was verified by a third party to the standard disclosed,
and that the IDSP staked its reputation on the accuracy of the
attestation. It CANNOT conclude that the claim satisfies a
regulatory requirement without also verifying that the IDSP and its
methods are recognised by the relevant regulator.
4.4. Level 3 - Regulatory-Grade
The attestation meets a specific legal or regulatory standard. Level
3 covers claims that must meet defined legal or regulatory
requirements such as Know Your Customer / Anti-Money Laundering
verification under a named framework, professional licensure verified
against government records, or biometric identity proofing under a
named assurance level.
A Level 3 attestation MUST carry the "framework" field (Section 6.2)
identifying the regulatory or trust framework under which the
attestation is issued. It MUST carry the "jurisdiction" field where
the framework is jurisdictionally scoped.
A relying party operating at Level 3 CAN rely on the attestation to
satisfy its own regulatory obligations where the relevant trust
framework explicitly permits such reliance. The relying party MUST
verify that the named IDSP is recognized by the relevant regulator or
Noss & Jeftovic Expires 25 November 2026 [Page 9]
Internet-Draft Groundmark Attestation May 2026
framework before relying on a Level 3 attestation for compliance
purposes; this specification does not designate any IDSP as
authoritative for any framework.
4.5. Level Stacking and Composability
An agent identity MAY carry multiple _agentclaim records
simultaneously, each independent. A single agent might present a
Level 1 operator-verified attestation alongside several Level 2
claim-specific attestations from different IDSPs. The relying party
selects only the claims its policy requires.
Multiple attestations from different IDSPs do not implicitly refer to
the same underlying operator identity, since IDSPs do not coordinate
with one another. Section 9.3 addresses this limitation.
5. Claim Type Vocabulary
This section defines the initial vocabulary of claim types. Each
claim type specifies the JSON structure of the claim_value field in
an attestation payload (Section 6).
Custom claim types MUST use the form "x-<registrant-domain>-<claim-
name>", where <registrant-domain> is a domain controlled by the
entity defining the claim type. Custom claim types do not require
IANA registration; relying parties MUST ignore claim types they do
not recognize, per the core protocol.
Claim types intended for broad interoperability SHOULD be registered
in the IANA Groundmark Claim Types registry established by this
document (Section 12).
5.1. operator-verified
Level: 1.
The IDSP has verified that a real, identifiable operator controls the
agent and has accepted the IDSP's accountability terms.
claim_value:
{
"verified": true,
"operator_display_name": "Acme Corp"
}
Noss & Jeftovic Expires 25 November 2026 [Page 10]
Internet-Draft Groundmark Attestation May 2026
"verified" is REQUIRED and MUST be true (an attestation with
verified=false MUST NOT be issued; such a record should be absent,
or, if previously present, revoked).
"operator_display_name" is OPTIONAL and SHOULD only be included if
the operator has explicitly chosen to disclose it publicly. Relying
parties MUST NOT use operator_display_name as the sole basis of any
trust or access-control decision. See Section 9.2.
5.2. age-over-18, age-over-21
Level: 2.
The operator meets the specified age threshold. The claim value is a
boolean predicate; the operator's actual age or date of birth is not
disclosed.
claim_value:
{ "result": true }
5.3. jurisdiction-licensed
Level: 2 or 3, depending on the IDSP's method and the framework under
which it is operating.
The operator holds a valid licence in a named jurisdiction and
practice category. The licence number MUST NOT be included in the
claim value.
claim_value:
{
"licensed": true,
"jurisdiction": "CA-ON",
"licence_category": "real-estate-agent",
"licence_status": "active"
}
"jurisdiction" uses the conventional country-subdivision form (ISO
3166-1 alpha-2, optionally followed by "-" and an ISO 3166-2
subdivision code).
When this claim is published as a Level 3 attestation, the top-level
"framework" field of the attestation MUST identify the regulatory
licensing framework.
Noss & Jeftovic Expires 25 November 2026 [Page 11]
Internet-Draft Groundmark Attestation May 2026
5.4. kyc-basic
Level: 2 or 3.
The operator has passed a basic Know Your Customer screening.
claim_value:
{
"passed": true,
"framework": "FINTRAC-PCMLTFA",
"tier": "basic"
}
The "framework" field inside claim_value is REQUIRED for this claim
type and identifies the screening framework applied. When the
attestation is Level 3, the top-level "framework" field MUST also be
present and SHOULD match the claim_value "framework".
5.5. kyc-enhanced
Level: 3.
The operator has passed an enhanced KYC process, including source-of-
funds verification or equivalent under the named framework.
claim_value:
{
"passed": true,
"framework": "FINTRAC-PCMLTFA",
"tier": "enhanced"
}
5.6. operator-contact
Level: 0 (self-asserted).
A self-declared contact point. This claim type MAY be published
directly in a _agentclaim record using "val=" without a "ref=" URL or
"idsp=", per the core protocol. Relying parties MUST treat it as
unverified self-assertion.
claim_value (when retrieved as an IDSP-issued attestation, which is
uncommon for this claim type):
Noss & Jeftovic Expires 25 November 2026 [Page 12]
Internet-Draft Groundmark Attestation May 2026
{
"contact_type": "email",
"value": "ops@acmecorp.example"
}
6. Attestation Payload Schema
This section defines the JSON document served by an IDSP at the URL
referenced by an _agentclaim "ref=" field.
6.1. Transport and Caching
The transport for attestation retrieval is HTTPS, per the core
protocol. Additional requirements specific to the attestation layer:
* IDSPs MUST serve attestation payloads with Content-Type:
application/json (or application/jose+json for Verifiable
Credential or JWT-bearing variants under future extensions).
* IDSPs MUST require no authentication from the relying party. The
"ref=" URL functions as an opaque bearer reference.
* IDSPs MUST validate TLS at the transport layer per the underlying
HTTPS implementation; relying parties MUST validate the
attestation endpoint's TLS certificate per [RFC9110].
* IDSPs MUST set HTTP Cache-Control directives [RFC9111] consistent
with the attestation's expires_at time. IDSPs MUST NOT set max-
age values so short as to force effectively per-request
revalidation; the framework is designed for cached retrieval, and
IDSPs that operate the revocation endpoint as a per-transaction
authentication gate create a denial-of-service vector against the
relying-party population (see Section 9.5).
* Relying parties MAY cache attestation payloads up to the lesser of
the IDSP-supplied max-age and the attestation's expires_at time.
6.2. Top-Level Fields
The attestation is a flat JSON [RFC8259] object using snake_case
field names. The following fields are defined.
schema_version (REQUIRED, string) Schema version. The current value
is "1.0". Relying parties SHOULD reject schema versions they do
not understand.
subject (REQUIRED, string) The agent domain this attestation covers,
as a fully qualified domain name in lowercase ASCII.
Noss & Jeftovic Expires 25 November 2026 [Page 13]
Internet-Draft Groundmark Attestation May 2026
claim_type (REQUIRED, string) A value from the claim type vocabulary
in Section 5, a vendor extension of the form "x-<registrant-
domain>-<claim-name>", or an IANA-registered extension.
claim_value (REQUIRED, object) The minimal predicate value.
Structure is determined by claim_type.
level (REQUIRED, integer) The attestation level (0 through 3).
Relying parties MUST reject attestations whose level is below the
level required by the relying party's policy.
idsp (REQUIRED, string) The IDSP's domain name. The IDSP's public
signing key MUST be retrievable via the core-protocol _agentid
convention at _agentid.<idsp>.
issued_at (REQUIRED, string) The time at which the attestation was
issued, formatted per [RFC3339].
expires_at (REQUIRED, string) The time at which the attestation
expires, formatted per [RFC3339]. Relying parties MUST reject
attestations whose expires_at is in the past.
method_disclosure (REQUIRED, object) Structured description of the
verification the IDSP performed. See Section 6.3.
endpoint_url (REQUIRED, string) The canonical HTTPS URL at which
this attestation is served. MUST match the "ref=" URL in the
corresponding _agentclaim record. Bound into the signed payload
to prevent portability attacks (see Section 9.1).
revocation_endpoint (REQUIRED, string) HTTPS URL for revocation
status. Returns { "revoked": true | false }. See Section 8.
signing_key_id (REQUIRED, string) Identifier of the IDSP signing key
used. Matches the "kid=" value of the corresponding _agentid
record at the IDSP's domain.
signature (REQUIRED, string) Base64url-encoded [RFC4648] Ed25519
signature over the canonical payload. See Section 7.
jurisdiction (OPTIONAL, string) Applicable jurisdiction. REQUIRED
at Level 3 when the framework is jurisdictionally scoped.
framework (OPTIONAL, string) Named regulatory or trust framework.
REQUIRED at Level 3.
short_lived_token (OPTIONAL, object) A short-lived signed status
token analogous to certificate stapling. See Section 8.3.
Noss & Jeftovic Expires 25 November 2026 [Page 14]
Internet-Draft Groundmark Attestation May 2026
6.3. The method_disclosure Object
methods (REQUIRED, array of strings) An array of method identifiers,
each drawn from the Groundmark Method Identifier registry
established by this document (Section 12). Implementations MUST
tolerate identifiers they do not recognize.
method_detail (OPTIONAL, string) Free-text description providing
additional context. Intended for human review, not machine
parsing.
subcontractors (OPTIONAL, array of strings) Domain names of any
third-party services engaged in the verification. Present when
the IDSP subcontracted part of the verification.
evidence_class (OPTIONAL, array of strings) An array of evidence-
class identifiers from the Groundmark Method Identifier registry,
indicating the categories of evidence the IDSP examined (for
example, "government-issued-id", "corporate-registry", "biometric-
liveness"). The initial set is defined in the registry;
community-defined extensions follow the registry's policy.
6.4. Worked Example
The following non-normative example illustrates the JSON payload
served by an IDSP at the URL referenced by an _agentclaim "ref="
field. It is the Level 1 operator-verified attestation referenced by
the worked example in the core protocol.
Noss & Jeftovic Expires 25 November 2026 [Page 15]
Internet-Draft Groundmark Attestation May 2026
{
"schema_version": "1.0",
"subject": "purchasing.acmecorp.example",
"claim_type": "operator-verified",
"claim_value": {
"verified": true,
"operator_display_name": "Acme Corp"
},
"level": 1,
"idsp": "verify.example.net",
"issued_at": "2026-05-19T12:00:00Z",
"expires_at": "2026-12-01T00:00:00Z",
"method_disclosure": {
"methods": [
"corporate-registry-lookup",
"organizational-domain-email-confirmation"
],
"method_detail":
"Operator legal entity confirmed against the Ontario
Business Registry; domain control confirmed by email
challenge to postmaster@acmecorp.example.",
"evidence_class": [
"corporate-registry",
"domain-control"
]
},
"endpoint_url":
"https://verify.example.net/a/4f9f3e1c7ab93d4f8d22",
"revocation_endpoint":
"https://verify.example.net/r/4f9f3e1c7ab93d4f8d22",
"signing_key_id": "k1",
"signature": "MEUCIQ...base64url...=="
}
The IDSP's signing public key is published at
_agentid.verify.example.net. The relying party retrieves it via a
DNSSEC-validating resolver, selects the record with kid=k1,
reconstructs the canonical payload using [RFC8785] on the object with
the signature field removed, and verifies the Ed25519 signature
against the IDSP's public key.
7. Signature Construction and Verification
Attestation signatures use Ed25519 [RFC8032]. The signature is
computed over a canonical serialization of the attestation payload
with the signature field removed.
Noss & Jeftovic Expires 25 November 2026 [Page 16]
Internet-Draft Groundmark Attestation May 2026
The canonical serialization is JSON Canonicalization Scheme [RFC8785]
applied to the attestation payload object, omitting the signature
key. JCS provides a deterministic byte sequence regardless of input
ordering or whitespace, removing a class of canonicalization bugs.
The IDSP's public key is published in DNS using the _agentid.<idsp-
domain> convention defined by the core protocol. IDSPs MUST sign
their zones with DNSSEC. A public key retrieved from a non-DNSSEC-
signed zone MUST NOT be used for attestation verification. The
signing_key_id field in the attestation identifies which of the
IDSP's keys was used; this corresponds to the "kid=" field in the
IDSP's _agentid record.
7.1. Verification Steps
A relying party verifying an attestation payload MUST:
1. Confirm that schema_version is understood.
2. Confirm that expires_at is in the future.
3. Confirm that endpoint_url matches the "ref=" URL from which the
attestation was retrieved. Reject otherwise (see Section 9.1).
4. Confirm that level meets or exceeds the relying party's policy
floor.
5. Retrieve the IDSP's _agentid record(s) from DNS using a DNSSEC-
validating resolver. Select the record matching signing_key_id.
Reject if no such record exists, if DNSSEC validation fails, or
if the IDSP zone is unsigned.
6. Compute the canonical serialization per [RFC8785] on the payload
with signature removed.
7. Verify the Ed25519 signature using the IDSP's public key.
8. Check the revocation_endpoint according to the rules in
Section 8.
8. Revocation
Two independent revocation mechanisms operate at the attestation
layer, in addition to DNS-level revocation provided by the core
protocol (deletion of the _agentclaim record).
DNS-layer revocation (under the core protocol) Removal of the
_agentclaim record invalidates the claim within the record's TTL.
Noss & Jeftovic Expires 25 November 2026 [Page 17]
Internet-Draft Groundmark Attestation May 2026
Endpoint-layer revocation The IDSP marks a specific attestation as
revoked at its revocation_endpoint. The agent identity remains
usable; only the specific claim is revoked. This is appropriate
when an operator's standing changes with respect to a single claim
without affecting the underlying identity.
The revocation endpoint response is structurally minimal:
{ "revoked": true }
or
{ "revoked": false }
IDSPs MAY include additional fields (revoked_at, reason) but MUST
include the boolean revoked field as defined. Relying parties MUST
NOT require additional fields.
The revocation endpoint MUST NOT require authentication from the
relying party. IDSPs MUST NOT use the revocation endpoint as a per-
transaction authentication gate (see Section 9.5).
8.1. Fail-Mode Behaviour
When the revocation endpoint is unreachable, relying parties MUST
apply the following fail behaviour, scaled by attestation level:
Level 3 Relying parties MUST fail closed. An unreachable revocation
endpoint MUST be treated as a verification failure and the
transaction declined. Continuing under Level 3 without a current
revocation check is a non-conformant deployment.
Level 2 Relying parties MUST fail closed UNLESS all of the following
hold: the attestation was issued less than 24 hours before the
current time, the relying party's policy permits soft-fail at
Level 2 under this transaction's risk profile, and the relying
party logs the soft-fail per Section 8.2.
Level 1 Relying parties MAY fail open subject to the logging
requirements of Section 8.2. Fail-open is permitted at Level 1
because the underlying claim is operator-accountability rather
than compliance: the worst-case consequence of an erroneously
accepted Level 1 attestation is materially different from the
worst-case consequence at higher levels.
Noss & Jeftovic Expires 25 November 2026 [Page 18]
Internet-Draft Groundmark Attestation May 2026
8.2. Audit Logging of Fail-Open Decisions
Fail-open behaviour at any level MUST be logged. The logging
requirements below are the minimum; relying parties may impose
additional requirements under their own policies.
The fail-open log entry MUST include:
* The agent domain and the attestation's endpoint_url.
* The idsp, claim_type, and level from the attestation.
* The reason for fail-open (typically: revocation endpoint
unreachable, with an indication of the failure mode).
* The time of the decision.
* The identity of the transaction or operation that proceeded under
fail-open.
The log MUST be retained by the relying party for a period not less
than one year, or for the period required by any applicable
regulatory framework, whichever is longer. The log SHOULD be
available to the IDSP on reasonable request, since an unexpected
pattern of fail-open events on a particular IDSP is operationally
significant to both parties.
8.3. Short-Lived Status Tokens
Real-time revocation checks against an IDSP endpoint introduce the
same class of operational fragility as OCSP. To mitigate this
without reintroducing OCSP's worst failure modes, an IDSP MAY include
a short_lived_token field in the attestation payload, analogous to
certificate stapling.
A short-lived status token is a signed assertion of the form:
{
"status": "active",
"as_of": "2026-05-19T12:00:00Z",
"valid_until": "2026-05-19T18:00:00Z",
"signature": "<base64url-ed25519>"
}
The token is signed by the same IDSP signing key as the parent
attestation, over the canonical serialization of the token object
with signature removed.
Noss & Jeftovic Expires 25 November 2026 [Page 19]
Internet-Draft Groundmark Attestation May 2026
When a current short-lived status token is present and valid, the
relying party MAY treat it as a substitute for a fresh
revocation_endpoint check during the token's validity window. The
relying party MUST NOT extend the token's effective validity past
valid_until. Token validity windows SHOULD be no longer than 24
hours; IDSPs that issue longer-lived tokens defeat the purpose of the
mechanism.
IDSPs MAY rotate tokens by re-serving the attestation payload with an
updated short_lived_token; the rest of the payload (and its
signature) is unchanged. Relying parties caching the attestation
SHOULD periodically re-fetch to obtain refreshed tokens; this is
substantially cheaper than full revocation checks.
9. Security Considerations
9.1. Endpoint Portability Attacks
The endpoint_url field in the canonical payload binds an attestation
to the specific URL at which it is served. Without this binding, an
attacker who obtained a valid attestation payload (perhaps by
previously serving as the IDSP under a since-decommissioned identity)
could serve that payload at a different location and have it accepted
by relying parties. Including endpoint_url in the signed canonical
payload prevents this attack. Relying parties MUST verify the
endpoint_url match per Section 7.1; this is not optional.
9.2. Display Name Impersonation
The operator_display_name field in operator-verified attestations is
operator-chosen and self-asserted. The IDSP attesting that the
operator exists and is accountable does not, by default, verify that
the chosen display name is accurate or non-deceptive.
Relying parties MUST NOT use operator_display_name as the basis of
trust or access-control decisions. The field is a UI affordance
only.
Future versions of this specification may require IDSPs to validate
display names against protected brand-name lists as a condition of
Level 1 attestation. Such a requirement is out of scope for this
document, but the field's presence in the schema provides a hook for
such future requirements.
Noss & Jeftovic Expires 25 November 2026 [Page 20]
Internet-Draft Groundmark Attestation May 2026
9.3. Cross-Claim Consistency
A single agent may carry attestations from multiple IDSPs that
implicitly refer to different underlying operator identities, since
IDSPs do not coordinate with one another. A relying party evaluating
two claims from two different IDSPs cannot, in general, determine
whether both claims describe the same operator.
For high-assurance transactions requiring multiple claims, relying
parties SHOULD prefer attestations from a single IDSP where possible.
Future versions of this specification may define a subject_handle
field that allows IDSPs to identify a stable operator handle within a
single trust framework, enabling cross-claim consistency checks.
This is out of scope for this document.
9.4. IDSP Compromise
Compromise of an IDSP's signing key permits an attacker to issue
fraudulent attestations until the corresponding _agentid record at
the IDSP's domain is removed and caches expire. IDSPs MUST treat
their signing keys with the same operational discipline as
certificate-authority signing keys, including hardware key storage
and audit-grade access controls. An IDSP SHOULD prepare for
emergency key rotation per the procedure defined in the core
protocol, and SHOULD pre-announce key rotation policy in its public
practices statement.
A compromised IDSP signing key invalidates all attestations signed
under that key. There is no fine-grained recovery: relying parties
detecting an IDSP key compromise SHOULD treat all attestations under
that key as unverifiable until the key is rotated and the affected
attestations are re-issued.
9.5. Denial of Service via Revocation Endpoint
The revocation endpoint is a relying-party-facing service consulted
on a substantial fraction of attestations. IDSPs that operate it as
an authenticated, throttled, or per-relying-party-rate-limited
service shift operational fragility onto the entire relying-party
population. This document REQUIRES the revocation endpoint to be
unauthenticated, structurally minimal, and operated at a service
quality appropriate to its function in the trust framework. IDSPs
that do not meet this requirement create a denial-of-service vector
against deployments depending on their attestations.
Noss & Jeftovic Expires 25 November 2026 [Page 21]
Internet-Draft Groundmark Attestation May 2026
9.6. Method Disclosure Misrepresentation
The method_disclosure object is the central accountability locus of
the IDSP role. An IDSP that misrepresents its methods - claiming
verification it did not perform, omitting subcontractors, or
misstating evidence classes - undermines the trust framework that
makes its attestations evaluable. There is no cryptographic
mechanism that detects this; the discipline depends on the relying
party's, and the broader community's, ability to evaluate IDSP
practices and on the IDSP's reputational exposure to inaccurate
disclosure. Trust frameworks that recognize specific IDSPs SHOULD
require audit of method-disclosure accuracy as a condition of
recognition.
10. Privacy Considerations
This document inherits the privacy considerations of the core
protocol [I-D.noss-jeftovic-groundmark-core], and is shaped by the
guidance of [RFC6973]. The following considerations are specific to
the attestation layer.
10.1. Minimal Disclosure by Construction
The claim-value structures in Section 5 are deliberately minimal.
age-over-18 discloses a boolean, not a date of birth. jurisdiction-
licensed discloses the existence and category of a licence in a named
jurisdiction, not the licence number. kyc-basic and kyc-enhanced
disclose only that the relevant screening was performed under a named
framework.
Custom claim types defined under the "x-<registrant-domain>-<claim-
name>" extension mechanism SHOULD follow the same discipline. Claim
types that would require disclosure of richer personal data SHOULD be
considered carefully against the minimal-disclosure principle and,
where possible, decomposed into bounded predicates.
10.2. Public Visibility of Attestation Existence
What is publicly visible in DNS for a given agent is the existence of
an attestation of a given claim_type from a named idsp, plus the
high-entropy "ref=" URL. The claim value itself is reachable only by
following the "ref=" URL.
This is an intentional design tradeoff. Publishing the claim type
and IDSP name supports interoperability and meaningful relying-party
policy; publishing the value would either require value
confidentiality (complicating retrieval) or render claim-value
privacy moot. The recommended deployment pattern for individual
Noss & Jeftovic Expires 25 November 2026 [Page 22]
Internet-Draft Groundmark Attestation May 2026
operators concerned about this visibility is provider-hosted
identities, as discussed in the core protocol's Privacy
Considerations.
10.3. Linkability Across Relying Parties
A relying party that observes a Groundmark request signature obtains
the agent's domain and, on attestation retrieval, the attestation's
content. Multiple relying parties observing requests from the same
agent can correlate by agent domain. This is a property of DNS-
anchored identity and is not unique to Groundmark; an agent domain is
necessarily globally unique and linkable.
Operators concerned about cross-relying-party linkability SHOULD
provision per-relationship agent domains (for example, distinct
subdomains per counterparty) or use ephemeral agent domains. These
mitigations come at the cost of reduced amortization of attestation
issuance and verification, and are accordingly out of scope for the
default deployment pattern.
11. Governance Considerations
This specification permits a diversity of IDSP operators, trust
frameworks, and jurisdictional regimes. It does not designate any of
them.
The framework's accountability properties depend on the existence of
mechanisms - external to this specification - for evaluating IDSPs.
Such mechanisms may include:
* Industry-specific trust frameworks (analogous to those operated
for payment networks, professional licensing bodies, or
certificate-authority root programs).
* Regulator-recognized IDSP rosters for specific compliance purposes
(for example, recognized KYC providers under a given AML regime).
* Community-curated lists of IDSPs evaluated for specific purposes.
* Direct evaluation by relying parties of an IDSP's public practices
statement, audit reports, and method-disclosure accuracy.
The Groundmark framework supports all of these because every
attestation carries the IDSP's identity, the methods performed, and
the cryptographic material needed to verify the attestation. What
this specification provides is the technical substrate that makes
governance possible; the governance itself is the work of trust
frameworks and the broader community.
Noss & Jeftovic Expires 25 November 2026 [Page 23]
Internet-Draft Groundmark Attestation May 2026
12. IANA Considerations
12.1. Groundmark Claim Types Registry
IANA is requested to establish a new registry titled "Groundmark
Claim Types" under a new "Groundmark" registry group.
Registration policy: Specification Required, per [RFC8126]. The
designated expert SHOULD evaluate proposed registrations for:
* Adherence to the minimal-disclosure principle.
* Clarity of the claim_value schema.
* Compatibility with the level taxonomy.
The initial registry contents are the claim types defined in
Section 5:
+=======================+==========+===============+
| Claim Type | Level(s) | Reference |
+=======================+==========+===============+
| operator-verified | 1 | This document |
+-----------------------+----------+---------------+
| age-over-18 | 2 | This document |
+-----------------------+----------+---------------+
| age-over-21 | 2 | This document |
+-----------------------+----------+---------------+
| jurisdiction-licensed | 2, 3 | This document |
+-----------------------+----------+---------------+
| kyc-basic | 2, 3 | This document |
+-----------------------+----------+---------------+
| kyc-enhanced | 3 | This document |
+-----------------------+----------+---------------+
| operator-contact | 0 | This document |
+-----------------------+----------+---------------+
Table 1: Initial Groundmark Claim Types
12.2. Groundmark Method Identifier Registry
IANA is requested to establish a new registry titled "Groundmark
Method Identifiers" under the "Groundmark" registry group.
Registration policy: Specification Required, per [RFC8126].
Noss & Jeftovic Expires 25 November 2026 [Page 24]
Internet-Draft Groundmark Attestation May 2026
The initial registry contents are reserved for community development
and will be populated by an early companion specification defining
the verification method vocabulary. Examples of expected initial
entries include "corporate-registry-lookup", "government-issued-id",
"biometric-liveness", "domain-control-acme", and "organizational-
domain-email-confirmation".
13. References
13.1. Normative References
[I-D.noss-jeftovic-groundmark-core]
Noss, E. and M. Jeftovic, "DNS-Anchored Identity Discovery
for Autonomous Agents", Work in Progress, Internet-Draft,
draft-noss-jeftovic-groundmark-core-00, 2026,
<https://datatracker.ietf.org/doc/html/draft-noss-
jeftovic-groundmark-core-00>.
[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>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[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>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
Noss & Jeftovic Expires 25 November 2026 [Page 25]
Internet-Draft Groundmark Attestation May 2026
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>.
13.2. Informative References
[Cameron2005]
Cameron, K., "The Laws of Identity", May 2005,
<https://www.identityblog.com/?p=352>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
Acknowledgements
The authors thank Doc Searls for substantive review of earlier
drafts, the late Kim Cameron whose Laws of Identity [Cameron2005]
shaped the philosophical commitments of this work, and the broader
registrar, DNS, and identity communities whose infrastructure and
prior art make this approach viable.
Change Log
-00
* Initial submission as the companion to
[I-D.noss-jeftovic-groundmark-core].
* Split from the prior single-draft draft-noss-groundmark-agent-
identity-dns.
* Replaced the open-ended methods array description with explicit
reference to the Groundmark Method Identifier registry.
* Specified canonical-serialization using JCS [RFC8785], replacing
ad-hoc "lexicographically sorted keys" language.
Noss & Jeftovic Expires 25 November 2026 [Page 26]
Internet-Draft Groundmark Attestation May 2026
* Tightened revocation fail-mode semantics: prescriptive logging at
every fail-open decision; mandated unauthenticated revocation
endpoint to prevent DoS leverage.
* Added short-lived status tokens as an OPTIONAL mechanism.
* Resolved IDSP key rotation through the core protocol's "kid="
mechanism rather than as an open question.
* Added Privacy Considerations and Governance Considerations
sections.
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 27]