MTPROTO 1.2

1Scope

This document specifies MTPROTO, an interchange format for measurement results and for the statements of metrological traceability that accompany them. It defines a record structure, a canonical serialisation of that structure, and a signature scheme over the canonical form.

This document does not specify how records are transported, stored or indexed; it does not define accreditation requirements; and it does not prescribe measurement methods. Where a term of art from the international vocabulary of metrology is used, it is used with its established meaning.

The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY in this document are to be interpreted as described in RFC 2119 and RFC 8174, and only when they appear in capitals.

2Terminology

3Data model

A record is an object. The members defined in this version are listed below. Consumers MUST preserve members they do not recognise when re-serialising a record, and MUST NOT treat their presence as an error.

3.1Quantity objects

A quantity object reports one value. value and unit are required; u (standard uncertainty, expressed in the same unit) and k (coverage factor) are required for members of results and optional elsewhere. Where u is present and distribution is absent, "normal" is assumed.

{
  "quantity": "torque",
  "value": 41.83,
  "unit": "N.m",
  "u": 0.062,
  "k": 2,
  "distribution": "normal",
  "method": "reference transducer, 5-point rising"
}

Do not round in transit. A record carries the value as reported by the issuing laboratory. Presentation rounding is a decision for the consumer, and applying it before storage destroys information the uncertainty statement depends on.

4Units and quantities

The unit member MUST be a UCUM case-sensitive code. Free-text units such as "micron" or "deg C" are not conforming. A dimensionless ratio MUST use "1"; percent MUST use "%".

The quantity member names what was measured, using a dotted identifier. Implementations SHOULD use a registered name where one exists and MAY use a private name prefixed with x-. Registered names in 1.2:

The registry is deliberately short. Adding a name is a normative change and follows the process in §9.3; in practice most laboratories find that x- names cover their local vocabulary without needing one.

5Traceability chains

Each element of traceable_to identifies one reference standard used to obtain the reported results, and the record that certifies that standard:

{
  "standard": "Reference transducer, 100 N.m",
  "certificate": "urn:mtproto:4c81b0e2-77aa-41d9-9f0c-6b3d2a5e7181",
  "resolver": "https://records.example-lab.invalid/mtproto/"
}

resolver is optional and advisory. A consumer MAY append the certificate URN to the resolver base and fetch the referenced record; it MUST NOT treat a failure to do so as a failure of the record itself. Offline verification of a single record is always possible.

A chain is walked by repeatedly resolving certificate references until an anchor is reached. Implementations MUST detect cycles and SHOULD impose a depth limit; a limit of 32 is RECOMMENDED. Chains longer than six hops are unusual in practice and generally indicate that an intermediate record has been issued in error.

6Canonical form

Signatures are computed over a canonical serialisation so that a record survives reformatting. The canonical form of a record is its JSON serialisation with:

• object members sorted by Unicode code point of the member name;
• no insignificant whitespace;
• numbers serialised as specified in RFC 8785 (JCS);
• strings in UTF-8 with the minimal escaping JCS permits;
• the signature member removed.

The CBOR serialisation defined in §8 is canonicalised per RFC 8949 §4.2.1 and signed over the same logical content, so a record may be converted between the two encodings without invalidating its signature.

7Signatures

A record SHOULD carry a signature member. The value is an object with alg, key_id and sig; the only algorithm defined in 1.2 is "ed25519", and sig is the base64url encoding, without padding, of the signature over the canonical form.

"signature": {
  "alg": "ed25519",
  "key_id": "mtp:ed25519:8Qf3…c1a7",
  "sig": "MEUCIQDf…9pQ"
}

key_id is the multibase-encoded public key prefixed with mtp:ed25519:, which makes a record self-contained: verification needs no directory lookup. Binding a key to a legal entity is out of scope for this document and is expected to happen through whatever accreditation or contractual arrangement already exists between the parties.

Key rotation. Records are signed at issue and not re-signed. A verifier checks the signature against the key named in the record, not against the issuer's current key. Revocation is therefore a question about the record's validity, not its signature, and is handled by the issuer publishing a superseding record.

8Media types

The bundle type exists for the common case of handing someone an entire chain at once: a flat archive of records plus a manifest.json naming the entry point. Bundles are a convenience and carry no additional semantics.

9Conformance

9.1Producers

A conforming producer emits records that validate against the normative schema for the version declared in mtproto, uses UCUM codes for every unit, and reports u and k for every member of results.

9.2Consumers

A conforming consumer accepts any record whose major version it supports, preserves unknown members, verifies signature when present, and does not rely on member ordering. A consumer that reports a record as verified MUST have checked the signature over the canonical form of §6, not over the bytes as received.

9.3Changes

Normative changes are published as a new minor version after a review period of at least sixty days. A minor version never removes a member or changes the meaning of an existing one; changes that would do so require a new major version, and no major version beyond 1 is planned. Editorial corrections are published as patch releases and listed in the version history.