We refreshed our doc site!
Bookmarked links may have changed
Read release notesToday's identity providers, identity verification services, banks, and other core services that perform some degree of Know-Your-Customer (KYC) and/or Know-Your-Business-Partner (KYBP) services on their customers operate in a predomintrustantly issuer-centric, phone-home world: today's web [2.0] and mobile-app ecosystems are almost 100% powered by API phone-homes and delegation tokens. This is gradually changing, though: third party cookies are being replaced by more nebulous (and platform-centric) tracking models, reducing the centrality of identity providers in the web advertising ecosystem. In parallel, user-centric approaches are increasingly putting cryptocurrency private keys and sensitive identity data directly in user-controlled wallets. The role of an identity provider is shifting, along with their phone-home mechanisms, user experience expectations, and business models. The next big thing is portable identity, user-controlled sharing, and trustless, universally-verifiable tokens. Verite provides a standards-driven approach for empowering your end-users without assuming new risks and liabilities.
If you want your end-users to be able to present a [revocable, tightly-controlled] "badge" that proves them to be your customers anywhere such a badge grants them access to better products and validated-customer prices, you want to be issuing them Verite credentials. Which exact form that takes depends on the answers to a few key questions:
In the short-term, the following use-cases are going live in at least one product offering in 2022:
The following are in research and design phase, being co-developed by participants and adopters:
Each Verite credential type represents a different liability surface and lifecycle. When designing your Verite engagement, consider the following variables:
A note on "Uptime": particularly if you are issuing credentials that may need to be revoked quickly, you should consider whether you are operationally equipped to maintain (24/7, 365) monitoring of real-world data sources like OFAC and PEP lists. Most IDV companies have some kind of realtime monitoring that triggers "push" notifications to clients when statuses change, but with portable, self-certifying credentials like Verite, you don't know whom to push that notification to-- instead, you have to comply with the low latency-tolerance of publishing credential status updates to "revocation lists".
Take a minute to ask yourself some difficult strategic questions:
At present, the two main options to consider are whether you want to attest to the controller of an blockchain address or to the controller of a specific wallet, which may control multiple addresses in addition to a DID (wallet identifier). For more information, read the identifier scheme considerations and compare the address-bound credential exchange flow and the wallet-bound credential exchange flow.
For address-bound flows, please see Wallet Connect issuancefor implementation guidance and code examples, and Wallet Connect request presentation for reference.
For wallet-bound flows, please see the pages on wallet-bound issuance mechanics and wallet-bound issuance service setup for implementation guidance and code examples, and wallet-bound credential exchange flow for reference.
Once you have clear your use-cases and your high-level architecture, you arrive at the build-or-buy decision. If you want to issue the credentials you will be responsible for yourself, there are tutorials and documents to guide you through the process in the "For Developers" section of thissite.