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

6.1. X.509 and Web PKI

X.509 certificates bind a public key to a domain name, and Extended Validation (EV) certificates additionally attest to the legal entity operating the domain. However, EV identity information is presented at the TLS layer, is not exposed as structured, queryable data to autonomous agents, and is not designed to be consumed as a transaction-time identity assertion. Certificate Transparency [RFC9162] provides public auditability of certificate issuance but does not surface legal entity claims in a form suitable for machine evaluation. MIA produces a structured JSON assertion that an agent can parse, validate, and retain as an audit artifact alongside transaction records.¶

6.2. W3C Decentralized Identifiers and Verifiable Credentials

The W3C Verifiable Credentials Data Model defines a general framework for cryptographically verifiable claims about a subject, and Decentralized Identifiers (DIDs) define resolver-based identity. An MIA could in principle be expressed as a constrained Verifiable Credential profile. This document defines a narrower mechanism intentionally: discovery via a single well-known URI rather than DID resolution across heterogeneous methods, a fixed claim schema scoped to merchant identity, and a wire format optimized for agent verification rather than holder presentation. Future work MAY define an MIA-to-VC mapping for deployments that require it.¶

6.3. OAuth Dynamic Client Registration

OAuth 2.0 Dynamic Client Registration [RFC7591] enables a client to register identity metadata with an authorization server. It addresses a different problem: client onboarding within a trust relationship mediated by an authorization server. MIA addresses transaction-time merchant verification across trust boundaries, with no central authorization server and no prior registration relationship between the verifying agent and the merchant.¶

6.4. SPIFFE and Workload Identity

SPIFFE defines workload identity within a trust domain, typically a single organization or federation thereof. MIA addresses cross-organization identity verification between parties with no pre-established trust relationship.¶

6.5. DNS-Based Identity (DANE, TLSA)

DNS-based mechanisms such as DANE [RFC6698] bind keys or certificates to domain names via DNSSEC. MIA uses DNS only as one of two third-party authorization mechanisms (Section 8.2) and carries the structured legal entity claims that DNS records are not designed to convey. A future profile MAY define a DNS record type for MIA discovery; this document defines HTTPS well-known URI discovery as the primary mechanism for compatibility with the broader deployment of HTTPS over DNSSEC.¶

7.1. Claim Fields (Required)

version (integer):

The MIA specification version. This document defines version 1. Implementations MUST reject assertions with unrecognized version values.¶

subject (string):

The subject domain. MUST be a fully qualified domain name (FQDN) expressed in lowercase. MUST match the domain from which the assertion is served or the domain for which the issuer holds explicit authorization per Section 8.2.¶

legalName (string):

The registered legal name of the merchant entity as it appears in the jurisdiction of incorporation or registration.¶

entityType (string):

The legal entity type. MUST be one of: "corporation", "llc", "partnership", "sole_proprietor", "cooperative", "nonprofit", "government", or "other".¶

jurisdiction (string):

The ISO 3166-1 alpha-2 country code of the primary jurisdiction of registration (e.g., "US", "GB", "DE"). Where a subdivision-level identifier is available and relevant, implementors MAY use an ISO 3166-2 code (e.g., "US-AZ") in the extensions field.¶

issuedAt (string):

The UTC datetime at which this assertion was issued, in RFC 3339 format (e.g., "2026-04-15T00:00:00Z").¶

expiresAt (string):

The UTC datetime after which this assertion MUST NOT be accepted, in RFC 3339 format. Issuers SHOULD NOT set validity periods exceeding 365 days.¶

issuer (object):

An object identifying the signing entity. MUST contain:¶

name (string):

Human-readable issuer name.¶

domain (string):

Issuer FQDN.¶

keyDirectory (string):

HTTPS URI of the issuer's Key Directory (Section 10.2).¶

7.2. Claim Fields (Optional)

registrationId (string):

A jurisdiction-specific business registration identifier (e.g., EIN, Companies House number, GLEIF LEI [LEI]).¶

evidenceUris (array of strings):

HTTPS URIs referencing third-party authoritative records that corroborate the identity claims in this assertion (e.g., a public government business registry record, a GLEIF LEI record). Each URI MUST be publicly accessible over HTTPS without authentication. Failure to retrieve or parse an evidenceUris value (network failure, non-200 HTTP status, redirect to an authentication-gated resource, or unparseable response) does not, by itself, invalidate the MIA. Relying parties MAY define policies (per Section 9.4) that condition acceptance on successful evidence retrieval for high-value or regulated transactions; such policies are deployment-specific and out of scope for this document.¶

