Merchant Identity Assertions for Autonomous Commerce

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

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

5.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 6.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".¶

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

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

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

5.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-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 Section 11, trust bootstrap).¶

proofValue (string):

The base64url-encoded Ed25519 [RFC8032] signature over the canonical Claims Object, as defined in Section 7.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.¶

5.4. Wire Format

An MIA is serialized as a single JSON document. The Claims Object fields (Section 5.1 and Section 5.2) and the proof field (Section 5.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.¶

5.5. Example

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

{
  "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-EdDSA-v1",
    "created": "2026-04-15T00:00:00Z",
    "verificationMethod":
      "https://trust.example.org/.well-known/jwks.json#key-01",
    "proofValue": "z3FXQjecMBCm...base64url-signature"
  }
}

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

6.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 5.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 5.3, 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.¶

7.1. Signing Algorithm

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

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

7.3. Signing Procedure

To produce an MIA signature, the issuer MUST:¶

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

7.4. 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 Section 7.3, 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 Section 6.2.¶
13. If all steps succeed, the assertion is valid.¶

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

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

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

9.3. Example

The following is a non-normative example of a decoded ERT payload:¶

{
  "iss": "trust.example.org",
  "sub": "supplier.example.com",
  "iat": 1744934400,
  "exp": 1744934700,
  "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.¶

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

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

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

10.4. Consumer Principal Privacy

ERTs as defined in Section 9 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.¶

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

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

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

11.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 6.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.¶

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

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

11.7. Third-Party Authorization Poisoning

DNS TXT records (Section 6.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.¶

11.8. JWT Security

Implementations of the ERT (Section 9) 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.¶

12.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 6.1¶

Status:

permanent¶

Related information:

None¶

12.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 6.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.¶

12.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 11 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¶