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.
What we can see
Section titled “What we can see”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.
What we cannot see
Section titled “What we cannot see”- 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.
What stays on your node
Section titled “What stays on your node”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.
What the node records about resolution
Section titled “What the node records about resolution”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.
The mechanism
Section titled “The mechanism”- Import: product data arrives at your node (CSV, Excel or an ERP export) on infrastructure you control.
- Validate: locally, against the product group’s versioned schema and rules. Validation is a pure function: no network calls.
- Sign: your Ed25519 key, held on your infrastructure, signs the validated passport as a JSON Web Signature bound to your
did:webidentity. - Publish: the signed passport becomes resolvable. Public fields are served to anyone; restricted fields only against a verified credential.
- Verify: anyone verifies against your public DID document. Odal is not involved.
Read next
Section titled “Read next”- Core Concepts: the three ideas the design rests on, including this one.
- Proof files and verification: how anyone checks a passport without trusting us.
Information on this site is not legal advice. Legal noticePrivacy policy