extensions (object):

A JSON object for implementation-specific fields. Relying parties MUST ignore unrecognized keys. Extension keys MUST use reverse domain notation (e.g., "com.example.customField").¶

7.3. Proof Object

The proof field MUST be present in a signed MIA and MUST be a JSON object containing:¶

type (string):

MUST be "MerchantIdentityProof-v1" for assertions signed per this document. This value identifies the proof envelope format defined in this section. Future documents MAY define additional proof type values for structurally different envelopes.¶

alg (string):

The signature algorithm identifier. This document defines a single value: "Ed25519", indicating the Edwards-Curve Digital Signature Algorithm with the Ed25519 curve [RFC8032]. Future specifications MAY register additional algorithm identifiers via Standards Action; see Section 14.9. Implementations MUST reject assertions with unrecognized alg values and MUST NOT attempt to infer an algorithm from the key material alone.¶

created (string):

The UTC datetime at which the proof was created, in RFC 3339 format. MUST match the issuedAt claim field.¶

verificationMethod (string):

An HTTPS URI of the form: {issuer.keyDirectory}#{kid} where {kid} is the key identifier within the Key Directory used to produce this signature. This field anchors the signature to a specific, named key and provides a deterministic path for key retrieval without requiring the relying party to trust the payload-embedded keyDirectory value in isolation (see Section 14, trust bootstrap).¶

proofValue (string):

The base64url-encoded signature over the canonical Claims Object, produced using the algorithm named in the alg field, as defined in Section 10.3.¶

The keyDirectory URI appears in the assertion payload, which could raise a trust bootstrap concern if a relying party were to trust the payload as the sole source of key discovery information. To avoid this, the relying party MUST derive the authoritative key directory location from proof.verificationMethod and MUST NOT rely on issuer.keyDirectory as the sole key discovery path. Relying parties SHOULD additionally verify that the domain in verificationMethod matches issuer.domain as a consistency check.¶

7.4. Wire Format

An MIA is serialized as a single JSON document. The Claims Object fields (Section 7.1 and Section 7.2) and the proof field (Section 7.3) appear at the top level of this JSON document.¶

The document MUST be served over HTTPS with:¶

Content-Type: application/merchant-identity+json

Implementations MUST NOT serve or accept MIA documents over plain HTTP.¶

7.5. Versioning

The version field in the Claims Object identifies the MIA specification version, not the issuer's software version or assertion content version. This document defines version 1.¶

The version field follows a strict-rejection model: relying parties MUST reject assertions with unrecognized version values. New claim fields, optional or required, do not increment the version number; they are added through extensions (Section 7.2) or through new optional fields defined by future documents that update this specification.¶

The version number is incremented only when an incompatible structural change is made to the Claims Object such that an implementation built to an earlier version could not safely interpret the assertion. Examples of incompatible changes include: removal of a required field, change in the canonicalization algorithm, or change in the meaning of an existing field.¶

The proof.type field follows the same model independently. The version number in the proof type identifier (currently "MerchantIdentityProof-v1") increments only on incompatible changes to the proof envelope structure itself, distinct from algorithm changes (which are signaled via proof.alg per Section 14.9).¶

7.6. Example

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

{
  "version": 1,
  "subject": "supplier.example.com",
  "legalName": "Example Supply Corporation",
  "entityType": "corporation",
  "jurisdiction": "US",
  "issuedAt": "2026-04-15T00:00:00Z",
  "expiresAt": "2027-04-15T00:00:00Z",
  "issuer": {
    "name": "Example Trust Registry",
    "domain": "trust.example.org",
    "keyDirectory": "https://trust.example.org/.well-known/jwks.json"
  },
  "registrationId": "12-3456789",
  "evidenceUris": [
    "https://www.gleif.org/lei/5493001KJTIIGC8Y1R12"
  ],
  "proof": {
    "type": "MerchantIdentityProof-v1",
    "alg": "Ed25519",
    "created": "2026-04-15T00:00:00Z",
    "verificationMethod":
      "https://trust.example.org/.well-known/jwks.json#key-01",
    "proofValue": "MGViZDcwYTk...86-char-base64url-signature"
  }
}

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

8.2. Third-Party Issuer Authorization

