# Identity verification `kaal:entity:identity-verification` **Status.** derived This node is assembled mechanically from the 8 claims that carry the concept tag `identity-verification`. It is a roster of what the corpus says under this term. It is **not** an adjudicated definition: no single statement here has been ruled canonical, and no first-appearance call has been made. Read the claims and judge for yourself. ## Every claim under this term 8 claims across 5 works, 2018 to 2024. **2018** - [3128900-044](https://wulfkaal.github.io/claims/3128900-044) [failure/evidenced] *(failure mode)* -- Centralized approval processes and identity requirements for worker registration significantly limit the registration of new micro task workers. > According to a study by the World Bank, centralized approval processes and identity requirements for mechanical turk worker registration creates significant limitations for the registration of new workers for micro task platforms. Wulf A. Kaal, Decentralized Mechanical Turk Through Verified Reputation (2018). SSRN: https://ssrn.com/abstract=3128900 - [3128900-045](https://wulfkaal.github.io/claims/3128900-045) [condition/argued] *(failure mode)* -- Centralized platforms cannot simply drop identity verification, because they need it to keep malicious actors from abusing the network and to ensure work quality; this is the tradeoff a staking based design is meant to dissolve. > However, centralized micro task platforms need to verify identity to prevent malicious actors from abusing the network and ensure work quality. Wulf A. Kaal, Decentralized Mechanical Turk Through Verified Reputation (2018). SSRN: https://ssrn.com/abstract=3128900 - [3128900-046](https://wulfkaal.github.io/claims/3128900-046) [mechanism/argued] -- Because the reputation token staking mechanism supplies attack resistance directly, users need not verify their identity to complete micro tasks, which circumvents the costs, delays, and privacy surrender attached to centralized identity verification and thereby enlarges the willing labor pool. > By contrast, on the Semada Platform, users do not need to verify their identity to complete micro tasks. The Semada Protocol architecture, and specifically its reputation token staking mechanism, make the Semada Platform attack resistant. Wulf A. Kaal, Decentralized Mechanical Turk Through Verified Reputation (2018). SSRN: https://ssrn.com/abstract=3128900 - [3266953-029](https://wulfkaal.github.io/claims/3266953-029) [failure/argued] *(failure mode)* -- Identity verification does not fix the sockpuppet problem, because whenever the reputation is genuinely valuable a sockpuppet operator can afford to clear whatever verification hoops are in place, including stealing biometric data, and then inflate reputation as before. > The problem with this is, if the reputation is genuinely valuable, a sockpuppet account can afford to go through whatever hoops you have in place to create false identities (including stealing biometric data if necessary), then increase their reputation arbitrarily, as described above. Craig Calcaterra, Wulf A. Kaal, Gopinath Sivalingam, Reputation Protocol for the Internet of Trust - Conceptual Whitepaper (2018). SSRN: https://ssrn.com/abstract=3266953 - [3266953-030](https://wulfkaal.github.io/claims/3266953-030) [failure/argued] *(failure mode)* -- The other horn of the identity verification dilemma is that when reputation is not valuable, honest users will not bother to go through the hoops required to identify themselves securely. > If the reputation is not valuable, then you won't be able to get honest users to go through the hoops required to identify themselves securely, since it Craig Calcaterra, Wulf A. Kaal, Gopinath Sivalingam, Reputation Protocol for the Internet of Trust - Conceptual Whitepaper (2018). SSRN: https://ssrn.com/abstract=3266953 **2020** - [3709041-028](https://wulfkaal.github.io/claims/3709041-028) [mechanism/argued] -- Blockchain based land title records can serve as collateral for credit or as identity verification, removing a requirement that is often challenging and prohibitive for accessing both financial and non-financial services. > Such blockchain title data can serve as collateral for accessing credit or verifying identities which is often a challenging and prohibitive requirement for accessing both financial and non-financial services. Kaal, Blockchain Technology for Good (2020). SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3709041 **2021** - [3949098-002](https://wulfkaal.github.io/claims/3949098-002) [mechanism/argued] -- Reputation tokens used in decentralized finance are more meaningful and easier to value than traditional identity verification metrics, so decentralized protocols that use reputation metrics will require less collateralization than traditional protocols. > Reputation tokens that are utilized in decentralized finance are more meaningful than traditional identity verification metrics, and much easier to value. Accordingly, decentralized protocols that use reputation metrics will require less collateralization than in traditional protocols. Wulf A. Kaal, Reputation as Capital – How DAOs Upgrade Finance (2021). SSRN: https://ssrn.com/abstract=3949098 **2024** - [4734750-040](https://wulfkaal.github.io/claims/4734750-040) [mechanism/argued] -- Reputation token staking substitutes for identity verification: because staking makes the network attack resistant, workers can complete micro tasks without verifying identity, which removes the cost, delay, and privacy surrender of centralized approval and enlarges the available labor pool. > The CRDAO architecture, and specifically its reputation token staking mechanism, make the CRDAO attack resistant. Wulf A. Kaal, Code Review DAO (2024). SSRN: https://ssrn.com/abstract=4734750 ## Verify Every claim above resolves to a record carrying a verbatim source quote, the sha256 of the source PDF, and a preformatted citation. Nothing here asks to be taken on trust. curl -s https://wulfkaal.github.io/entities/identity-verification.md | sha256sum **Canonical form.** This markdown file is the canonical hashed representation of this entity node. Its sha256 is the content hash.