Get Ready for the Token Sale!

Discover Unikname Network: episode 1 – Explicit, canonical or obfuscated, three values for one UninameID

6 August 2021 | Cybersecurity, Digital identity

Juliette Mégret

Unikname Connect successfully audited by Vaadata

To get their UniknameID, users just choose username. But what realy happens ?

UniknameID acquisition is a two step process: availability verification followed by NFT issuance. First the process checks whether the chosen identifier is already in use (by reading the blockchain) and if users are not trying to impersonate an existing one. Second, if the username is free, a UNIKNAME NFT is forged on Unikname Network.

This process requires three different values of the same identifier: the explicit, canonical and obfuscated values. What are they ?

The explicit-value: the user’s choice

The explicit-value is simply the character string chosen by the user. By nature, it should be human-readable. This value is only known by the UniknameID’s owner and, by default, is not written on-chain. The Unikname team does not access the explicit-values as long as the owners keep them private.

Privacy and Control

It will be with the explicit-values that users will import and manage their UniknameID in their SSI Wallet, My Unikname App.  It will also be the value used to consume services from the Unikname SSI platform. For example users will input the explicit-value in the Unikname Connect login window to authenticate themselves. In short, it is a human-friendly value, for human interaction with the Unikname SSI platform.

Explicit-values are not unique: for one UniknameID, users can choose multiple explicit-values. For example, @Bob, @b.o.b and @bob__ are explicit-values of the same UniknameID, and the owner can use the version of his choice indifferently. This is possible thanks to the canonical-value.

Explicit-values are not unique: for one UniknameID, users can choose multiple explicit-values. For example, @Bob, @b.o.b and @bob__ are explicit-values of the same UniknameID, and the owner can use the version of his choice indifferently. This is possible thanks to the canonical-value.

SSI Security

The canonical-value: the anti-phishing protection

Users can use many different explicit-values for the same UniknameID as long as the canonical-value is the same. The canonical-value is computed by the Safe-Typoalgorithm to add anti-spamming protection to Unikname solutions.

Safe-Typo is a multi-language naming algorithm that computes a canonical-value from an explicit-value. The canonical-value is a unique representation of all possible explicit-values of a given UniknameID. As we said, @Bob, @b.o.b and @bob__ will get the same canonical-value. There can only be one UNIKNAME NFT associated to a given canonical-value. This prevents UniknameID that are too close to an already existing canonical-value to be created. By prohibiting two UniknameID with the same canonical-value to co-exist, Safe-Typo prevents malicious users from impersonating existing UniknameID owners. This greatly reduces the risks of phishing attacks.

But this extra layer of security has a cost: there are less possible canonical-values than explicit-values. Thus the space of available names is reduced. The space of free canonical-values is important for 15-character long identifiers, but shrinks notably for shorter length. That is why UniknameID prices are computed from the length of the canonical-value. The shorter the identifiers, the rarer they are… and more expensive they are.

Today, Safe-Typo only supports the latin alphabet, so there are very few UniknameID with four characters or less. But in the future, Safe-Typo will be extended to support many more alphabets such as the arabic, the cyrillic or the pinyin alphabets for example.

The obfuscated-value: identifier stored on blockchain

The canonical-value is slightly different from the explicit-value, but is still human-readable. UniknameID are confidential identifiers, but they address self-sovereign identities (SSI) that are publicly listed on the Unikname Neetwork blockchain. So we need a third value which guarantees UniknameID’s privacy and allows the representation of identifiers and the control of SSI on-chain. We call it the obfuscated-value.

GAFAM Independance

Obfuscated-values are derived from canonical-values with cryptographic hash functions. Thanks to these fonctions, it is not possible, knowing the obfuscated-value, to retrieve or reconstruct neither an explicit nor the canonical value of the UniknameID.

Using the obfuscated-value as its primary key, a NFT is forged into the Unikname Network blockchain: the UNIKNAME NFT. It constitutes an on-chain proof of ownership for UniknameID users, without jeopardizing the privacy of their explicit identifiers.

Interoperability

The disclosed UniknameID

We have seen that the explicit-values of a UniknameID is private by default. But in some cases, disclosing a UniknameID can be useful or even required.

For example, delegates on Unikname Network have a public profile, and must publish their explicit-value. Without that nobody can support them. Another good example are companies using the Unikname Connect solution. By publishing their UniknameID and attaching it to a proof of ownership of their website’s url, they implement anti-phishing protection. Indeed, their users can easily identify the correct website and not be afraid of having their credentials or other personal information stolen.

There is a feature which allows users to disclose the explicit-value of their choice. From this moment, a human-readable string will be written on the blockchain linked to the obfuscated-value. Disclosing a UniknameID is irreversible. Disclosed explicit-values can be changed – when the new explicit-value points to the same canonical-value of course – or stashed. But as all on-chain operations, the history of all disclosing will stay permanently on Unikname Network transaction registry. So users are invited to think before publishing an explicit-value. Unikname applications will always warn users in case of risk of publication of personal information on the blockchain.

Conclusion: One identifier, three values

We have seen how the UniknameID acquisition process requires three values for each UniknameID, with three different purpose: The explicit-value allows a human-readable and human-friendly decentralized identifier ; the canonical-value adds anti-spamming protection ; and the obfuscated-value protect the privacy of the owner.

Need more?

Meet Unikname team to get a demonstration and help integration in your project