How does TNG Identity work?
Solution overview
Last updated
Solution overview
Last updated
In the TNG Identity system, every individual or entity possesses a unique identifier known as a DID (Decentralised Identifier), and their identity-related data, or claim, is encapsulated through Verifiable Credentials (VCs). These VCs serve as representations of various information, ranging from basic details such as age to more complex attributes like academic achievements or memberships.
In the TNG Identity system, every individual or entity possesses a unique identifier known as a DID (Decentralised Identifier), and their identity-related data, or claim, is encapsulated through Verifiable Credentials (VCs). These VCs serve as representations of various information, ranging from basic details such as age to more complex attributes like academic achievements or memberships.
The framework's architecture consists of three key modules: Identity Holder, Issuer, and Verifier. Collectively, these modules form what we refer to as the Trust framework. Below, we describe the role each entity plays in TNG Identity.
Identity Holder: An entity that securely holds claims in its Wallet. As mentioned earlier, VCs are issued by an Issuer to the Holder. The Identity Holder secures all information in their devices and generates a Verifiable presentation (V.P) of the VCs issued. When required, present these V.P. to the Verifier, which rigorously verifies their authenticity against specific criteria.
Issuer: An entity, be it a person, organisation, or entity, is responsible for issuing VCs to the Holders. VCs are cryptographically signed by the Issuer, and every VC originates from an Issuer.
Verifier: A Verifier reviews the proof presented by a Holder. It requests the Holder to provide proof based on the VCs stored in their wallet. During verification, the Verifier conducts checks, such as confirming that the VC was signed by the expected Issuer and that it aligns with the criteria specified by the Verifier. This verification process happens off-chain (for tamper-proofing, data validation and signature check) and on-chain (for issuer/holder authentication).
Think of a Verifier like a university student council that wants to know if you're a university. Normally, you'd need to show your ID or university card with lots of personal information. But with TNG Identity, you prove it, showing a credential that only validates that you are a university student. The university's signature verifies the credential's authenticity, making things faster and safer. A fundamental concept here is the necessity for trust between a Verifier and an Issuer. While the information contained within a VC is cryptographically verifiable, the trustworthiness of the Issuer is paramount. This ensures that Verifiers can confidently utilise the VCs originated by the trusted Issuer.
We take an industry-standard approach defined by W3C specification implemented with data registries built on the BSV Blockchain.
The TNG product design proposes a new DID method – using the BSV blockchain for a publicly verifiable data registry.
Our unique design approach considers unspent transactions (UTXO) to represent the validity of the DID.
Revocation is performed by spending the last transaction in the chain – thus dissolving the DID.
The solution design includes the capability to rotate the cryptographic keys should the need arise.
The UTXO associated with the DID Document presents a snapshot of the current DID Document.
If there is a requirement to change the status of the DID from either the Issuer or Subject – the latest UTXO can be spent.
This will create a new transaction – publishing the latest version of the DID with newly rotated keys.
The TNG design uses the presence of Digital Signatures in blockchain transactions to bind the Subject and Controller keys to the credentials they publish. This ensures that only the holder of the identity can bind these keys to the credentials.
In addition. these keys can be considered legally binding as they fulfil the requirement for the digital signing process.