Merchants MAY authorize a third-party issuer to publish an MIA on their behalf. Before relying on a third-party MIA, the relying party MUST verify that the issuer is authorized by the subject domain using one of the following mechanisms:¶

a) DNS TXT Authorization Record:¶

The subject domain MUST publish a DNS TXT record at the name _mia-auth.{subject-domain}:¶

_mia-auth.supplier.example.com. IN TXT
    "v=mia1; issuer=trust.example.org"

The issuer value MUST exactly match the issuer.domain field in the MIA.¶

b) HTTP Delegation Document:¶

The subject domain MUST publish a Merchant Identity Delegation Document (MIDD) at:¶

https://{subject-domain}/.well-known/mia-delegation.json

An MIDD is a distinct document type from an MIA. It MUST be a JSON object signed using the same proof structure defined in Section 7.3 and MUST contain:¶

version (integer):

MUST be 1.¶

type (string):

MUST be "MerchantIdentityDelegation".¶

subject (string):

The merchant domain granting delegation.¶

authorizedIssuer (string):

The FQDN of the authorized third-party issuer.¶

issuedAt (string):

RFC 3339 datetime.¶

expiresAt (string):

RFC 3339 datetime.¶

proof (object):

Per Section 7.3, signed by a key published at the subject domain's Key Directory.¶

The MIDD MUST be served over HTTPS with:¶

Content-Type: application/merchant-delegation+json

Relying parties MUST verify the MIDD proof using a key hosted at the subject domain's Key Directory before accepting the named issuer as authorized. See Section 15.4 for the media type registration.¶

A subject domain that authorizes a third-party issuer via MIDD MUST publish a Key Directory at the location identified by the proof.verificationMethod field of the MIDD itself. The Key Directory MUST contain the public key whose corresponding private key signed the MIDD. This Key Directory is operated by the subject domain and is distinct from any Key Directory operated by the third-party issuer to which delegation is granted. A subject domain that uses only DNS TXT third-party authorization (mechanism a) is not required to operate a Key Directory.¶

Relying parties MUST treat an MIA as invalid if neither authorization mechanism is satisfied.¶

9.1. Self-Issuance

A merchant may self-issue an MIA: the issuer.domain equals the subject, and the assertion is signed by a key published at the subject domain's Key Directory. Self-issuance demonstrates control of the subject domain at the time of signing and provides cryptographic attribution of the claims to whoever controls the domain. It does not, by itself, demonstrate that the legal entity claims (legalName, entityType, jurisdiction, registrationId) correspond to the actual entity operating the domain.¶

9.2. Third-Party Issuance

A merchant may authorize a third-party issuer per Section 8.2. The relying party can then evaluate the assertion as the joint product of two signals: the merchant's authorization of the issuer (proven by the DNS TXT record or signed delegation document at the subject domain) and the issuer's attestation to the merchant's identity claims. The strength of the resulting assurance depends on the practices of the named issuer, which are out of scope for this document.¶

9.3. External Evidence

An MIA MAY include the optional evidenceUris field (Section 7.2), referencing publicly accessible authoritative records that corroborate identity claims (for example, a GLEIF LEI record, a government business registry entry, or a public regulator filing). The evidenceUris field allows a relying party, or an automated verification service acting on the relying party's behalf, to check the consistency of the MIA's claims against independent sources at verification time.¶

This document does not require relying parties to fetch or validate evidenceUris. Implementations MAY define policies that condition acceptance on successful evidence retrieval and consistency checks; such policies are deployment-specific.¶

9.4. Relying Party Policy

Relying parties operating in regulated, high-value, or otherwise high-stakes contexts SHOULD define explicit policies for which issuance models they accept. Examples of policies a relying party MAY adopt include:¶

• Accept only third-party-issued MIAs from issuers on a maintained allowlist.¶
• Accept self-issued MIAs only for transactions below a configured threshold.¶
• Require an evidenceUris value resolving to a GLEIF LEI record for transactions exceeding a configured threshold.¶
• Require a fresh assertion (recently retrieved from the well-known URI rather than served from cache) for transactions within a defined recency window.¶

Such policies are out of scope for this specification. The protocol exposes the inputs; the policy decisions belong to the relying party and its principals.¶

10.1. Signing Algorithm

This document defines a single mandatory-to-implement signature algorithm: the Edwards-Curve Digital Signature Algorithm (EdDSA) with the Ed25519 curve [RFC8032], identified in the proof.alg field as "Ed25519". All conforming issuers and relying parties MUST support this algorithm.¶

