RegisteredBrands.AI

founder@registeredbrands.ai https://registeredbrands.ai

merchant identity autonomous commerce agentic commerce trust verification Ed25519 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.

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. Current work in agent identity -- including IETF Web Bot Auth and payment authorization frameworks such as Visa Trusted Agent Protocol, Mastercard Agent Pay, and the KYAPay Profile -- provides mechanisms for a receiving system to verify that an automated client is legitimate and authorized to transact. HTTP Message Signatures 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

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.

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

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 .

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 .

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 issued by a verification service summarizing the result of a pre-transaction merchant identity check, as defined in .

Key Directory:

A JSON Web Key Set published at a well-known location used to discover public keys for signature verification.

Domain Comparison:

Throughout this document, comparison of two FQDNs (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 ; 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.

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:

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.

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.

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.

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.

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

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 .

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.

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.

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.

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

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.

OAuth Dynamic Client Registration OAuth 2.0 Dynamic Client Registration 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.

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.

DNS-Based Identity (DANE, TLSA) DNS-based mechanisms such as DANE bind keys or certificates to domain names via DNSSEC. MIA uses DNS only as one of two third-party authorization mechanisms () 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.

Merchant Identity Assertion An MIA is a JSON document served with media type application/merchant-identity+json (). It consists of a Claims Object ( and ) and an embedded Proof Object (). 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 ().

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 .

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

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

Claim Fields (Optional)

registrationId (string):

A jurisdiction-specific business registration identifier (e.g., EIN, Companies House number, GLEIF 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 ) 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").

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 . Future specifications MAY register additional algorithm identifiers via Standards Action; see . 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 , 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 .

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.

Wire Format An MIA is serialized as a single JSON document. The Claims Object fields ( and ) and the proof field () appear at the top level of this JSON document. The document MUST be served over HTTPS with: Implementations MUST NOT serve or accept MIA documents over plain HTTP.

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

Example The following is a non-normative example of a complete signed MIA document:

Discovery

Well-Known URI A merchant MAY self-issue an MIA and publish it at: This resource MUST be served over HTTPS with: 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.

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}: 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: An MIDD is a distinct document type from an MIA. It MUST be a JSON object signed using the same proof structure defined in 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 , signed by a key published at the subject domain's Key Directory.

The MIDD MUST be served over HTTPS with: 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 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.

Issuance Models and Assurance Considerations An MIA is structurally valid if it satisfies the verification procedure in . 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.

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.

Third-Party Issuance A merchant may authorize a third-party issuer per . 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.

External Evidence An MIA MAY include the optional evidenceUris field (), 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.

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.

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.

Signing and Verification

Signing Algorithm This document defines a single mandatory-to-implement signature algorithm: the Edwards-Curve Digital Signature Algorithm (EdDSA) with the Ed25519 curve , 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 for the extension model and post-quantum migration considerations.

Key Directory Issuers MUST publish a JSON Web Key Set 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 . Specifications defining additional algorithm identifiers () 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 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.

Signing Procedure To produce an MIA signature, the issuer MUST:

1. Construct the Claims Object containing all required fields () and any optional fields (), 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 .
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 () with the type, created, verificationMethod, and proofValue fields.
6. Merge the Claims Object and proof object into a single JSON document ().

Verification Procedure A relying party MUST perform the following steps:

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 . 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 , 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).
11. Verify that the subject field matches the domain for which verification is being performed, using the Domain Comparison rules defined in .
12. If issuer.domain differs from subject, verify third-party authorization per .
13. If all steps succeed, the assertion is valid.

A relying party MUST NOT act on an assertion that fails any verification step.

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.

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

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.

Key Rotation Operational revocation through signing-key rotation is supported by the Key Directory mechanism (). When an issuer rotates keys, it removes the old key from its Key Directory. Relying parties that follow the cache requirements in 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.

Evaluation Result Token A verification service MAY issue an Evaluation Result Token (ERT) after successfully verifying an MIA. The ERT is a signed JWT that serves as a portable audit artifact confirming that verification was performed. The ERT is an optional layer. Its issuance does not alter the validity of the underlying MIA.

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

Signing The ERT MUST be signed as a JWS using EdDSA with Ed25519 . 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 , including algorithm validation and rejection of the none algorithm.

Example The following is a non-normative example of a decoded ERT payload: 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.

Privacy Considerations

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.

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.

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.

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 .

Consumer Principal Privacy ERTs as defined in 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.

Security Considerations

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.

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.

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.

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

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.

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.

Third-Party Authorization Poisoning DNS TXT records (, 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.

JWT Security Implementations of the ERT () MUST comply with JWT Best Current Practices , 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.

Cryptographic Agility and Post-Quantum Considerations The MIA proof envelope () carries an explicit alg field to enable cryptographic agility. This document defines a single algorithm, Ed25519 , 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 , 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. 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 () and SHOULD address coexistence with deployed Ed25519 keys.

IANA Considerations The media type registrations below request names in the standards tree. Per Section 3.1 of , 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.

Well-Known URI: merchant-identity.json This document requests registration in the "Well-Known URIs" registry :

URI suffix:

merchant-identity.json

Change controller:

IETF

Specification document(s):

This document,

Status:

permanent

Related information:

None

Well-Known URI: mia-delegation.json This document requests registration in the "Well-Known URIs" registry :

URI suffix:

mia-delegation.json

Change controller:

IETF

Specification document(s):

This document,

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.

Media Type: application/merchant-identity+json This document requests registration of a new media type per :

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

Security considerations:

See of this document.

Interoperability considerations:

See 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

Media Type: application/merchant-delegation+json This document requests registration of a new media type per :

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

Security considerations:

See of this document. The MIDD MUST be signed by a key published at the subject domain's Key Directory; see .

Interoperability considerations:

See of this document.

Published specification:

This document, .

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

References Normative References Informative References IETF National Institute of Standards and Technology Global Legal Entity Identifier Foundation

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 .
• Added dedicated Non-Goals section () explicitly excluding trust scoring, ranking, endorsement, payment authorization, agent identity, identity of natural persons, and central registries.
• Added Relationship to Existing Work section () covering X.509/Web PKI, W3C VC/DID, OAuth Dynamic Client Registration, SPIFFE, and DNS-based identity.
• Added Issuance Models and Assurance Considerations section () 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 () including post-quantum considerations and ML-DSA reference.
• Tightened Key Directory caching, rotation, and unreachable-directory requirements ().
• Restructured Freshness and Revocation () 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.
• Registered media type application/merchant-delegation+json () and updated the third-party authorization section to use it.
• Added Versioning subsection () clarifying the independent version semantics of the Claims Object and the proof envelope.
• Added normative Domain Comparison rules () 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 ().
• Made the Key Directory dependency for MIDD-based third-party authorization explicit (); clarified that DNS-only authorization does not require subject-domain Key Directory.
• Added clock-skew tolerance for ERT iat/exp validation ().
• Added evidenceUris failure-handling guidance (): retrieval failure does not invalidate the MIA absent deployment-specific policy.
• Added MIA fetch failure handling and redirect prohibition in the verification procedure ().
• Added Issuer-Side Correlation privacy consideration ().
• Added a paragraph clarifying the architectural relationship between MIA and existing transport-layer agent identity mechanisms (Web Bot Auth, HTTP Message Signatures) in .
• Editorial improvements throughout.