Defining On-Chain Identity Token Standard

# Defining On-Chain Identity Token Standard ## Background The Web3 ecosystem needs an identity rail to address the limitations of anonymity and increasing global regulation. The Web3 identity rail will be comprised of on-chain and off-chain components. The on-chain components provide benefits such as discoverability and supporting on-chain tooling such as Smart Contracts. There are however currently regulatory concerns that limit the types data that can be placed on-chain - particularly PII and any data that can be correlated to a natural person. This document works to define an On Chain Token standard for Web3 applications. The motivation for this work is that organizations looking to issue On-chain tokens want a common standard for cross-company issuance and consumption. ## Web3 Use Cases for On-Chain Identity Tokens 1. Evidence that account controller has passed understood KYC process by 3rd party 2. Evidence that account controller is a real person and not a bot 3. Evidence that account controller is over 18 4. Evidence account controller is not on US sanctions list 5. Evidence account controller is not associated with sanctions country 6. On-chain discovery of custodial account controller 7. On-chain discovery of Travel rule protocol associated with account 8. ## Core Questions for Discussion: **1. What are the technical requirements for a On-Chain Identity Token? * Based on "industy" token standard with opportunity for broad tooling support * Support for attribute fields? * Support for Metadata field? * Support for account binding * **2. What token standard should be used for On-Chain Identity Tokens?** * ERC20 * ERC721 * ERC1155 * Other? ### In-meeting notes Which specific methods are MUST / MUST NOT / SHOULD / SHOULD NOT ? * E.g. optional transfer methods/events of ERC721 should NOT be used UNLESS X and Y conditions can be met * If non-transferable, conditions X and Y should be met (e.g. consent, user-burnable, etc.) * Some new ERCs are extensions of 721 anyways - **2. What should be the metadata contents of the On-Chain Identity Token** There is an intrinsic tradeoff in this question. * Option 1: The On-Chain Identity Token contains a lot of metadata (large KB) in a standardized way, whether in human-readable text or against a public mapping * more expensive, least private * variant: SBT "pass-through method" - refers to other onchain cleartext data called by a cross-contract getter * most appropriate for POAPs, openBadges, etc - low-key doxxing * Option 2: The On-Chain Identity Token contains basic info and then a clear-text/self-evident reference to an outside resource with the remaining information or semantics * onchain + known/published mapping (e.g. Verite semantics) * optimized for consortia/shared semantics * Option 3: The On-Chain Identity Token contains basic info and then a clear-text/self-evident reference to an outside resource with the remaining information * onchain + authenticated/secret decoder ring or other offchain/offline ingredient * indistinguishable from option 2 unless outside resource remains secret/permissioned * how many mappings/decoders? 1 per vendor = integration hell * Option 4: The On-Chain Identity Token contains basic info and then a opaque/discrete reference to an outside resource with the remaining information * onchain pointer to live API call, etc. * variant: ZK wallet interaction instead of API call **3. If an On-Chain Identity Token contains a connection to an outside resource - what should that resource be?** * Another Smart Contract or on-chain registry * API Endpoint * DID Document (with Service Endpoints) * IPFS/IPNS CID ### In-meeting notes Each has different MUST / MUST NOT / SHOULD / SHOULD NOT s, non? - E.g. what are the AuthZ assumptions? - Business model/liability assumptions? E.g. freemium model- coarse claims are free and onchain, fine-grain claims are offchain and pay-to-know - Raphael: caveat: pay-$link-to-know, but query results onchained :/ - Quadrata might be doing this (pay to query onchain) - Keith: Vendor lockin versus standard interface/interchangeable vendors - Kim: Consent issues with pay-to-know? Could address with getting holder signature, or blanket consent as part of ToS + Does issuance authZ all future queries at any scale? Raph: More granular or selective? Keith: Sure but that's a product-level decision + Monitoring/burning rights signed away by ToS? **4. What are the standarized contents that an On-Chain Identity Token should reference:** * Issuer Name * KYC Process Followed * Account controller submitted Government issued ID remotely. Goverment ID passed validation as genuine document. * Onfido/Jumio/eKYC-style providers don't make to NIST or any other major * Diff in quality control, AI, liveness... vary greatly * Raphael: Liveness.com - good comparison of liveness quality * Identity binding? * Account Controller passed liveness detection test. Facial match between Account Controller and Government ID photo. * Sanction List Status * Account Controller did not appear on Sanctions list for following countries (ISO3166) - 036, 124, 840) * Account Controller country of residence * Account Controller Proved legal residence within one of the following Countries (ISO3166 x 160) - list of all countries except countries subject to OFAC sanctions - Iran, N. Korea, Russia, Cuba * Granularity determinant: 160 countries? :thumbsup: 2 countries? :thumbsdown: * Account Controller is over 18 years of age **5. What is the lifecycle manaagement model for On-Chain Identity Tokens?** * Revocation * Issuer burns token when they no longer wish to attest to its contents * requires historical query/chainanalytics versus current-state check * vs. Token contains a status (//StatusList2021) * monetization built in :smile: * Issuer manages Smart Contract or off-chain resource regarding revocation status * Expiration / Refresh * Could be employed for "hygiene" purposes but could introduce dependence on issuer. **6. What is the threat model for On-Chain Identity Tokens?** * Wallet/private key loss * Wallet/private key transfer (intentional or unintentional) ## Appendix: Parallel Market PID Token: https://parallelmarkets.com/blog/web3-kyc-aml-via-the-parallel-identity-token The PID Token is supported by a regulatorily compliant KYC/AML process and indicates: whether the owner is a natural person or business entity that the owner has submitted information necessary to complete a KYC/AML review with Parallel that the owner is not currently sanctioned and is being monitored for new sanctions Violet.co https://docs.violet.co/for-developers/core-concepts OnChainID https://www.onchainid.com/