Future specifications MAY define additional algorithm identifiers; see Section 14.9 for the extension model and post-quantum migration considerations.¶

10.2. Key Directory

Issuers MUST publish a JSON Web Key Set [RFC7517] at the HTTPS URI in the issuer.keyDirectory field. This document is the Key Directory.¶

Key Directory entries used for MIA signing with the Ed25519 algorithm MUST include:¶

kty:

"OKP"¶

crv:

"Ed25519"¶

use:

"sig"¶

kid:

A stable, unique, URL-safe identifier.¶

x:

The base64url-encoded Ed25519 public key.¶

JWK parameters MUST be appropriate for the algorithm identified in the proof.alg field of the assertion the key is used to verify, per [RFC7517]. Specifications defining additional algorithm identifiers (Section 14.9) MUST specify the corresponding JWK parameter requirements.¶

The Key Directory MUST be served over HTTPS with appropriate HTTP caching headers. Relying parties SHOULD cache key material per those headers to reduce verification latency and network load. Implementations MUST NOT cache key material beyond the lifetime indicated by the HTTP cache directives, and MUST re-fetch on signature verification failure to accommodate key rotation. Issuers SHOULD set cache lifetimes that balance verification performance against key rotation responsiveness; values between one hour and 24 hours are RECOMMENDED.¶

If the Key Directory is unreachable during verification, relying parties MUST NOT accept the assertion as verified. Relying parties MAY retry per their own operational policies but MUST NOT fall back to cached keys whose cache lifetime has expired.¶

10.3. Signing Procedure

To produce an MIA signature, the issuer MUST:¶

1. Construct the Claims Object containing all required fields (Section 7.1) and any optional fields (Section 7.2), excluding the proof field.¶
2. Produce the canonical signing input by serializing the Claims Object as a JSON string with keys in lexicographic order and no insignificant whitespace [RFC8785].¶
3. Sign the UTF-8 encoding of the canonical string using the private key corresponding to the chosen kid, producing a signature with the algorithm identified by proof.alg.¶
4. Encode the resulting 64-byte signature as a base64url string (proofValue).¶
5. Construct the proof object (Section 7.3) with the type, created, verificationMethod, and proofValue fields.¶
6. Merge the Claims Object and proof object into a single JSON document (Section 7.4).¶

10.4. Verification Procedure

A relying party MUST perform the following steps:¶

1. Retrieve the MIA document via HTTPS. If the retrieval fails (network error, DNS resolution failure, TLS validation failure, non-2xx HTTP status, unfollowed redirect, or response exceeding a relying-party-defined maximum size), the relying party MUST treat the verification result as "no MIA available" and MUST NOT proceed with subsequent verification steps. Implementations MUST NOT automatically follow HTTP redirects when retrieving an MIA from the well-known URI; redirected responses MUST be treated as retrieval failure. The maximum response size SHOULD be at least 64 kilobytes and SHOULD NOT exceed 1 megabyte for any deployment.¶
2. Verify the Content-Type is application/merchant-identity+json.¶
3. Parse the JSON document. Extract the proof field. If absent, reject the assertion.¶
4. Verify proof.type is "MerchantIdentityProof-v1" and that proof.alg names a recognized algorithm. If either check fails, reject. Implementations MUST NOT accept assertions with unknown proof type or alg values.¶
5. Extract the key directory URI and kid from proof.verificationMethod by splitting on the last "#" character. The key directory URI is the portion before "#"; the kid is the portion after. The relying party MUST use this URI as the authoritative key directory location. It MUST also verify that the authority component of this URI matches the issuer.domain field in the assertion as a consistency check, using the Domain Comparison rules defined in Section 2. If they do not match, the assertion MUST be rejected. The path component of the URI MAY differ from any path implied by issuer.keyDirectory; only the authority component is compared.¶
6. Retrieve the Key Directory over HTTPS from the extracted URI.¶
7. Locate the JWK entry with the matching kid. If absent, reject.¶
8. Reconstruct the canonical signing input from the assertion document with the proof field removed, following the procedure in Section 10.3, step 2.¶
9. Verify the signature in proof.proofValue against the canonical signing input using the located public key and the algorithm identified by proof.alg.¶
10. Verify that the current time is strictly between issuedAt and expiresAt (exclusive).¶
11. Verify that the subject field matches the domain for which verification is being performed, using the Domain Comparison rules defined in Section 2.¶
12. If issuer.domain differs from subject, verify third-party authorization per Section 8.2.¶
13. If all steps succeed, the assertion is valid.¶

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

