ONT ID Product Suite Upgraded to Improve Ontology’s Decentralized ID Framework

With a goal to build the infrastructure and deliver the tools that will power Web3, Ontology has been “focused on the Decentralized Identity (DID) field since day one. ONT ID is Ontology’s decentralized identity framework, designed to be both trustless and private, empowering users and further facilitating Ontology’s mission.”

Having recently made their Verifiable Credentials Software Development Kits (VC SDKs) open-source for all Go and Java developers, the Ontology team “is pleased to announce a new framework upgrade for ONT ID.”

This framework upgrade will “see additional enhancements to ONT ID’s product suite, as well as some important upgrades, including the upgrade of Mercury, a secure, trustless, DID based peer-to-peer communication protocol.”

There are also additional upgrades “being made to ONT Login, the trustless universal authenticator, and ONT TAG, Ontology’s Trust Anchor Gateway.”

In all, this upgrade makes their decentralized identity solutions more compatible and more easy-to-use, “expanding Ontology’s ecosystem collaboration and accelerating the large-scale adoption of DID solutions.”

Upgrades to Mercury

As a trustless, peer-to-peer decentralized communication protocol that “allows entities to securely transmit messages, verifiable credentials, and verifiable presentations with each other, Mercury will play an important part in Ontology’s ecosystem.”

In short, Mercury makes it easier for both Web3 and Web2 application developers “to complete integrations with decentralized identity solutions.”

Mercury defines several decentralized identifier-based sub-protocols “for building connections and transmitting messages, verifiable credentials, and verifiable presentations between entities.”

The sub-protocol family “defined by Mercury includes a connection protocol, a general (encrypted) message exchange protocol, as well a verifiable credential and presentation transmission protocol.”

In Mercury, entities talk to each other “through agents.”

There are three kinds of agents in this system:

  • User Agent: A user agent is under the control of an end entity, and it can be built as or embedded into mobile apps or other data-rich clients. It is worth noting that user agents’ most important feature is that they cannot be online 24/7. Entities can keep the corresponding secret keys and store their verifiable credentials in their respective local storage, and then use user agents to initiate communication or transmit messages securely.
  • Cloud Agent: In some business cases where user agents cannot be online continuously, messages and credentials need to be relayed, forwarded, and stored temporarily. The cloud agents play important roles in routing these messages. The cloud agent itself has a public decentralized identity and an attribute of service endpoint, so its corresponding secret key needs to be kept secure.
  • Service Agent: The service agent itself is also a cloud agent. In addition, it also allows for the issuance of some verifiable credentials (such as diplomas from third-party institutions). The service agent should also have a public and certified decentralized identity in order to facilitate the secure management of secret keys.

Let’s say two Web3 application users “want to communicate with each other.”

To do so, they must “first establish a communication channel using the connection protocol.”

Following this, they can “transmit messages or verifiable credentials and verifiable presentations using the corresponding sub-protocols.”

  • Connection Protocol: Using Mercury, entities who want to communicate with others outside their own network can establish connections using the connection protocol.
  • General Message Exchange Protocol: Once the connection has been established, they can send messages to each other through the General Message Exchange Protocol. Messages which are sent to communication partners are encrypted and signed using cryptographic schemes ensuring the highest levels of privacy.
  • Verifiable Credential and Presentation Transmission Protocol: The Verifiable Credential and Presentation Transmission Protocol defines the methods of how the three above roles interact with each other. The three actors are the holder, the issuer, and the verifier. The issuer can issue a verifiable credential to the holder at the holder’s request. The holder can then generate verifiable presentations from their credentials for proof purposes. The verifier who obtains the verifiable presentation does so using cryptographic proofs.

Upgrades to ONT Login and ONT TAG

ONT Login is “a decentralized universal authentication login component that helps developers shield the details of authentication implementation. ONT Login brings a quick, seamless, and secure login experience to the developers and users of Web3.”

ONT TAG is “an open and decentralized authentication platform based on ONT ID. It provides KYC services for people, finances, and things, making off-chain data encapsulated within verifiable credentials trustable.”

Through integrations with ONT TAG, entities “can obtain different kinds of verifiable credentials from applications.”

In the future, these SDKs and protocols will “support additional decentralized identifier methods, as well as Ethereum Name Service (ENS) and other decentralized domain naming systems.”

ONT TAG will “allow users to obtain an NFT that can be used as their credentials, while ONT Login will be able to use NFTs to verify the users’ identities.”

Both will form an on-chain and off-chain data collaboration mechanism and “improve the decentralized identity ecosystem as a whole.”

Ontology’s core focus on providing DID tools and solutions is “paving the way towards the creation of a safer Web3 for businesses, entities, and users.”

Mercury, ONT Login, and ONT TAG “are three essential components of the Ontology ecosystem that will make the Web3 space easier to interact with, more compatible, and ultimately, more secure.”



Sponsored Links by DQ Promote