Self-sovereign identities, decentralized identities (DIDs) and Bridge Protocol
We have been hearing lots of questions on Reddit, Telegram and other outlets and wanted to take the time to define some key identity phrases to help our community understand a bit better how the Bridge Protocol and digital identities work.
Let’s start with some basics:
Self-Sovereign Identity: This is an identity concept where people and businesses store and control their data on their own devices; providing this data when someone needs to validate them. This is all done without relying on a centralized database. These are concepts and projects like Civic.
Decentralized Identities (DIDs): This is slightly different than the self-sovereign concept. A DID is completely under the authority of the user. There is NO central registry, identity provider or certificate authority that gives the receiving entity a “thumbs up” on the validity of the data.
Cryptography: This is something we are all familiar with it; likely through sending and receiving BTC/ETH. Public key cryptography is a system that uses a pair of keys. The public keys are viewable widely and private keys are only known to the holder of those assets. Authentication and encryption are met between the sender and receiver in this system because only the holder can decrypt the message with the private key.
Zero-Trust Datastores: A zero-trust datastore encompasses the ability to store private information locally, while maintaining trust and authenticity globally.
This premise makes it possible to store encrypted data on a smartphone and pass that information back to servers and applications without losing trust in its authenticity.
The Decentralized Identity Foundation, along with the W3C Credentials Community Group (among other involved and related initiatives) are working on the making of standards and tools for decentralized identity to become a reality.
Bridge Passport
We took an approach to design our ID system with decentralization and the realities of governments in mind. Our goal is to privately secure IDs for the blockchain community and be able to have regulators approve the methodology; accepting them as valid ID.
A Bridge ID owner might want to generate different IDs for their needs. John may want to give his verified, secure ID to an ICO, an exchange or financial institution. Since you do this once with Bridge, the user will be allowed to select the parts of their metadata that is shared.
But, we realized that “traditional” businesses like banks don’t like to take customer “word” for credit worthiness or attestation of our IDs.
If you ever went through getting a mortgage in the USA you know exactly how a portable ID can help!
Our system removes private data storage and utilizes a blockchain backbone; allowing the business or entity to “check” with Bridge regarding an ID validity.
We know many of you will read this and yell, “This is centralized!”
…But wait, although the Bridge chain will hold vague metadata, it is nothing personally identifiable. A user only needs to trust Bridge with vague information like country of citizenship, age. Also recorded is the users pass/fail results from terrorism and money laundering checks.
When the exchange or ICO requests to verify that Bridge ID, we have a simply designed logic function that attests to the validity of the metadata. Following that automated process, our system returns a YES or NO; based off the businesses compliance standard.
This is truly unique and no another system on the market is designed like this.
There are many use-cases where this kind of stored metadata can be verified:
1) A financial institution must verify a user has gone through a Know-Your-Customer (KYC) process
2) A notary wants to assure a document is valid and certified
3) A business or university wants to assure that a record or transcript is authentic
4) A business wants to ensure the contractual party is certified and valid, this is especially important for internet and online transactions where trust is defined on digital channels and emails
Token Useages
The economics of the TOLL utility token are quite evident. Users will need TOLL to pay for verifying attestations. Institutions will need TOLL to verify its users on the Bridge system.
As our system evolves to meet customers’ needs, we will tailor our solution to be the lowest cost and most private identity platform on the market. There is simply no need for transactions to risk storing sensitive user information; just for compliance.
Conclusion
Bridge is a hybrid between self-sovereign identities and decentralized identity standards; we have created our own standard that will be known as the Bridge Passport.
