## 3 The Digital Identity Model
### Linking Tokenized Objects  
Linking physical things (e.g., cars, jewelry, and goods) to a person is part of the eagerness required to build an ecosystem of digital identities. With this, we could provide a model where all identities are connected. However, some physical things could change ownership, whereas others do not. For example, a birth certificate is linked to a user and is not transferable; the same applies to a diploma awarded to one user and generated by a university. There exist standards for creating NFTs to be unique and indivisible, e.g., ERC-721 [33] and ERC-1155 [34]. The reason we do not adopt the ERC-721 standard is that  
Figure 1: The digital identity ecosystem modeled in Business Process Model and Notation (BPMN).  
it inherently supports token transferability between users or contracts. However, in our identity model, certain digital assets (such as birth certificates or university diplomas) are strictly bound to the original user and are, by design, non-transferable. Assigning these assets as transferable would contradict their inherent immutability and ownership constraints in the real world. On the other hand, although ERC-1155 offers a flexible framework for handling both fungible and non-fungible tokens, it still assumes that tokens are transferable by default. In our identity model, certain tokens (such as birth certificates or academic diplomas) must remain permanently associated with a single user and cannot be transferred. Therefore, adopting ERC-1155 without modification would contradict the immutability and ownership restrictions required for these identity-bound assets.  
We propose creating a system to link tokenized objects into a tokenized digital identity, certified or uncertified by a government. When receiving the _linkToken_ instruction--within the blockchain role in Figure 1--it is verified whether a token can be added or not and if it is certified or uncertified.  
Figure 3, in general, illustrates the process of tokenizing objects. The figure consists of two parts: the real world and the digital world. You can think of it as entities of the real world executing remote functions in the cloud.  
The figure shows, in general, various abstract mechanisms. For example, for the arrow with a circled 1, the government has tokenized three entities: an end-user, a car agency, and a university. Tokens in the figure are illustrated with an abbreviation address within a rectangle. The government could also create other types of tokens, such as birth certificates (circled 2). Other types of entities (after having been created by the government) could make their own tokenized assets (circled 3), for example, tokenizing physical cars by a car agency or tokenizing diplomas by universities. Note that, in the figure, we distinguish some tokens with an insignia, meaning that such tokens were certified by the government.  
A token must hold an owner attribute to know who it belongs to. However, when an entity creates tokens, they are scattered on the blockchain, and a special kind of wallet is required to link them. Therefore, in our model, there exists a step where each entity links one or more of their external tokens into their digital identity token through an established protocol. The protocol validates whether the owner of the external token corresponds to the same owner of the digital identity token. The circled 4 in the figure illustrates the digital identity token of the entity (\(0x1 AF...101\)) already linked with the other tokens.  
Figure 2: Sequence diagram showing government creation and identity issuance process.  
More technical details will be tackled in the following sections.