Notarized-by-Design Documents: How ObjectID Links Machine-Generated Data to a Real Company

In regulated industries, documents are everywhere: batch records, QC reports, calibration certificates, environmental logs, audit trails. The hard part is not generating and storing them. The hard part is proving, years later, exactly which system produced a dataset and which organization controlled that producer at the time.

ObjectID is built to provide that proof as a verifiable chain, not as a single signature.

ObjectID in one sentence

ObjectID assigns cryptographic identities to devices, applications, and industrial objects. One of its key use cases is to use these identities to notarize documents and link them to an organization through a robust ownership chain.

ObjectID objects: creators, owners, and W3C-compliant identities

In ObjectID, industrial assets are modeled as on-chain (IOTA) objects associated with roles such as creator and owner. The key point is that these roles are not just labels. They are identities expressed using the W3C DID standard.

A W3C DID (Decentralized Identifier) is a globally unique identifier designed to be resolvable into a DID Document that contains public keys, verification methods, and service endpoints used for authentication and verification. The DID Core specification defines the DID Document data model, its core properties, and the resolution concept. (W3C)

In ObjectID:

• An object (a device or an application) receives its own DID and becomes a verifiable producer of data.
• An object has a creator and an owner that represent control and governance.
• The owner identity is the trust anchor for organizational accountability.

W3C Verifiable Credentials: how ObjectID notarizes documents

ObjectID uses the W3C Verifiable Credentials (VC) model to express tamper-evident claims, such as “this dataset hash corresponds to this file and was issued by this identity”. The VC Data Model defines the structure and processing rules, including JWT-based encodings used in many systems (VC-JWT). (W3C)

A practical pattern is:

• Compute SHA-256 of the produced file (or a ZIP dataset).
• Issue a VC-JWT that embeds the hash and relevant metadata.
• Sign the VC with the DID of the producing device or application.

At this stage, a verifier can prove integrity and producer authenticity: the file has not changed since issuance, and the producer DID signed it.

The key design choice: Domain Linkage lives on the owner, not on the device

A device DID alone does not prove “this is the company’s machine”. Anyone can generate a DID and sign data.

ObjectID anchors organizational trust at the object's owner identity:

• The Domain Linkage Credential is placed in the owner DID Document, not in the device DID Document.
• Verification proceeds beyond signature validation of the document producer DID.
• The verifier retrieves the ObjectID identifier linked to the producer, fetches the ObjectID object on IOTA, and reads the owner field.
• The verifier resolves the owner DID and validates Domain Linkage, which proves control of a web domain that represents a specific organization.

This produces an end-to-end chain:

1. File hash matches the VC claim.
2. VC signature is valid for the producer DID.
3. Producer DID is associated with an ObjectID object.
4. The ObjectID object points to an owner DID.
5. The owner DID is linked to a domain via Domain Linkage.

If the chain is valid, the document is cryptographically linked to an identity that controls a website domain, making it reliably attributable to a specific company.        

A detail that matters in implementations: when a DID Document includes services, each service map must include id, type, and serviceEndpoint, and the type is how verifiers interpret what that endpoint represents. (W3C GitHub)

Why this chain is hard to fake

To create forged documents that appear to be produced by a real company, an attacker would need to satisfy multiple independent constraints:

• Create a producer DID and sign credentials.
• Associate that producer DID with an ObjectID object that resolves to the real company’s owner DID.
• Present a valid Domain Linkage proof for the owner DID, which requires control of the company’s domain.

Without controlling the linked owner identity and its domain, it is not possible to create a valid ObjectID association chain that passes verification. A fake device identity might still sign documents, but it cannot pass the owner linkage checks, and therefore it cannot credibly impersonate the company.

Example: pharmaceutical manufacturing

In pharma, data integrity is a compliance requirement. A chromatography system or production application produces a dataset that must be attributable to its exact source and its controlling organization.

With ObjectID:

• The producing machine or application signs a VC-JWT that notarizes the dataset hash.
• The verifier resolves the producer DID, then follows ObjectID ownership to the owner DID.
• The owner DID proves control of an organization domain through Domain Linkage.

This creates a defensible provenance chain for audits, partners, and regulators, without relying on a single centralized database as the trust anchor.

Events: maintenance and lifecycle traceability

ObjectID also supports attaching events to the machine identity: maintenance, calibration, component replacement, firmware updates. This adds context to documents: a dataset can be verified together with evidence that the producer was maintained and calibrated at the relevant time.

Why using IOTA for DID Documents makes verification durable

W3C standards define the data model and verification rules, but they do not mandate where DID Documents live. The “verifiable data registry” used for DID resolution can be implemented on a distributed ledger. (W3C)

With IOTA, DID Documents are stored and updated on the network as a tamper-evident source of truth for the data needed to resolve identities and verify credentials. Verification does not depend on a single vendor database and can be repeated by third parties at any time, with long-term persistence guaranteed by the network.

ObjectID and eIDAS 2.0

ObjectID is built on W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs), which makes it technically aligned with the direction of the eIDAS 2.0 ecosystem.

W3C DID is a technical standard for identifiers and DID Documents that publish the cryptographic material and service endpoints needed to prove control of an identity. (W3C) eIDAS 2.0 is a legal framework that defines EU-wide rules for digital identity, wallets, trust services, and cross-border recognition, while remaining technology-neutral on the implementation layer. (Digital Strategy)

Why ObjectID is effectively eIDAS 2.0-ready

The EUDI Wallet architecture and its interoperability work explicitly targets verifiable, cryptographic credentials and standardized verification flows. In practice, W3C VC-based approaches are part of the ecosystem that eIDAS 2.0 is shaping through architecture, profiles, and related standards. (eu-digital-identity-wallet.github.io)

Because ObjectID already uses W3C DID and W3C VC primitives, it starts from a model that is compatible with the core eIDAS 2.0 vision: interoperable digital attestations that can be verified independently and across borders, under a defined governance model. (eu-digital-identity-wallet.github.io)

Advantages

• Interoperability by design: DID Documents and VCs are standardized data structures for verification and portable trust. (W3C)
• Strong evidence for compliance workflows: ObjectID produces verifiable provenance chains that are auditable and difficult to forge, especially when organizational control is anchored via domain linkage on the owner identity.
• Easy integration with regulated trust layers: where higher assurance is required, ObjectID’s technical proofs can be combined with formal trust services rather than replaced.

Legal consequences and how to state them correctly

ObjectID provides strong cryptographic evidence of integrity and attribution, which can materially improve evidentiary strength in audits and disputes. eIDAS also clarifies that a Qualified Electronic Signature (QES) has the legal effect equivalent to a handwritten signature, but that level depends on the eIDAS-qualified trust service stack and conditions, not only on the data model used. (European Commission)

So the accurate legal framing is:

• ObjectID is structurally compatible with eIDAS 2.0 style digital trust because it uses standardized DID and VC building blocks.
• When a use case requires a specific legal effect (for example QES), ObjectID’s provenance chain can be paired with the required eIDAS-qualified components to reach that legal threshold. (European Commission)

Try ObjectID

If your organization generates machine-produced data that must remain attributable, auditable, and tamper-evident over time, ObjectID is worth testing in a real workflow. Start with a single device or application, issue a notarized credential for a dataset, and verify the full chain up to the owner identity and linked domain. It is a practical way to move from “trust the system” to “verify the evidence.”