Every ObjectID is generated by a smart contract, not issued by a central authority.
While the user provides certain inputs, the smart contract autonomously derives key elements and enforces strict rules that guarantee the integrity, authenticity, and immutability of each ObjectID.
This ensures that the informational structure of every ObjectID complies with a secure format defined directly in the code.

Identity Derived from a Seed

The process begins with the generation of a cryptographic seed, created and stored securely by the user.
From this seed, the system deterministically derives:

• A blockchain address, used for transaction signing
• A W3C-compliant Decentralized Identifier (DID)

The DID is a URL that points to a DID Document, a dataset containing identity-related information signed by the private key derived from the seed.

This DID Document is generated and stored on the IOTA blockchain through the IOTA Identity smart contract, making it immutable and verifiable.
To establish a verifiable link between the DID and the blockchain address, a special on-chain object called a ControllerCap is issued to the user’s address. This proves that the holder of the address also controls the associated DID.
This step is crucial, as smart contracts cannot natively resolve DIDs but can rely on this on-chain object to verify ownership.

Associating the DID with a Domain

Once the DID is active, the user can add additional metadata to the DID Document.
In the context of ObjectID, a Service Endpoint that links the DID to a specific internet domain (e.g., example.com) is addedd to the DID Document.

The updated DID Document, containing the domain linkage, is then signed and republished. Only the DID controller, who possesses the corresponding private key, can perform this operation.

Creating the Domain-Linked Verifiable Credential

After establishing the connection between the DID and the domain, the ObjectID dApp generates a Verifiable Credential (VC).
This credential is self-signed by the user and declares that the DID is associated with ownership of the specified domain.The resulting file, named did-configuration.json, must be uploaded to the /.well-known/ directory of the domain’s web server.
This placement allows external systems to verify that the domain publicly acknowledges the DID as its controller and vice versa.

Verifying Domain Control

Once the Verifiable Credential is published, the ObjectID dApp contacts the Non-Critical ObjectID Oracle via REST API to initiate a verification process.
The oracle checks the consistency between the DID and the VC available at the domain’s /.well-known/ path.

If successful, the oracle issues a new on-chain object, similar to the ControllerCap, and sends it to the user’s blockchain address. This object confirms that the address owner controls both the DID and the corresponding web domain.

This verified association is what enables the ObjectID smart contract to perform robust security checks at the moment an ObjectID is created. The smart contract ensures that no ObjectID can be generated by a user unless they have provable control over both the identity and the brand domain, preventing impersonation and unauthorized issuance.

Note: we define “npn-critical” the ObjectID Oracle because even in the case a user would objtain a ControlerCap for un uncontrolled internet domain, the validation of the Object that everyone can do autonomously, will fails. In practice, the ObjectID Oracale simply prevent the creation of spam.