11.1. Validity Periods and Re-Issuance

Relying parties MUST NOT accept assertions for which the current time is at or after the expiresAt value.¶

Issuers SHOULD limit assertion validity periods. Validity periods of 90 days or less are RECOMMENDED for issuers with automated re-issuance pipelines.¶

Issuers MUST re-issue assertions promptly when material identity information changes. Re-issuance is the primary mechanism for identity revocation; the previous assertion is allowed to expire on its own schedule unless explicit revocation is also signaled.¶

Relying parties in high-stakes or regulated contexts SHOULD retrieve a fresh assertion rather than relying on a cached copy when the cached copy is older than 24 hours, regardless of the expiresAt value.¶

Issuers MAY set HTTP cache directives on the MIA endpoint. Relying parties MAY honor these directives but MUST NOT cache an MIA beyond its expiresAt value regardless of HTTP cache headers, and MUST NOT cache an MIA whose Cache-Control directives explicitly forbid caching. Where issuer-supplied cache directives permit caching beyond the recency thresholds defined in this section, the more restrictive policy applies.¶

11.2. Explicit Revocation

Issuers MAY support explicit revocation by including a revocationUri extension field in the Claims Object. If present, this field MUST be an HTTPS URI that resolves to a JSON object with at least a boolean "revoked" field and a "checkedAt" string in RFC 3339 format indicating when the revocation status was last updated by the issuer.¶

Relying parties MAY check this URI before relying on an assertion. Relying parties in high-stakes or regulated contexts SHOULD do so. The revocationUri endpoint MUST be served over HTTPS with valid certificate validation.¶

This document does not define a normative revocation list format. A future specification MAY define one for deployments at scale.¶

11.3. Key Rotation

Operational revocation through signing-key rotation is supported by the Key Directory mechanism (Section 10.2). When an issuer rotates keys, it removes the old key from its Key Directory. Relying parties that follow the cache requirements in Section 10.2 will fail signature verification on assertions signed with revoked keys once the cache lifetime elapses.¶

Issuers MUST remove compromised keys from the Key Directory without delay and SHOULD re-issue all outstanding assertions previously signed with the compromised key.¶

12.1. Claims

iss (string, REQUIRED):

The domain of the verification service.¶

sub (string, REQUIRED):

The subject domain that was verified.¶

iat (NumericDate, REQUIRED):

Time of ERT issuance.¶

exp (NumericDate, REQUIRED):

Expiry time. MUST NOT exceed iat + 300 seconds to limit replay exposure.¶

jti (string, REQUIRED):

A cryptographically random, globally unique token identifier for replay detection.¶

mia_verified (boolean, REQUIRED):

True if a valid, unexpired MIA was located and successfully verified for the subject domain per Section 10.4. False otherwise.¶

mia_subject (string, REQUIRED when mia_verified is true):

The subject field from the verified MIA.¶

mia_issued_at (string, REQUIRED when mia_verified is true):

The issuedAt field from the verified MIA.¶

mia_issuer_domain (string, REQUIRED when mia_verified is true):

The issuer.domain field from the verified MIA.¶

No consumer or agent identity fields SHALL be included in an ERT without explicit principal consent.¶

12.2. Signing

The ERT MUST be signed as a JWS [RFC7515] using EdDSA with Ed25519 [RFC8032]. The JWS Protected Header MUST include:¶

alg:

"EdDSA"¶

kid:

Key identifier in the verification service's Key Directory.¶

Implementations MUST follow JWT Best Current Practices [RFC8725], including algorithm validation and rejection of the none algorithm.¶

12.3. Example

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

{
  "iss": "trust.example.org",
  "sub": "supplier.example.com",
  "iat": 1776254400,
  "exp": 1776254700,
  "jti": "f7a2c9e1b4d8",
  "mia_verified": true,
  "mia_subject": "supplier.example.com",
  "mia_issued_at": "2026-04-15T00:00:00Z",
  "mia_issuer_domain": "trust.example.org"
}

A relying party MAY include the ERT in payment metadata or transaction records to provide downstream parties with a verifiable audit artifact that pre-transaction merchant identity verification occurred.¶

13.1. Minimal Disclosure

MIA documents MUST NOT include personal data about natural persons except where the subject is a sole proprietor, such disclosure is legally required in the jurisdiction, and the natural person has provided explicit consent.¶

