v0.2.0 — Draft Specification

MIR Protocol

Memory Infrastructure Registry

An open specification for recording and verifying participation claims — cryptographically signed by the issuing domain, independently verifiable by anyone, and portable across systems without reliance on any central authority.

MIR Protocol defines the portable, domain-signed claim format. Policy decisions, trust tiers, and scoring are an optional application layer built on top.

Core Principles

Self-Contained Claims

Every claim carries an Ed25519 signature. Verification requires only the claim and the domain's public key. No registry call, no API key, no account.

No Central Authority

Registries provide discovery and availability. They are not trust anchors. They cannot forge, modify, or invalidate claims.

Non-Scoring

MIR records participation. It does not calculate trust, reputation, or behavioral rankings. Your policy engine applies your rules.

Non-Evaluative

MIR proves who signed a claim and that it hasn't been altered. It does not judge whether the claim is true.

Privacy-Minimizing

Subject identifiers are domain-scoped hashes. No plaintext PII enters the protocol. The same person has different hashes on different domains.

Survives Key Rotation

Historical claims remain verifiable even as domains rotate signing keys. Retired keys stay published with validity windows so verifiers can select the correct key over time.

Architecture

Claims flow from domains to verifiers. Registries are optional infrastructure — useful but architecturally replaceable.

  +--------------+          +--------------+          +------------+
  |    Domain    |  sign    |    Claim     |  verify  |  Verifier  |
  |  (key pair)  |----------| (portable)   |----------|  (anyone)  |
  +--------------+          +--------------+          +------------+
                                   |
                                   | optional
                                   v
                            +--------------+
                            |   Registry   |
                            |  (discover,  |
                            |  timestamp,  |
                            |    index)    |
                            +--------------+

Claim Structure

A MIR claim is a signed JSON document. It is the fundamental unit of the protocol.

{
  "mir": 1,
  "type": "mir.transaction.completed",
  "domain": "marketplace.example.com",
  "subject": "a55bea0a6788794ef1307951...f63ae618",
  "timestamp": "2026-02-16T15:30:00Z",
  "metadata": { "currency": "USD", "count": 1 },
  "keyFingerprint": "e3b0c44298fc1c149afbf4c8...7852b855",
  "sig": "base64url-encoded-ed25519-signature"
}

The keyFingerprint field is the key selector — it tells verifiers which of the domain's published public keys signed this claim. No trial-and-error required.

How to Implement

1

Understand the claim structure

Required fields, types, subject identifier derivation, and immutability rules.

2

Generate keys and publish

Create an Ed25519 key pair and publish the public key via DNS TXT at _mir-key.{domain} or .well-known/mir.json.

3

Implement canonical serialization

MIR Canonical JSON (MCJ): sort keys lexicographically, remove sig, compact JSON, encode as UTF-8. Defined normatively in the Signature Model. This produces the signing input.

4

Sign and verify claims

Sign canonical bytes with Ed25519. Encode signatures as base64url without padding (86 characters).

5

Validate against test vectors

Six normative test vectors with real Ed25519 signatures cover all verification scenarios.

6

Check conformance

Review the conformance requirements for signers, verifiers, and registries.

Specification Documents

The full protocol is defined across 11 documents.

# Document Description
01 Overview Architecture, properties, scope
02 Terminology Defined terms
03 Claim Format Claim structure, fields, types, encoding
04 Signature Model Canonical serialization, Ed25519, number handling
05 Domain Key Discovery DNS TXT, .well-known/mir.json, key lifecycle
06 Verification Process Deterministic verification algorithm, error codes
07 Registry Role What registries do and do not provide
08 Security Considerations Cryptographic and operational security
09 Threat Model Attack surface and mitigations
10 Non-Goals Explicit exclusions
11 Conformance MUST/SHOULD checklist and error codes

MIR stands for Memory Infrastructure Registry. This project is not related to Mirror Protocol, MIR token, or any cryptocurrency.