Merchant Identity Assertions for Autonomous Commerce
draft-anders-merchant-identity-assertions-01
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) | |
|---|---|---|---|
| Author | Robb Anders | ||
| Last updated | 2026-07-04 | ||
| 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-anders-merchant-identity-assertions-01
Network Working Group R. Anders
Internet-Draft RegisteredBrands.AI
Intended status: Informational 4 July 2026
Expires: 5 January 2027
Merchant Identity Assertions for Autonomous Commerce
draft-anders-merchant-identity-assertions-01
Abstract
Existing work helps a relying party determine whether an automated
client is authorized to initiate a transaction. This document
addresses the complementary problem: how that client can obtain a
verifiable identity statement about the merchant that will receive
the resulting payment, before the transaction is completed.
This document defines a Merchant Identity Assertion (MIA): a signed
JSON document binding a legal entity claim to a domain name. It
specifies the claims schema, the proof envelope, key discovery via a
JSON Web Key Set at a well-known URI, third-party issuance with
explicit authorization, signing and verification procedures, validity
and revocation semantics, and an optional signed Evaluation Result
Token that records the outcome of a verification check as a portable
audit artifact.
This document is informational. It defines a discovery and
verification mechanism only. It does not define trust scoring,
merchant ranking, payment authorization, or agent identity. It
complements existing agent identity and payment authorization
protocols without modifying them.
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 5 January 2027.
Anders Expires 5 January 2027 [Page 1]
Internet-Draft Merchant Identity Assertions July 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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Merchant Impersonation . . . . . . . . . . . . . . . . . 6
3.2. Absent Audit Trail . . . . . . . . . . . . . . . . . . . 7
3.3. Policy Enforcement Gap . . . . . . . . . . . . . . . . . 7
3.4. Interoperability Absence . . . . . . . . . . . . . . . . 7
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Relationship to Existing Work . . . . . . . . . . . . . . . . 9
6.1. X.509 and Web PKI . . . . . . . . . . . . . . . . . . . . 9
6.2. W3C Decentralized Identifiers and Verifiable
Credentials . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. OAuth Dynamic Client Registration . . . . . . . . . . . . 9
6.4. SPIFFE and Workload Identity . . . . . . . . . . . . . . 10
6.5. DNS-Based Identity (DANE, TLSA) . . . . . . . . . . . . . 10
7. Merchant Identity Assertion . . . . . . . . . . . . . . . . . 10
7.1. Claim Fields (Required) . . . . . . . . . . . . . . . . . 10
7.2. Claim Fields (Optional) . . . . . . . . . . . . . . . . . 11
7.3. Proof Object . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 13
7.5. Versioning . . . . . . . . . . . . . . . . . . . . . . . 13
7.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 14
8.2. Third-Party Issuer Authorization . . . . . . . . . . . . 15
9. Issuance Models and Assurance Considerations . . . . . . . . 16
9.1. Self-Issuance . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Third-Party Issuance . . . . . . . . . . . . . . . . . . 17
9.3. External Evidence . . . . . . . . . . . . . . . . . . . . 17
9.4. Relying Party Policy . . . . . . . . . . . . . . . . . . 17
10. Signing and Verification . . . . . . . . . . . . . . . . . . 18
Anders Expires 5 January 2027 [Page 2]
Internet-Draft Merchant Identity Assertions July 2026
10.1. Signing Algorithm . . . . . . . . . . . . . . . . . . . 18
10.2. Key Directory . . . . . . . . . . . . . . . . . . . . . 18
10.3. Signing Procedure . . . . . . . . . . . . . . . . . . . 19
10.4. Verification Procedure . . . . . . . . . . . . . . . . . 19
11. Freshness and Revocation . . . . . . . . . . . . . . . . . . 21
11.1. Validity Periods and Re-Issuance . . . . . . . . . . . . 21
11.2. Explicit Revocation . . . . . . . . . . . . . . . . . . 22
11.3. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 22
12. Evaluation Result Token . . . . . . . . . . . . . . . . . . . 22
12.1. Claims . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.2. Signing . . . . . . . . . . . . . . . . . . . . . . . . 23
12.3. Example . . . . . . . . . . . . . . . . . . . . . . . . 24
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
13.1. Minimal Disclosure . . . . . . . . . . . . . . . . . . . 24
13.2. Evidence URI Privacy . . . . . . . . . . . . . . . . . . 24
13.3. Relying Party Query Privacy . . . . . . . . . . . . . . 24
13.4. Issuer-Side Correlation . . . . . . . . . . . . . . . . 25
13.5. Consumer Principal Privacy . . . . . . . . . . . . . . . 25
14. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 25
14.2. Key Compromise . . . . . . . . . . . . . . . . . . . . . 26
14.3. Domain Transfer . . . . . . . . . . . . . . . . . . . . 26
14.4. Malicious Issuers . . . . . . . . . . . . . . . . . . . 26
14.5. Stale Assertions . . . . . . . . . . . . . . . . . . . . 26
14.6. Downgrade Attacks . . . . . . . . . . . . . . . . . . . 26
14.7. Third-Party Authorization Poisoning . . . . . . . . . . 27
14.8. JWT Security . . . . . . . . . . . . . . . . . . . . . . 27
14.9. Cryptographic Agility and Post-Quantum Considerations . 27
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
15.1. Well-Known URI: merchant-identity.json . . . . . . . . . 28
15.2. Well-Known URI: mia-delegation.json . . . . . . . . . . 28
15.3. Media Type: application/merchant-identity+json . . . . . 29
15.4. Media Type: application/merchant-delegation+json . . . . 29
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1. Normative References . . . . . . . . . . . . . . . . . . 30
16.2. Informative References . . . . . . . . . . . . . . . . . 32
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33
Document History . . . . . . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
The rapid growth of autonomous AI agents executing financial
transactions on behalf of human principals has created a new class of
trust requirements that existing protocols do not fully address.
Anders Expires 5 January 2027 [Page 3]
Internet-Draft Merchant Identity Assertions July 2026
Current work in agent identity -- including IETF Web Bot Auth
[WEBBOTAUTH] and payment authorization frameworks such as Visa
Trusted Agent Protocol, Mastercard Agent Pay, and the KYAPay Profile
[KYAPAY] -- provides mechanisms for a receiving system to verify that
an automated client is legitimate and authorized to transact. HTTP
Message Signatures [RFC9421] provide the cryptographic foundation on
which several of these frameworks build.
MIA is independent of these mechanisms but designed to compose with
them. A relying party MAY use Web Bot Auth or HTTP Message
Signatures to authenticate itself to the merchant's MIA endpoint, and
the merchant MAY use the same mechanisms to authenticate its inbound
transaction request from the agent. The MIA itself is fetched as a
static signed document and does not require any specific transport-
layer authentication. This independence is intentional: it allows
MIA verification to occur in deployment contexts where transport-
coupled signing is not available, while permitting transport-coupled
signing where it is.
These mechanisms answer: "Is this agent who it claims to be, and is
it authorized to pay?"
A complementary question remains unanswered by existing standards:
"Is the merchant this agent intends to pay who it claims to be?"
In human-mediated commerce, consumers evaluate merchant identity
through visual cues, brand recognition, and accumulated reputation.
Autonomous agents lack these faculties. Without a machine-readable,
cryptographically verifiable merchant identity mechanism, agents must
either trust merchant identity claims implicitly -- creating fraud
exposure -- or implement proprietary verification mechanisms that are
not interoperable.
This document defines the Merchant Identity Assertion (MIA): a
minimal, interoperable signed JSON document that enables any
autonomous agent to verify merchant identity before executing a
transaction.
The MIA is designed to:
* Be self-hostable by any merchant at a well-known URI
* Be verifiable by any agent without central registry dependency
* Complement existing agent identity protocols without replacing or
competing with them
* Support independent implementations by any party
Anders Expires 5 January 2027 [Page 4]
Internet-Draft Merchant Identity Assertions July 2026
This document does not define trust scoring algorithms, merchant
ranking systems, payment authorization protocols, or agent identity
mechanisms. Those concerns are addressed by other specifications.
2. Terminology
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.
Merchant: A legal entity offering goods or services in exchange for
payment, identified by a domain name.
Merchant Identity Assertion (MIA): A signed JSON document attesting
to the verifiable identity of a merchant entity, as defined in
Section 7.
Claims Object: The JSON object containing the identity fields of an
MIA, excluding the proof. Used as the signing input.
Proof Object: The JSON object embedded in an MIA that carries the
cryptographic signature and key reference, as defined in
Section 7.3.
Issuer: An entity that signs and publishes a Merchant Identity
Assertion. The issuer MAY be the merchant itself or a third party
acting on the merchant's behalf with explicit authorization per
Section 8.2.
Relying Party: An autonomous agent or system that consumes a
Merchant Identity Assertion to make a pre-transaction verification
decision.
Subject Domain: The fully qualified domain name (FQDN) to which the
Merchant Identity Assertion applies.
Evaluation Result Token (ERT): A signed JWT [RFC7519] issued by a
verification service summarizing the result of a pre-transaction
merchant identity check, as defined in Section 12.
Key Directory: A JSON Web Key Set [RFC7517] published at a well-
known location used to discover public keys for signature
verification.
Domain Comparison: Throughout this document, comparison of two FQDNs
Anders Expires 5 January 2027 [Page 5]
Internet-Draft Merchant Identity Assertions July 2026
(e.g., subject against verifier-supplied domain;
verificationMethod authority against issuer.domain; DNS TXT issuer
value against issuer.domain) MUST be performed as follows: both
values are converted to their A-label form per IDNA2008 [RFC5890];
any trailing dot is removed; the resulting ASCII labels are
compared case-insensitively. Internationalized domain names that
differ only by U-label vs A-label representation MUST be treated
as equal. Implementations MUST reject FQDN values that contain
disallowed code points or that fail IDNA2008 processing.
3. Problem Statement
Consider an autonomous procurement agent operating on behalf of a
corporate principal. The agent receives an invoice from
supplier.example.com for goods delivered under an existing master
services agreement. The agent has standing authorization to settle
invoices below a configured threshold without human review.
Before authorizing payment, the agent needs to answer a question that
has no standardized protocol response today: is the legal entity
operating supplier.example.com the same entity named on the
underlying agreement? The agent has the invoice, a domain name, and
a payment destination. It has no machine-readable, cryptographically
verifiable statement that binds the domain to a specific legal
entity, jurisdiction, and registration record.
In the absence of such a statement, the agent has three options:
trust the domain implicitly, defer to a human reviewer (defeating the
automation), or rely on a proprietary verification service whose
attestations are not interoperable with other agents or auditors.
This document addresses this gap. It defines a signed, self-hostable
assertion that any merchant can publish and any agent can verify,
producing a portable audit artifact in the process.
More generally, autonomous agents executing financial transactions
face a fundamental asymmetry: agent identity protocols enable
merchants to verify agents, but no complementary mechanism enables
agents to verify merchants.
This asymmetry creates the following risks:
3.1. Merchant Impersonation
Without verifiable merchant identity, an agent may be directed to pay
a fraudulent entity impersonating a legitimate merchant. Domain
spoofing, homograph attacks, and DNS hijacking all represent
realistic attack vectors in autonomous transaction flows.
Anders Expires 5 January 2027 [Page 6]
Internet-Draft Merchant Identity Assertions July 2026
3.2. Absent Audit Trail
Regulated industries including healthcare, government procurement,
and financial services require demonstrable proof that vendor
identity was verified before payment. No standardized cryptographic
mechanism currently exists to produce this proof in autonomous
transaction flows.
3.3. Policy Enforcement Gap
Human principals delegating transaction authority to autonomous
agents may wish to restrict transactions to verified merchant
entities. Without a machine-readable merchant identity standard,
such policies cannot be enforced consistently across agent
implementations.
3.4. Interoperability Absence
Proprietary merchant verification mechanisms implemented by
individual agent platforms are not interoperable. A merchant
verified by one platform's mechanism provides no assurance to a
different platform. A common standard eliminates this fragmentation.
4. Design Goals
G1. Verifiability: Any relying party MUST be able to verify an MIA
using only the assertion document and publicly available key
material, without dependency on a central authority.
G2. Self-Hostability: Any merchant MUST be able to publish an MIA
without registration with a central registry. Discovery via well-
known URI [RFC8615] enables decentralized publication.
G3. Interoperability: The MIA format MUST permit independent
implementation by any party. No proprietary extensions SHALL be
required for basic verification.
G4. Minimal Disclosure: The MIA MUST contain only the fields
necessary to establish merchant identity. Trust scoring, ranking,
and behavioral data are explicitly out of scope.
G5. Composability: The MIA MUST complement existing agent identity
and payment authorization protocols without requiring modification
to those protocols.
Anders Expires 5 January 2027 [Page 7]
Internet-Draft Merchant Identity Assertions July 2026
5. Non-Goals
The mechanism defined in this document is intentionally narrow. The
following are explicitly out of scope:
Trust scoring or reputation: An MIA does not assert that a merchant
is trustworthy, reliable, well-behaved, financially solvent, or a
good commercial counterparty. It asserts only that a specific
legal entity has cryptographically bound identity claims to a
specific domain. Reputation, ratings, scoring, and behavioral
signals are out of scope.
Merchant ranking or discovery: This document defines no mechanism
for ranking, prioritizing, recommending, or directing relying
parties toward any merchant. MIA verification produces a binary
outcome (the assertion is valid or it is not) and a set of
identity claims; it produces no ordering.
Endorsement or certification: An MIA is not a certification,
accreditation, or endorsement. The presence of a valid MIA does
not imply that the issuer has audited, approved, or sanctioned the
merchant beyond verifying the identity claims contained in the
assertion.
Payment authorization: This document defines no authorization,
settlement, clearing, or routing mechanism. Whether a verified
merchant should be paid, in what amount, by what instrument, and
under what terms is determined by the relying party's policies and
by separate payment protocols.
Agent or principal identity: This document defines no identity
mechanism for autonomous agents, the human or corporate principals
on whose behalf they act, or the platforms that operate them.
Agent identity is addressed by other specifications, with which
MIA is designed to compose.
Identity of natural persons: This document concerns the identity of
legal entities (corporations, LLCs, partnerships, etc.) that
operate commercial domains. It is not a mechanism for verifying
the identity of individual natural persons. Sole proprietor
cases, where the legal entity and the natural person coincide, are
addressed only with the privacy constraints in Section 13.
A central registry: No central registry, authority, or trusted third
party is defined or required. Each merchant, or a third party
explicitly authorized by the merchant, publishes its own MIA.
Relying parties may apply their own policies for which issuers
they trust.
Anders Expires 5 January 2027 [Page 8]
Internet-Draft Merchant Identity Assertions July 2026
Implementations and deployments MAY layer additional capabilities on
top of MIA verification (for example, a relying party may consult
external reputation services after MIA verification succeeds). Such
layers are out of scope for this document and MUST NOT be implied by
the presence of a valid MIA alone.
6. Relationship to Existing Work
Several existing technologies address adjacent problems. This
section describes how MIA relates to each, and why a distinct
mechanism is proposed.
6.1. X.509 and Web PKI
X.509 certificates bind a public key to a domain name, and Extended
Validation (EV) certificates additionally attest to the legal entity
operating the domain. However, EV identity information is presented
at the TLS layer, is not exposed as structured, queryable data to
autonomous agents, and is not designed to be consumed as a
transaction-time identity assertion. Certificate Transparency
[RFC9162] provides public auditability of certificate issuance but
does not surface legal entity claims in a form suitable for machine
evaluation. MIA produces a structured JSON assertion that an agent
can parse, validate, and retain as an audit artifact alongside
transaction records.
6.2. W3C Decentralized Identifiers and Verifiable Credentials
The W3C Verifiable Credentials Data Model defines a general framework
for cryptographically verifiable claims about a subject, and
Decentralized Identifiers (DIDs) define resolver-based identity. An
MIA could in principle be expressed as a constrained Verifiable
Credential profile. This document defines a narrower mechanism
intentionally: discovery via a single well-known URI rather than DID
resolution across heterogeneous methods, a fixed claim schema scoped
to merchant identity, and a wire format optimized for agent
verification rather than holder presentation. Future work MAY define
an MIA-to-VC mapping for deployments that require it.
6.3. OAuth Dynamic Client Registration
OAuth 2.0 Dynamic Client Registration [RFC7591] enables a client to
register identity metadata with an authorization server. It
addresses a different problem: client onboarding within a trust
relationship mediated by an authorization server. MIA addresses
transaction-time merchant verification across trust boundaries, with
no central authorization server and no prior registration
relationship between the verifying agent and the merchant.
Anders Expires 5 January 2027 [Page 9]
Internet-Draft Merchant Identity Assertions July 2026
6.4. SPIFFE and Workload Identity
SPIFFE defines workload identity within a trust domain, typically a
single organization or federation thereof. MIA addresses cross-
organization identity verification between parties with no pre-
established trust relationship.
6.5. DNS-Based Identity (DANE, TLSA)
DNS-based mechanisms such as DANE [RFC6698] bind keys or certificates
to domain names via DNSSEC. MIA uses DNS only as one of two third-
party authorization mechanisms (Section 8.2) and carries the
structured legal entity claims that DNS records are not designed to
convey. A future profile MAY define a DNS record type for MIA
discovery; this document defines HTTPS well-known URI discovery as
the primary mechanism for compatibility with the broader deployment
of HTTPS over DNSSEC.
7. Merchant Identity Assertion
An MIA is a JSON [RFC8259] document served with media type
application/merchant-identity+json (Section 15.3). It consists of a
Claims Object (Section 7.1 and Section 7.2) and an embedded Proof
Object (Section 7.3).
The Claims Object is the canonical input to the signing procedure.
The Proof Object records the resulting signature and key reference.
Both are serialized together as a single JSON document on the wire
(Section 7.4).
7.1. Claim Fields (Required)
version (integer): The MIA specification version. This document
defines version 1. Implementations MUST reject assertions with
unrecognized version values.
subject (string): The subject domain. MUST be a fully qualified
domain name (FQDN) expressed in lowercase. MUST match the domain
from which the assertion is served or the domain for which the
issuer holds explicit authorization per Section 8.2.
legalName (string): The registered legal name of the merchant entity
as it appears in the jurisdiction of incorporation or
registration.
entityType (string): The legal entity type. MUST be one of:
"corporation", "llc", "partnership", "sole_proprietor",
"cooperative", "nonprofit", "government", or "other".
Anders Expires 5 January 2027 [Page 10]
Internet-Draft Merchant Identity Assertions July 2026
jurisdiction (string): The ISO 3166-1 alpha-2 country code of the
primary jurisdiction of registration (e.g., "US", "GB", "DE").
Where a subdivision-level identifier is available and relevant,
implementors MAY use an ISO 3166-2 code (e.g., "US-AZ") in the
extensions field.
issuedAt (string): The UTC datetime at which this assertion was
issued, in RFC 3339 format (e.g., "2026-04-15T00:00:00Z").
expiresAt (string): The UTC datetime after which this assertion MUST
NOT be accepted, in RFC 3339 format. Issuers SHOULD NOT set
validity periods exceeding 365 days.
issuer (object): An object identifying the signing entity. MUST
contain:
name (string): Human-readable issuer name.
domain (string): Issuer FQDN.
keyDirectory (string): HTTPS URI of the issuer's Key Directory
(Section 10.2).
7.2. Claim Fields (Optional)
registrationId (string): A jurisdiction-specific business
registration identifier (e.g., EIN, Companies House number, GLEIF
LEI [LEI]).
evidenceUris (array of strings): HTTPS URIs referencing third-party
authoritative records that corroborate the identity claims in this
assertion (e.g., a public government business registry record, a
GLEIF LEI record). Each URI MUST be publicly accessible over
HTTPS without authentication. Failure to retrieve or parse an
evidenceUris value (network failure, non-200 HTTP status, redirect
to an authentication-gated resource, or unparseable response) does
not, by itself, invalidate the MIA. Relying parties MAY define
policies (per Section 9.4) that condition acceptance on successful
evidence retrieval for high-value or regulated transactions; such
policies are deployment-specific and out of scope for this
document.
extensions (object): A JSON object for implementation-specific
fields. Relying parties MUST ignore unrecognized keys. Extension
keys MUST use reverse domain notation (e.g.,
"com.example.customField").
Anders Expires 5 January 2027 [Page 11]
Internet-Draft Merchant Identity Assertions July 2026
7.3. Proof Object
The proof field MUST be present in a signed MIA and MUST be a JSON
object containing:
type (string): MUST be "MerchantIdentityProof-v1" for assertions
signed per this document. This value identifies the proof
envelope format defined in this section. Future documents MAY
define additional proof type values for structurally different
envelopes.
alg (string): The signature algorithm identifier. This document
defines a single value: "Ed25519", indicating the Edwards-Curve
Digital Signature Algorithm with the Ed25519 curve [RFC8032].
Future specifications MAY register additional algorithm
identifiers via Standards Action; see Section 14.9.
Implementations MUST reject assertions with unrecognized alg
values and MUST NOT attempt to infer an algorithm from the key
material alone.
created (string): The UTC datetime at which the proof was created,
in RFC 3339 format. MUST match the issuedAt claim field.
verificationMethod (string): An HTTPS URI of the form:
{issuer.keyDirectory}#{kid} where {kid} is the key identifier
within the Key Directory used to produce this signature. This
field anchors the signature to a specific, named key and provides
a deterministic path for key retrieval without requiring the
relying party to trust the payload-embedded keyDirectory value in
isolation (see Section 14, trust bootstrap).
proofValue (string): The base64url-encoded signature over the
canonical Claims Object, produced using the algorithm named in the
alg field, as defined in Section 10.3.
The keyDirectory URI appears in the assertion payload, which could
raise a trust bootstrap concern if a relying party were to trust the
payload as the sole source of key discovery information. To avoid
this, the relying party MUST derive the authoritative key directory
location from proof.verificationMethod and MUST NOT rely on
issuer.keyDirectory as the sole key discovery path. Relying parties
SHOULD additionally verify that the domain in verificationMethod
matches issuer.domain as a consistency check.
Anders Expires 5 January 2027 [Page 12]
Internet-Draft Merchant Identity Assertions July 2026
7.4. Wire Format
An MIA is serialized as a single JSON document. The Claims Object
fields (Section 7.1 and Section 7.2) and the proof field
(Section 7.3) appear at the top level of this JSON document.
The document MUST be served over HTTPS with:
Content-Type: application/merchant-identity+json
Implementations MUST NOT serve or accept MIA documents over plain
HTTP.
7.5. Versioning
The version field in the Claims Object identifies the MIA
specification version, not the issuer's software version or assertion
content version. This document defines version 1.
The version field follows a strict-rejection model: relying parties
MUST reject assertions with unrecognized version values. New claim
fields, optional or required, do not increment the version number;
they are added through extensions (Section 7.2) or through new
optional fields defined by future documents that update this
specification.
The version number is incremented only when an incompatible
structural change is made to the Claims Object such that an
implementation built to an earlier version could not safely interpret
the assertion. Examples of incompatible changes include: removal of
a required field, change in the canonicalization algorithm, or change
in the meaning of an existing field.
The proof.type field follows the same model independently. The
version number in the proof type identifier (currently
"MerchantIdentityProof-v1") increments only on incompatible changes
to the proof envelope structure itself, distinct from algorithm
changes (which are signaled via proof.alg per Section 14.9).
7.6. Example
The following is a non-normative example of a complete signed MIA
document:
Anders Expires 5 January 2027 [Page 13]
Internet-Draft Merchant Identity Assertions July 2026
{
"version": 1,
"subject": "supplier.example.com",
"legalName": "Example Supply Corporation",
"entityType": "corporation",
"jurisdiction": "US",
"issuedAt": "2026-04-15T00:00:00Z",
"expiresAt": "2027-04-15T00:00:00Z",
"issuer": {
"name": "Example Trust Registry",
"domain": "trust.example.org",
"keyDirectory": "https://trust.example.org/.well-known/jwks.json"
},
"registrationId": "12-3456789",
"evidenceUris": [
"https://www.gleif.org/lei/5493001KJTIIGC8Y1R12"
],
"proof": {
"type": "MerchantIdentityProof-v1",
"alg": "Ed25519",
"created": "2026-04-15T00:00:00Z",
"verificationMethod":
"https://trust.example.org/.well-known/jwks.json#key-01",
"proofValue": "MGViZDcwYTk...86-char-base64url-signature"
}
}
8. Discovery
8.1. Well-Known URI
A merchant MAY self-issue an MIA and publish it at:
https://{subject-domain}/.well-known/merchant-identity.json
This resource MUST be served over HTTPS with:
Content-Type: application/merchant-identity+json
A relying party wishing to obtain an MIA for a given merchant domain
SHOULD first attempt retrieval from this well-known URI.
For a self-issued MIA, the issuer.domain field MUST equal the subject
field, and the issuer.keyDirectory MUST resolve to a Key Directory at
the subject domain.
Anders Expires 5 January 2027 [Page 14]
Internet-Draft Merchant Identity Assertions July 2026
8.2. Third-Party Issuer Authorization
Merchants MAY authorize a third-party issuer to publish an MIA on
their behalf. Before relying on a third-party MIA, the relying party
MUST verify that the issuer is authorized by the subject domain using
one of the following mechanisms:
a) DNS TXT Authorization Record:
The subject domain MUST publish a DNS TXT record at the name _mia-
auth.{subject-domain}:
_mia-auth.supplier.example.com. IN TXT
"v=mia1; issuer=trust.example.org"
The issuer value MUST exactly match the issuer.domain field in the
MIA.
b) HTTP Delegation Document:
The subject domain MUST publish a Merchant Identity Delegation
Document (MIDD) at:
https://{subject-domain}/.well-known/mia-delegation.json
An MIDD is a distinct document type from an MIA. It MUST be a JSON
object signed using the same proof structure defined in Section 7.3
and MUST contain:
version (integer): MUST be 1.
type (string): MUST be "MerchantIdentityDelegation".
subject (string): The merchant domain granting delegation.
authorizedIssuer (string): The FQDN of the authorized third-party
issuer.
issuedAt (string): RFC 3339 datetime.
expiresAt (string): RFC 3339 datetime.
proof (object): Per Section 7.3, signed by a key published at the
subject domain's Key Directory.
The MIDD MUST be served over HTTPS with:
Content-Type: application/merchant-delegation+json
Anders Expires 5 January 2027 [Page 15]
Internet-Draft Merchant Identity Assertions July 2026
Relying parties MUST verify the MIDD proof using a key hosted at the
subject domain's Key Directory before accepting the named issuer as
authorized. See Section 15.4 for the media type registration.
A subject domain that authorizes a third-party issuer via MIDD MUST
publish a Key Directory at the location identified by the
proof.verificationMethod field of the MIDD itself. The Key Directory
MUST contain the public key whose corresponding private key signed
the MIDD. This Key Directory is operated by the subject domain and
is distinct from any Key Directory operated by the third-party issuer
to which delegation is granted. A subject domain that uses only DNS
TXT third-party authorization (mechanism a) is not required to
operate a Key Directory.
Relying parties MUST treat an MIA as invalid if neither authorization
mechanism is satisfied.
9. Issuance Models and Assurance Considerations
An MIA is structurally valid if it satisfies the verification
procedure in Section 10.4. Structural validity is a necessary
condition for relying on an assertion, but it is not, by itself, a
sufficient condition for high-assurance use.
This document defines no normative assurance levels. However, the
protocol surfaces enough information for a relying party to apply its
own policies. This section describes the issuance models the
protocol supports and the corresponding signals available to relying
parties.
9.1. Self-Issuance
A merchant may self-issue an MIA: the issuer.domain equals the
subject, and the assertion is signed by a key published at the
subject domain's Key Directory. Self-issuance demonstrates control
of the subject domain at the time of signing and provides
cryptographic attribution of the claims to whoever controls the
domain. It does not, by itself, demonstrate that the legal entity
claims (legalName, entityType, jurisdiction, registrationId)
correspond to the actual entity operating the domain.
Anders Expires 5 January 2027 [Page 16]
Internet-Draft Merchant Identity Assertions July 2026
9.2. Third-Party Issuance
A merchant may authorize a third-party issuer per Section 8.2. The
relying party can then evaluate the assertion as the joint product of
two signals: the merchant's authorization of the issuer (proven by
the DNS TXT record or signed delegation document at the subject
domain) and the issuer's attestation to the merchant's identity
claims. The strength of the resulting assurance depends on the
practices of the named issuer, which are out of scope for this
document.
9.3. External Evidence
An MIA MAY include the optional evidenceUris field (Section 7.2),
referencing publicly accessible authoritative records that
corroborate identity claims (for example, a GLEIF LEI record, a
government business registry entry, or a public regulator filing).
The evidenceUris field allows a relying party, or an automated
verification service acting on the relying party's behalf, to check
the consistency of the MIA's claims against independent sources at
verification time.
This document does not require relying parties to fetch or validate
evidenceUris. Implementations MAY define policies that condition
acceptance on successful evidence retrieval and consistency checks;
such policies are deployment-specific.
9.4. Relying Party Policy
Relying parties operating in regulated, high-value, or otherwise
high-stakes contexts SHOULD define explicit policies for which
issuance models they accept. Examples of policies a relying party
MAY adopt include:
* Accept only third-party-issued MIAs from issuers on a maintained
allowlist.
* Accept self-issued MIAs only for transactions below a configured
threshold.
* Require an evidenceUris value resolving to a GLEIF LEI record for
transactions exceeding a configured threshold.
* Require a fresh assertion (recently retrieved from the well-known
URI rather than served from cache) for transactions within a
defined recency window.
Anders Expires 5 January 2027 [Page 17]
Internet-Draft Merchant Identity Assertions July 2026
Such policies are out of scope for this specification. The protocol
exposes the inputs; the policy decisions belong to the relying party
and its principals.
10. Signing and Verification
10.1. Signing Algorithm
This document defines a single mandatory-to-implement signature
algorithm: the Edwards-Curve Digital Signature Algorithm (EdDSA) with
the Ed25519 curve [RFC8032], identified in the proof.alg field as
"Ed25519". All conforming issuers and relying parties MUST support
this algorithm.
Future specifications MAY define additional algorithm identifiers;
see Section 14.9 for the extension model and post-quantum migration
considerations.
10.2. Key Directory
Issuers MUST publish a JSON Web Key Set [RFC7517] at the HTTPS URI in
the issuer.keyDirectory field. This document is the Key Directory.
Key Directory entries used for MIA signing with the Ed25519 algorithm
MUST include:
kty: "OKP"
crv: "Ed25519"
use: "sig"
kid: A stable, unique, URL-safe identifier.
x: The base64url-encoded Ed25519 public key.
JWK parameters MUST be appropriate for the algorithm identified in
the proof.alg field of the assertion the key is used to verify, per
[RFC7517]. Specifications defining additional algorithm identifiers
(Section 14.9) MUST specify the corresponding JWK parameter
requirements.
The Key Directory MUST be served over HTTPS with appropriate HTTP
caching headers. Relying parties SHOULD cache key material per those
headers to reduce verification latency and network load.
Implementations MUST NOT cache key material beyond the lifetime
indicated by the HTTP cache directives, and MUST re-fetch on
signature verification failure to accommodate key rotation. Issuers
Anders Expires 5 January 2027 [Page 18]
Internet-Draft Merchant Identity Assertions July 2026
SHOULD set cache lifetimes that balance verification performance
against key rotation responsiveness; values between one hour and 24
hours are RECOMMENDED.
If the Key Directory is unreachable during verification, relying
parties MUST NOT accept the assertion as verified. Relying parties
MAY retry per their own operational policies but MUST NOT fall back
to cached keys whose cache lifetime has expired.
10.3. Signing Procedure
To produce an MIA signature, the issuer MUST:
1. Construct the Claims Object containing all required fields
(Section 7.1) and any optional fields (Section 7.2), excluding
the proof field.
2. Produce the canonical signing input by serializing the Claims
Object as a JSON string with keys in lexicographic order and no
insignificant whitespace [RFC8785].
3. Sign the UTF-8 encoding of the canonical string using the private
key corresponding to the chosen kid, producing a signature with
the algorithm identified by proof.alg.
4. Encode the resulting 64-byte signature as a base64url string
(proofValue).
5. Construct the proof object (Section 7.3) with the type, created,
verificationMethod, and proofValue fields.
6. Merge the Claims Object and proof object into a single JSON
document (Section 7.4).
10.4. Verification Procedure
A relying party MUST perform the following steps:
Anders Expires 5 January 2027 [Page 19]
Internet-Draft Merchant Identity Assertions July 2026
1. Retrieve the MIA document via HTTPS. If the retrieval fails
(network error, DNS resolution failure, TLS validation failure,
non-2xx HTTP status, unfollowed redirect, or response exceeding
a relying-party-defined maximum size), the relying party MUST
treat the verification result as "no MIA available" and MUST NOT
proceed with subsequent verification steps. Implementations
MUST NOT automatically follow HTTP redirects when retrieving an
MIA from the well-known URI; redirected responses MUST be
treated as retrieval failure. The maximum response size SHOULD
be at least 64 kilobytes and SHOULD NOT exceed 1 megabyte for
any deployment.
2. Verify the Content-Type is application/merchant-identity+json.
3. Parse the JSON document. Extract the proof field. If absent,
reject the assertion.
4. Verify proof.type is "MerchantIdentityProof-v1" and that
proof.alg names a recognized algorithm. If either check fails,
reject. Implementations MUST NOT accept assertions with unknown
proof type or alg values.
5. Extract the key directory URI and kid from
proof.verificationMethod by splitting on the last "#" character.
The key directory URI is the portion before "#"; the kid is the
portion after. The relying party MUST use this URI as the
authoritative key directory location. It MUST also verify that
the authority component of this URI matches the issuer.domain
field in the assertion as a consistency check, using the Domain
Comparison rules defined in Section 2. If they do not match,
the assertion MUST be rejected. The path component of the URI
MAY differ from any path implied by issuer.keyDirectory; only
the authority component is compared.
6. Retrieve the Key Directory over HTTPS from the extracted URI.
7. Locate the JWK entry with the matching kid. If absent, reject.
8. Reconstruct the canonical signing input from the assertion
document with the proof field removed, following the procedure
in Section 10.3, step 2.
9. Verify the signature in proof.proofValue against the canonical
signing input using the located public key and the algorithm
identified by proof.alg.
10. Verify that the current time is strictly between issuedAt and
expiresAt (exclusive).
Anders Expires 5 January 2027 [Page 20]
Internet-Draft Merchant Identity Assertions July 2026
11. Verify that the subject field matches the domain for which
verification is being performed, using the Domain Comparison
rules defined in Section 2.
12. If issuer.domain differs from subject, verify third-party
authorization per Section 8.2.
13. If all steps succeed, the assertion is valid.
A relying party MUST NOT act on an assertion that fails any
verification step.
11. Freshness and Revocation
This document distinguishes two categories of change that affect the
validity of a previously issued MIA:
Identity revocation: A material change to the legal entity claims in
the MIA (e.g., legal name change, jurisdiction change,
dissolution, loss of business registration, or transfer of the
subject domain to a different legal entity). Identity revocation
invalidates the assertion's claims regardless of cryptographic
validity.
Operational revocation: A change to the issuer's signing
infrastructure (e.g., key compromise, key rotation, or suspension
of issuance) that affects the cryptographic validity of
outstanding assertions but does not change the underlying identity
claims.
The protocol addresses these two categories through complementary
mechanisms.
11.1. Validity Periods and Re-Issuance
Relying parties MUST NOT accept assertions for which the current time
is at or after the expiresAt value.
Issuers SHOULD limit assertion validity periods. Validity periods of
90 days or less are RECOMMENDED for issuers with automated re-
issuance pipelines.
Issuers MUST re-issue assertions promptly when material identity
information changes. Re-issuance is the primary mechanism for
identity revocation; the previous assertion is allowed to expire on
its own schedule unless explicit revocation is also signaled.
Anders Expires 5 January 2027 [Page 21]
Internet-Draft Merchant Identity Assertions July 2026
Relying parties in high-stakes or regulated contexts SHOULD retrieve
a fresh assertion rather than relying on a cached copy when the
cached copy is older than 24 hours, regardless of the expiresAt
value.
Issuers MAY set HTTP cache directives on the MIA endpoint. Relying
parties MAY honor these directives but MUST NOT cache an MIA beyond
its expiresAt value regardless of HTTP cache headers, and MUST NOT
cache an MIA whose Cache-Control directives explicitly forbid
caching. Where issuer-supplied cache directives permit caching
beyond the recency thresholds defined in this section, the more
restrictive policy applies.
11.2. Explicit Revocation
Issuers MAY support explicit revocation by including a revocationUri
extension field in the Claims Object. If present, this field MUST be
an HTTPS URI that resolves to a JSON object with at least a boolean
"revoked" field and a "checkedAt" string in RFC 3339 format
indicating when the revocation status was last updated by the issuer.
Relying parties MAY check this URI before relying on an assertion.
Relying parties in high-stakes or regulated contexts SHOULD do so.
The revocationUri endpoint MUST be served over HTTPS with valid
certificate validation.
This document does not define a normative revocation list format. A
future specification MAY define one for deployments at scale.
11.3. Key Rotation
Operational revocation through signing-key rotation is supported by
the Key Directory mechanism (Section 10.2). When an issuer rotates
keys, it removes the old key from its Key Directory. Relying parties
that follow the cache requirements in Section 10.2 will fail
signature verification on assertions signed with revoked keys once
the cache lifetime elapses.
Issuers MUST remove compromised keys from the Key Directory without
delay and SHOULD re-issue all outstanding assertions previously
signed with the compromised key.
12. Evaluation Result Token
A verification service MAY issue an Evaluation Result Token (ERT)
after successfully verifying an MIA. The ERT is a signed JWT
[RFC7519] that serves as a portable audit artifact confirming that
verification was performed.
Anders Expires 5 January 2027 [Page 22]
Internet-Draft Merchant Identity Assertions July 2026
The ERT is an optional layer. Its issuance does not alter the
validity of the underlying MIA.
12.1. Claims
iss (string, REQUIRED): The domain of the verification service.
sub (string, REQUIRED): The subject domain that was verified.
iat (NumericDate, REQUIRED): Time of ERT issuance.
exp (NumericDate, REQUIRED): Expiry time. MUST NOT exceed iat + 300
seconds to limit replay exposure.
jti (string, REQUIRED): A cryptographically random, globally unique
token identifier for replay detection.
mia_verified (boolean, REQUIRED): True if a valid, unexpired MIA was
located and successfully verified for the subject domain per
Section 10.4. False otherwise.
mia_subject (string, REQUIRED when mia_verified is true): The
subject field from the verified MIA.
mia_issued_at (string, REQUIRED when mia_verified is true): The
issuedAt field from the verified MIA.
mia_issuer_domain (string, REQUIRED when mia_verified is true): The
issuer.domain field from the verified MIA.
No consumer or agent identity fields SHALL be included in an ERT
without explicit principal consent.
12.2. Signing
The ERT MUST be signed as a JWS [RFC7515] using EdDSA with Ed25519
[RFC8032]. The JWS Protected Header MUST include:
alg: "EdDSA"
kid: Key identifier in the verification service's Key Directory.
Implementations MUST follow JWT Best Current Practices [RFC8725],
including algorithm validation and rejection of the none algorithm.
Anders Expires 5 January 2027 [Page 23]
Internet-Draft Merchant Identity Assertions July 2026
12.3. Example
The following is a non-normative example of a decoded ERT payload:
{
"iss": "trust.example.org",
"sub": "supplier.example.com",
"iat": 1776254400,
"exp": 1776254700,
"jti": "f7a2c9e1b4d8",
"mia_verified": true,
"mia_subject": "supplier.example.com",
"mia_issued_at": "2026-04-15T00:00:00Z",
"mia_issuer_domain": "trust.example.org"
}
A relying party MAY include the ERT in payment metadata or
transaction records to provide downstream parties with a verifiable
audit artifact that pre-transaction merchant identity verification
occurred.
13. Privacy Considerations
13.1. Minimal Disclosure
MIA documents MUST NOT include personal data about natural persons
except where the subject is a sole proprietor, such disclosure is
legally required in the jurisdiction, and the natural person has
provided explicit consent.
13.2. Evidence URI Privacy
The evidenceUris field, if included, reveals which third-party
registries were used to corroborate the merchant's identity. Issuers
SHOULD assess the privacy implications of each URI before inclusion.
13.3. Relying Party Query Privacy
Real-time retrieval of MIAs from well-known URIs or Key Directories
reveals which merchants a relying party intends to transact with.
Implementations SHOULD use caching and pre-fetching strategies to
reduce this correlation risk.
Anders Expires 5 January 2027 [Page 24]
Internet-Draft Merchant Identity Assertions July 2026
13.4. Issuer-Side Correlation
An issuer hosting MIAs at well-known URIs, and the operator of any
Key Directory, observes which network endpoints retrieve which
assertions. Operators of verification-as-a-service offerings, third-
party issuers, and CDNs in the retrieval path can therefore construct
correlation graphs linking relying parties to merchant-domain
queries. Issuers and intermediaries SHOULD NOT log or retain the
source IP, principal identifier, or session identifier of MIA
retrievals beyond what is operationally necessary, and MUST NOT share
such retrieval metadata with third parties without the requesting
relying party's consent. Operators of verification services that
issue ERTs on behalf of relying parties MUST ensure that retrieval
logs are not cross-linked with ERT issuance records in ways that
would defeat the consumer principal privacy requirements in
Section 13.5.
13.5. Consumer Principal Privacy
ERTs as defined in Section 12 MUST NOT include consumer or agent
principal identifiers. Verification services MUST NOT log consumer
identifiers in association with merchant verification events without
explicit consumer consent.
14. Security Considerations
14.1. Replay Attacks
The ERT jti claim provides a unique token identifier. Relying
parties MUST maintain a jti cache for at least the duration of the
token's validity window (exp - iat), plus a clock-skew allowance of
at least 60 seconds, and MUST reject any ERT whose jti has been seen
previously. The RECOMMENDED maximum ERT validity of 300 seconds
bounds the size of this cache.
Relying parties verifying iat and exp claims SHOULD permit clock skew
of up to 60 seconds in either direction relative to the relying
party's local clock. Implementations operating in environments with
reliable time synchronization (e.g., NTP-disciplined clocks) MAY use
a smaller skew allowance. Implementations MUST NOT permit skew
exceeding 300 seconds, as doing so would extend the effective replay
window beyond the token's intended lifetime.
Anders Expires 5 January 2027 [Page 25]
Internet-Draft Merchant Identity Assertions July 2026
14.2. Key Compromise
If an issuer's signing key is compromised, all MIA documents signed
with that key MUST be treated as invalid. Issuers MUST maintain key
rotation procedures and MUST remove compromised keys from their Key
Directory promptly. Relying parties that cache Key Directory
material MUST re-fetch on signature verification failure.
14.3. Domain Transfer
An MIA is bound to a domain name. Transfer of that domain to a new
owner does not automatically invalidate outstanding assertions.
Issuers MUST implement procedures to detect domain transfer and
revoke or re-evaluate affected assertions without delay.
14.4. Malicious Issuers
A third-party issuer operating in bad faith may publish false
assertions. Relying parties SHOULD NOT treat all issuers as equally
trustworthy. Relying parties MAY maintain allowlists of trusted
issuer domains and SHOULD treat assertions from unknown issuers with
heightened scrutiny. The third-party authorization requirement in
Section 8.2 ensures that an issuer cannot publish an MIA for a domain
that has not explicitly authorized it, but does not guarantee the
issuer itself is trustworthy.
14.5. Stale Assertions
Merchant legal standing may change after assertion issuance (e.g.,
insolvency, license revocation, sanctions designation). Relying
parties in regulated industries MUST NOT treat an MIA as sole
evidence of current compliance and SHOULD supplement MIA verification
with jurisdiction-appropriate checks for high-value or high-risk
transactions.
14.6. Downgrade Attacks
An attacker with network access could substitute an older but still-
valid MIA for a more recently issued one. Relying parties SHOULD
record the issuedAt timestamp of the assertion used in a transaction
and SHOULD reject assertions whose issuedAt predates their recency
threshold for the transaction context.
Anders Expires 5 January 2027 [Page 26]
Internet-Draft Merchant Identity Assertions July 2026
14.7. Third-Party Authorization Poisoning
DNS TXT records (Section 8.2, mechanism a) are susceptible to cache
poisoning if DNSSEC is not deployed. Implementations MUST use
DNSSEC-validated resolution where available when performing DNS-based
third-party authorization checks. HTTP delegation documents
(mechanism b) MUST be retrieved over HTTPS with certificate
validation; relying parties MUST reject delegation documents served
without a valid TLS certificate.
14.8. JWT Security
Implementations of the ERT (Section 12) MUST comply with JWT Best
Current Practices [RFC8725], including:
* Explicitly validating the alg header value.
* Rejecting tokens with alg: "none".
* Validating iss, sub, iat, exp, and jti before acting on any token.
* Not relying on unverified header parameters for security
decisions.
14.9. Cryptographic Agility and Post-Quantum Considerations
The MIA proof envelope (Section 7.3) carries an explicit alg field to
enable cryptographic agility. This document defines a single
algorithm, Ed25519 [RFC8032], as mandatory to implement. Future
specifications MAY register additional algorithm identifiers via
Standards Action, including post-quantum signature algorithms
standardized by NIST such as ML-DSA [FIPS204], and composite
signature schemes that combine a classical and a post-quantum
algorithm in a single proof.
An MIA is a signed assertion, not an encrypted payload. The "harvest
now, decrypt later" threat model applicable to confidentiality-
protected traffic does not apply directly to MIA documents. The
post-quantum concern relevant to this specification is the future
forgeability of long-lived merchant signing keys: an adversary in
possession of a cryptographically relevant quantum computer could, in
principle, recover an Ed25519 private key from observed public-key
material and use it to forge assertions. Issuers SHOULD therefore
treat assertion validity periods and signing-key rotation cadence as
the primary mitigations available within the bounds of this document.
Anders Expires 5 January 2027 [Page 27]
Internet-Draft Merchant Identity Assertions July 2026
Implementations consuming MIAs SHOULD be designed to accommodate
additional algorithm identifiers in the proof.alg field without
requiring changes to the envelope format or wire structure.
Specifications introducing new algorithms MUST define the
corresponding JWK parameters in the Key Directory (Section 10.2) and
SHOULD address coexistence with deployed Ed25519 keys.
15. IANA Considerations
The media type registrations below request names in the standards
tree. Per Section 3.1 of [RFC6838], standards-tree registrations
require approval associated with IETF standards-track processing.
The author acknowledges that these registrations are contingent on
the disposition of this document; should this document not progress
toward standards-track publication, the registrations would be
withdrawn or resubmitted under the vendor tree.
15.1. Well-Known URI: merchant-identity.json
This document requests registration in the "Well-Known URIs" registry
[RFC8615]:
URI suffix: merchant-identity.json
Change controller: IETF
Specification document(s): This document, Section 8.1
Status: permanent
Related information: None
15.2. Well-Known URI: mia-delegation.json
This document requests registration in the "Well-Known URIs" registry
[RFC8615]:
URI suffix: mia-delegation.json
Change controller: IETF
Specification document(s): This document, Section 8.2
Status: permanent
Related information: Used to publish a Merchant Identity Delegation
Document (MIDD) authorizing a named third-party issuer to publish
MIAs on behalf of the subject domain.
Anders Expires 5 January 2027 [Page 28]
Internet-Draft Merchant Identity Assertions July 2026
15.3. Media Type: application/merchant-identity+json
This document requests registration of a new media type per
[RFC6838]:
Type name: application
Subtype name: merchant-identity+json
Required parameters: none
Optional parameters: version: The MIA version number (integer).
Defaults to 1 if absent.
Encoding considerations: Binary (UTF-8 encoded JSON per [RFC8259]).
Security considerations: See Section 14 of this document.
Interoperability considerations: See Section 4 of this document.
Published specification: This document.
Applications that use this media type: Autonomous agents performing
pre-transaction merchant identity verification; verification
services issuing Evaluation Result Tokens; merchant identity
registries.
Fragment identifier considerations: None.
Additional information: Deprecated alias names for this type: None.
Magic number(s): None. File extension(s): .mia.json. Macintosh
file type code(s): None.
Person & email address to contact for further information:
founder@registeredbrands.ai
Intended usage: COMMON
Restrictions on usage: None.
Author: Robb Anders
Change controller: IETF
15.4. Media Type: application/merchant-delegation+json
This document requests registration of a new media type per
[RFC6838]:
Anders Expires 5 January 2027 [Page 29]
Internet-Draft Merchant Identity Assertions July 2026
Type name: application
Subtype name: merchant-delegation+json
Required parameters: none
Optional parameters: version: The MIDD version number (integer).
Defaults to 1 if absent.
Encoding considerations: Binary (UTF-8 encoded JSON per [RFC8259]).
Security considerations: See Section 14 of this document. The MIDD
MUST be signed by a key published at the subject domain's Key
Directory; see Section 8.2.
Interoperability considerations: See Section 4 of this document.
Published specification: This document, Section 8.2.
Applications that use this media type: Merchant Identity Assertion
(MIA) issuers and verifiers; relying parties evaluating third-
party-issued MIAs.
Fragment identifier considerations: None.
Additional information: Deprecated alias names for this type: None.
Magic number(s): None. File extension(s): .midd.json. Macintosh
file type code(s): None.
Person & email address to contact for further information:
founder@registeredbrands.ai
Intended usage: COMMON
Restrictions on usage: None.
Author: Robb Anders
Change controller: IETF
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Anders Expires 5 January 2027 [Page 30]
Internet-Draft Merchant Identity Assertions July 2026
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, 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, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/rfc/rfc5890>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/rfc/rfc8725>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
Anders Expires 5 January 2027 [Page 31]
Internet-Draft Merchant Identity Assertions July 2026
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
16.2. Informative References
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
[WEBBOTAUTH]
Meunier, T. and S. Major, "Web Bot Auth Architecture",
Work in Progress, Internet-Draft, draft-meunier-web-bot-
auth-architecture, 2026,
<https://datatracker.ietf.org/doc/draft-meunier-web-bot-
auth-architecture/>.
[KYAPAY] IETF, "KYAPay Profile", Work in Progress, Internet-Draft,
draft-skyfire-kyapayprofile-01,
<https://datatracker.ietf.org/doc/draft-skyfire-
kyapayprofile-01/>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/rfc/rfc7591>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/rfc/rfc6698>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.
[FIPS204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard", FIPS 204,
August 2024, <https://csrc.nist.gov/pubs/fips/204/final>.
[LEI] Global Legal Entity Identifier Foundation, "Legal Entity
Identifier", 2026, <https://www.gleif.org/>.
Anders Expires 5 January 2027 [Page 32]
Internet-Draft Merchant Identity Assertions July 2026
Acknowledgements
The author thanks the participants of the IETF web-bot-auth working
group for their engagement, and in particular David Schinazi and
Rifaat Shekh-Yusef for their guidance in directing this work toward
the DISPATCH working group. The author also acknowledges the
complementary work in draft-skyfire-kyapayprofile, which addresses
agent-side identity in a manner that this document's merchant-side
framework is designed to complement.
Document History
This section is to be removed by the RFC Editor before publication.
Changes from -00 to -01 (author revision):
* Added Motivating Scenario in Section 3.
* Added dedicated Non-Goals section (Section 5) explicitly excluding
trust scoring, ranking, endorsement, payment authorization, agent
identity, identity of natural persons, and central registries.
* Added Relationship to Existing Work section (Section 6) covering
X.509/Web PKI, W3C VC/DID, OAuth Dynamic Client Registration,
SPIFFE, and DNS-based identity.
* Added Issuance Models and Assurance Considerations section
(Section 9) describing self-issuance, third-party issuance,
external evidence, and relying party policy.
* Refactored proof envelope: separated proof.type (envelope format
identifier) from proof.alg (signature algorithm identifier);
renamed proof type from MerchantIdentityProof-EdDSA-v1 to
MerchantIdentityProof-v1.
* Added Cryptographic Agility section (Section 14.9) including post-
quantum considerations and ML-DSA reference.
* Tightened Key Directory caching, rotation, and unreachable-
directory requirements (Section 10.2).
* Restructured Freshness and Revocation (Section 11) to distinguish
identity revocation, explicit revocation, and operational
revocation through key rotation.
* Added Security Considerations subsections on Domain Transfer,
Stale Assertions, Downgrade Attacks, and Third-Party Authorization
Poisoning.
Anders Expires 5 January 2027 [Page 33]
Internet-Draft Merchant Identity Assertions July 2026
* Registered media type application/merchant-delegation+json
(Section 15.4) and updated the third-party authorization section
to use it.
* Added Versioning subsection (Section 7.5) clarifying the
independent version semantics of the Claims Object and the proof
envelope.
* Added normative Domain Comparison rules (Section 2) covering
IDNA2008 A-label normalization, trailing-dot handling, and case-
insensitive comparison; updated verification steps to reference
these rules.
* Clarified the relationship between proof.verificationMethod and
issuer.keyDirectory: only the authority component is compared, and
the path component MAY differ.
* Added MIA endpoint cache-control guidance (Section 11.1).
* Made the Key Directory dependency for MIDD-based third-party
authorization explicit (Section 8.2); clarified that DNS-only
authorization does not require subject-domain Key Directory.
* Added clock-skew tolerance for ERT iat/exp validation
(Section 14.1).
* Added evidenceUris failure-handling guidance (Section 7.2):
retrieval failure does not invalidate the MIA absent deployment-
specific policy.
* Added MIA fetch failure handling and redirect prohibition in the
verification procedure (Section 10.4).
* Added Issuer-Side Correlation privacy consideration
(Section 13.4).
* Added a paragraph clarifying the architectural relationship
between MIA and existing transport-layer agent identity mechanisms
(Web Bot Auth, HTTP Message Signatures) in Section 1.
* Editorial improvements throughout.
Author's Address
Robb Anders
RegisteredBrands.AI
Email: founder@registeredbrands.ai
URI: https://registeredbrands.ai
Anders Expires 5 January 2027 [Page 34]