ODP Object ID Compatibility Profile · v0.5 draft

Optional profile. Normative core rules remain in SPEC.md.

Purpose

This profile makes an ODP passport serve two complementary goals with one document:

  1. Authenticity (ODP core): is the object in front of you the registered original? Answered by on-chain anchors — dataHash, fileHash, image hashes, seal verification (SPEC §10–§11) — plus institutional proofs (submitProof).
  2. Theft documentation and recovery (Object ID): if the object is lost or stolen, is there a description good enough for police, customs, insurers, and databases such as INTERPOL's stolen-art registry? Answered by the Object ID checklist data captured below, cryptographically timestamped at mint.

The two goals reinforce each other: the same distinguishing features that let an investigator identify a recovered painting also let an expert distinguish an original from a physical copy. A counterfeit may carry a cloned label or a copied QR code — it will not carry the original's repaired 3 cm tear, its stretcher inscription, or its exact craquelure pattern, and those facts are hash-anchored on-chain with a mint timestamp that predates the dispute.

Relationship to the Object ID standard

Object ID is an international documentation standard for cultural goods: nine information categories plus four steps (photograph → identify categories → write description → store securely). Rights are held by ICOM (International Council of Museums).

Trademark note: this profile is compatible with the Object ID checklist. It is not affiliated with, endorsed by, or certified by ICOM or the J. Paul Getty Trust. Implementations MUST NOT present ODP passports as official Object ID records.

Category mapping

Object ID category passport.json v0.5 field Profile requirement
1. Type of object domain, physical.category required
2. Materials & techniques physical.medium, physical.materials required
3. Measurements physical.dimensions (and physical.weight when meaningful) required
4. Inscriptions & markings physical.marks required when present on the object
5. Distinguishing features objectId.distinguishingFeatures (new) required
6. Title title required (core)
7. Subject objectId.subject (new) required
8. Date or period creationDate (+ objectYear when it differs from mint year) required
9. Maker authorship.author required (core)
Step 1: Photograph image (+ on-chain imageHash) required for physical/mixed
Step 3: Description description required
Step 4: Secure storage .odpass retention; see Privacy below required practice

New fields (objectId block)

"objectId": {
  "subject": "Winter landscape: frozen canal, windmill at right, two skaters in foreground",
  "distinguishingFeatures": [
    "Repaired 3 cm tear lower right quadrant, visible under raking light",
    "Blue chalk inventory number 47-B on stretcher, upper bar"
  ]
}

Both fields are part of the canonical document and are covered by dataHash: after mint they cannot be edited without the change being detectable (SPEC §10). Machine-readable validation: schema/passport-0.5.schema.json (the objectId block and its conditional requirements are enforced there).

Profile conformance rules

A passport conforms to this profile when:

  1. The objectId block is present with both fields non-empty.
  2. For objectType physical or mixed: image, description, and creationDate are present, and the on-chain imageHash is non-zero (photograph is not optional in Object ID).
  3. All applicable category-mapping rows above are filled.
  4. The issuer retains the canonical .odpass bundle (Object ID step 4).

Privacy: publish-on-incident model (important)

Object ID practice is to keep documentation confidential until an incident, then release it to investigators. ODP supports this natively:

Lost / stolen signaling (roadmap, not in v0.5 bytecode)

The v0.5 reference line has no on-chain lost/stolen flag. Interim practice and planned direction:

Verifier guidance

Verifiers implementing this profile SHOULD: