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 how that client can obtain verifiable merchant identity information about the payee before completing the transaction. Specifically, this document defines a Merchant Identity Assertion (MIA): a JSON document that attests to the verifiable identity of a merchant entity and carries an embedded cryptographic proof. It defines the assertion object structure, required and optional fields, the proof object, key discovery via well-known URIs, validity semantics, and an optional signed Evaluation Result Token for pre-transaction verification. This document is intended to complement, not replace, existing agent identity and payment authorization protocols.

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

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

G6. Forward Compatibility:

The MIA format MUST support extension through optional fields without breaking existing implementations.

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.

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-EdDSA-v1" for assertions signed per this document. This value identifies the proof format defined in this section. Future documents MAY define additional proof type values.

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 Ed25519 signature over the canonical Claims Object, 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.

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 Content-Type application/json. This document does not define a dedicated media type for MIDD documents. Relying parties MUST verify the MIDD proof using a key hosted at the subject domain before accepting the named issuer as authorized. Relying parties MUST treat an MIA as invalid if neither authorization mechanism is satisfied.

Signing and Verification

Signing Algorithm All MIA signatures MUST use the Edwards-Curve Digital Signature Algorithm (EdDSA) with the Ed25519 curve . No other algorithms are defined by this document.

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 MUST include:

kty:

"OKP"

crv:

"Ed25519"

use:

"sig"

kid:

A stable, unique, URL-safe identifier.

x:

The base64url-encoded Ed25519 public key.

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.

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 Ed25519 private key corresponding to the chosen kid.
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.
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-EdDSA-v1". If not, reject. Implementations MUST NOT accept assertions with unknown proof type 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 domain of this URI matches the issuer.domain field in the assertion as a consistency check. If they do not match, the assertion MUST be rejected.
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 Ed25519 signature in proof.proofValue against the canonical signing input using the located public key.
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 (case-insensitive FQDN comparison).
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 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 MAY support early revocation by including a revocationUri extension field. If present, this field MUST be an HTTPS URI that resolves to a JSON object with a boolean "revoked" field. Relying parties MAY check this URI before relying on an assertion. Issuers MUST re-issue assertions promptly when material identity information changes (e.g., legal name change, jurisdiction change, loss of business registration). 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.

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.

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

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.

IANA Considerations

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

References Normative References Informative References IETF 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- 01, which addresses agent-side identity in a manner that this document's merchant-side framework is designed to complement.