Skip to content
Alpha: Odal Node is in active development. APIs, schemas and docs will change before 1.0.

What Odal can and cannot see

On a proof-bound node, product data is validated, signed and stored on the operator’s infrastructure. The node serves the signed passport, which carries the full product data across its disclosure classes. This page lists what Odal can see, what it cannot see, and what the node records when a passport is resolved.

It describes a self-hosted node, which is the only way Odal Node runs today. A node run for you is an option on the roadmap, not something that exists. If it ever does, this page will describe it separately.

The same as anyone: the public part of the passports you publish, and your DID document, which is public by definition. We see them the way any reader does, by looking them up through your resolver. We do not see who else looks them up; scan counts stay on your node.

  • Your node: its servers, its database and its configuration. We are not part of the deployment and have no access to it.
  • Your signing key: generated and held on your infrastructure, encrypted at rest with an Argon2id-derived AES-256-GCM key, and never transmitted.
  • The restricted parts of your passports: they are released only to readers presenting a credential your node accepts.
  • Your import files, raw production data and supply-chain detail beyond what you publish in a passport.

Everything the node stores stays on your infrastructure, including your passports and drafts, their history, the report of each import, and the scan counts described below. Whoever operates the node holds what it stores; on a self-hosted node, that is you.

When a published passport is resolved, the node can count it.

The count is an aggregate per passport, per day and per surface, and nothing more. Nothing about the person who scanned is recorded: no IP address, device, location, identity or session. The database has no column for any of it, so none of it can be stored. Generating a QR-code image is counted separately and never added to the scan total, because it measures label printing rather than readers.

  1. Import: product data arrives at your node (CSV, Excel or an ERP export) on infrastructure you control.
  2. Validate: locally, against the product group’s versioned schema and rules. Validation is a pure function: no network calls.
  3. Sign: your Ed25519 key, held on your infrastructure, signs the validated passport as a JSON Web Signature bound to your did:web identity.
  4. Publish: the signed passport becomes resolvable. Public fields are served to anyone; restricted fields only against a verified credential.
  5. Verify: anyone verifies against your public DID document. Odal is not involved.