13.2. Evidence URI Privacy

The evidenceUris field, if included, reveals which third-party registries were used to corroborate the merchant's identity. Issuers SHOULD assess the privacy implications of each URI before inclusion.¶

13.3. Relying Party Query Privacy

Real-time retrieval of MIAs from well-known URIs or Key Directories reveals which merchants a relying party intends to transact with. Implementations SHOULD use caching and pre-fetching strategies to reduce this correlation risk.¶

13.4. Issuer-Side Correlation

An issuer hosting MIAs at well-known URIs, and the operator of any Key Directory, observes which network endpoints retrieve which assertions. Operators of verification-as-a-service offerings, third-party issuers, and CDNs in the retrieval path can therefore construct correlation graphs linking relying parties to merchant-domain queries. Issuers and intermediaries SHOULD NOT log or retain the source IP, principal identifier, or session identifier of MIA retrievals beyond what is operationally necessary, and MUST NOT share such retrieval metadata with third parties without the requesting relying party's consent. Operators of verification services that issue ERTs on behalf of relying parties MUST ensure that retrieval logs are not cross-linked with ERT issuance records in ways that would defeat the consumer principal privacy requirements in Section 13.5.¶

13.5. Consumer Principal Privacy

ERTs as defined in Section 12 MUST NOT include consumer or agent principal identifiers. Verification services MUST NOT log consumer identifiers in association with merchant verification events without explicit consumer consent.¶

14.1. Replay Attacks

The ERT jti claim provides a unique token identifier. Relying parties MUST maintain a jti cache for at least the duration of the token's validity window (exp - iat), plus a clock-skew allowance of at least 60 seconds, and MUST reject any ERT whose jti has been seen previously. The RECOMMENDED maximum ERT validity of 300 seconds bounds the size of this cache.¶

Relying parties verifying iat and exp claims SHOULD permit clock skew of up to 60 seconds in either direction relative to the relying party's local clock. Implementations operating in environments with reliable time synchronization (e.g., NTP-disciplined clocks) MAY use a smaller skew allowance. Implementations MUST NOT permit skew exceeding 300 seconds, as doing so would extend the effective replay window beyond the token's intended lifetime.¶

14.2. Key Compromise

If an issuer's signing key is compromised, all MIA documents signed with that key MUST be treated as invalid. Issuers MUST maintain key rotation procedures and MUST remove compromised keys from their Key Directory promptly. Relying parties that cache Key Directory material MUST re-fetch on signature verification failure.¶

14.3. Domain Transfer

An MIA is bound to a domain name. Transfer of that domain to a new owner does not automatically invalidate outstanding assertions. Issuers MUST implement procedures to detect domain transfer and revoke or re-evaluate affected assertions without delay.¶

14.4. Malicious Issuers

A third-party issuer operating in bad faith may publish false assertions. Relying parties SHOULD NOT treat all issuers as equally trustworthy. Relying parties MAY maintain allowlists of trusted issuer domains and SHOULD treat assertions from unknown issuers with heightened scrutiny. The third-party authorization requirement in Section 8.2 ensures that an issuer cannot publish an MIA for a domain that has not explicitly authorized it, but does not guarantee the issuer itself is trustworthy.¶

14.5. Stale Assertions

Merchant legal standing may change after assertion issuance (e.g., insolvency, license revocation, sanctions designation). Relying parties in regulated industries MUST NOT treat an MIA as sole evidence of current compliance and SHOULD supplement MIA verification with jurisdiction-appropriate checks for high-value or high-risk transactions.¶

14.6. Downgrade Attacks

An attacker with network access could substitute an older but still-valid MIA for a more recently issued one. Relying parties SHOULD record the issuedAt timestamp of the assertion used in a transaction and SHOULD reject assertions whose issuedAt predates their recency threshold for the transaction context.¶

14.7. Third-Party Authorization Poisoning

DNS TXT records (Section 8.2, mechanism a) are susceptible to cache poisoning if DNSSEC is not deployed. Implementations MUST use DNSSEC-validated resolution where available when performing DNS-based third-party authorization checks. HTTP delegation documents (mechanism b) MUST be retrieved over HTTPS with certificate validation; relying parties MUST reject delegation documents served without a valid TLS certificate.¶

14.8. JWT Security

Implementations of the ERT (Section 12) MUST comply with JWT Best Current Practices [RFC8725], including:¶

