We refreshed our doc site!
Bookmarked links may have changed
Read release notes"Knowing your customers" in the traditional banking sense is a tall order, and a one-size-fits-all regulatory approach that can be a huge burden on crypto businesses, that often need 1/10 of the certainty afforded by KYC'ing all their customers or counterparties and are loathe to assume huge costs and liabilities just to do it. Add to that rising regulatory risks and liabilities... and you've got every reason to let a trusted intermediary KYC your customers for you. Verite lets you get just the bare minimum you need from a more dedicated identity verifier, with a verifiable, trustless passing of basic facts. If you ever need to prove exactly when and how you approved a blockchain address or a wallet to interact with you... you've got timestamped, tamperproof, receipts. As ironclad as on-chain data!
Some key questions to ask yourself:
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:
In many use-cases, the least you can get away with knowing about an address is its:
None of these are PII, and if sufficiently coarse-grained, none of these compromise on the anonymity central to the ethos of cryptocurrency and web3. Verite exists to make these kinds of facts verifiable, yet still under direct user control with a minimum of issuer involvement or surveillance risk.
If you need anything finer-grained than the above, you inch towards the risk of deanonymizing the wallet/user, leaking personal information to be snatched up by prying scammers or spammers, etc. To get into that more dangerous territory, you will have to proceed to request further information from the wallet and/or issuer; this can entail a more niche zero-knowledge protocol or circuit/setup, or a direct channel to the issuer and authorization from the user to inquire about sensitive data they retain.
The best way to think through reliance from a legal and compliance point of view is this: what are you inferring or taken as evidenced, once you've verified a valid (non-revoked, non-suspended) Verite VC from a trusted issuer? You are responsible for all that you inferred or assumed, and the issuer is responsible for only what is in the credential. For this reason, it is highly recommended that you log the verification interactions carefully, retaining at least the issuer's identifier and whatever the issuer might need to produce the VC itself, for forensic purposes.
A note on "Uptime": if you are consuming credentials that may need to be revoked quickly, such as credentials reflecting the current status of real-time monitoring of data sources like OFAC and PEP lists, you may need to check the "status" of a credential far more frequently than you verify the credential itself. Luckily, this status can be expressed as a web URL, an on-chain registry, and/or as a value queried via on-chain oracle; unlike the credential itself, no fancy cryptography is needed for these more frequent checks.
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 request presentation for implementation guidance and code examples, and Wallet Connect issuance for reference.
For wallet-bound flows, please see the pages on wallet-bound credential exchange flow for implementation guidance and code examples, and wallet-bound issuance mechanics and wallet-bound issuance service setup for reference.
Once you have clear your use-cases and your high-level architecture, you arrive at the build-or-buy decision. Verifying Verite credentials at scale and in production can be a massive undertaking if you're not familiar with OIDC token, authorization issues, applied cryptography, or other related problems in web engineering. That said, they are just signed JSON! If you're considering building a verifier for your environment, start with the tutorials and documents that guide you through the process in the "For Developers" section of this site.
If outsourcing this layer is more appealing, there are already a number of verifiers that offer the verification and validation/initial-processing of Verite credentials as a service, which can deliver definitive answers about which wallets/address to sort into which buckets or trust-levels over APIs, oracles, and/or on-chain registries. Some of these are even free to use in production, at scale!