• Explicitly validating the alg header value.¶
• Rejecting tokens with alg: "none".¶
• Validating iss, sub, iat, exp, and jti before acting on any token.¶
• Not relying on unverified header parameters for security decisions.¶

14.9. Cryptographic Agility and Post-Quantum Considerations

The MIA proof envelope (Section 7.3) carries an explicit alg field to enable cryptographic agility. This document defines a single algorithm, Ed25519 [RFC8032], as mandatory to implement. Future specifications MAY register additional algorithm identifiers via Standards Action, including post-quantum signature algorithms standardized by NIST such as ML-DSA [FIPS204], and composite signature schemes that combine a classical and a post-quantum algorithm in a single proof.¶

An MIA is a signed assertion, not an encrypted payload. The "harvest now, decrypt later" threat model applicable to confidentiality-protected traffic does not apply directly to MIA documents. The post-quantum concern relevant to this specification is the future forgeability of long-lived merchant signing keys: an adversary in possession of a cryptographically relevant quantum computer could, in principle, recover an Ed25519 private key from observed public-key material and use it to forge assertions. Issuers SHOULD therefore treat assertion validity periods and signing-key rotation cadence as the primary mitigations available within the bounds of this document.¶

Implementations consuming MIAs SHOULD be designed to accommodate additional algorithm identifiers in the proof.alg field without requiring changes to the envelope format or wire structure. Specifications introducing new algorithms MUST define the corresponding JWK parameters in the Key Directory (Section 10.2) and SHOULD address coexistence with deployed Ed25519 keys.¶

15.1. Well-Known URI: merchant-identity.json

This document requests registration in the "Well-Known URIs" registry [RFC8615]:¶

URI suffix:

merchant-identity.json¶

Change controller:

IETF¶

Specification document(s):

This document, Section 8.1¶

Status:

permanent¶

Related information:

None¶

15.2. Well-Known URI: mia-delegation.json

This document requests registration in the "Well-Known URIs" registry [RFC8615]:¶

URI suffix:

mia-delegation.json¶

Change controller:

IETF¶

Specification document(s):

This document, Section 8.2¶

Status:

permanent¶

Related information:

Used to publish a Merchant Identity Delegation Document (MIDD) authorizing a named third-party issuer to publish MIAs on behalf of the subject domain.¶

15.3. Media Type: application/merchant-identity+json

This document requests registration of a new media type per [RFC6838]:¶

Type name:

application¶

Subtype name:

merchant-identity+json¶

Required parameters:

none¶

Optional parameters:

version: The MIA version number (integer). Defaults to 1 if absent.¶

Encoding considerations:

Binary (UTF-8 encoded JSON per [RFC8259]).¶

Security considerations:

See Section 14 of this document.¶

Interoperability considerations:

See Section 4 of this document.¶

Published specification:

This document.¶

Applications that use this media type:

Autonomous agents performing pre-transaction merchant identity verification; verification services issuing Evaluation Result Tokens; merchant identity registries.¶

Fragment identifier considerations:

None.¶

Additional information:

Deprecated alias names for this type: None. Magic number(s): None. File extension(s): .mia.json. Macintosh file type code(s): None.¶

Person & email address to contact for further information:

founder@registeredbrands.ai¶

Intended usage:

COMMON¶

Restrictions on usage:

None.¶

Author:

Robb Anders¶

Change controller:

IETF¶

15.4. Media Type: application/merchant-delegation+json

This document requests registration of a new media type per [RFC6838]:¶

Type name:

application¶

Subtype name:

merchant-delegation+json¶

Required parameters:

none¶

Optional parameters:

version: The MIDD version number (integer). Defaults to 1 if absent.¶

Encoding considerations:

Binary (UTF-8 encoded JSON per [RFC8259]).¶

Security considerations:

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

Interoperability considerations:

See Section 4 of this document.¶

Published specification:

This document, Section 8.2.¶

Applications that use this media type:

Merchant Identity Assertion (MIA) issuers and verifiers; relying parties evaluating third-party-issued MIAs.¶

Fragment identifier considerations:

None.¶

Additional information:

Deprecated alias names for this type: None. Magic number(s): None. File extension(s): .midd.json. Macintosh file type code(s): None.¶

Person & email address to contact for further information:

founder@registeredbrands.ai¶

Intended usage:

COMMON¶

Restrictions on usage:

None.¶

Author:

Robb Anders¶

Change controller:

IETF¶