---
# System prepended metadata

title: GreenCheck Identifier Service Requirements

---

---
title: GreenCheck Identifier Service Requirements
---
### GreenCheck Trust Commons
#### Purpose
GreenCheck's purpose is to enable the formation and use of networks of high trust. Because such networks have many applications and high value, it is intended to be structured legally as a fractal 'network cooperative' governed 'liquid-democratically' at all scales. 

For the purposes of this document, trust is assumed to be founded on relationships between two humans. Thus, proof of personhood is a primary requirement; e.g. as [Vitalik Buterin](https://www.youtube.com/shorts/WH83_Fad7E4) defines it: 
> “I certify that I am a real human and I am registered exactly once in this registry”


GreenCheck's approach is a combination of *intersectional identity* and *three-friend authentication* (aka *web of trust*) as described in the [Who Watches the Watchmen?](https://www.frontiersin.org/articles/10.3389/fbloc.2020.590171/full) link under Links below. GreenCheck is blockchain-independent but Web3-friendly.

#### Core Concepts
Any human can get one and only one GreenCheck ID (GCID). This creates a node in the GreenCheck graph.

Owner of a GCID can prove ownership of other identifying attributes by which others know them. 

Users can verify the claims of others they know. This creates an edge in the graph.


#### Requirements

* Intersectional Identity
	* User can prove sole control of multiple attributes
	* e.g. Two-factor auth of email addresses and phone number
	* OAuth roundtrips with social services that support that
	* Bookmarklet / browser extension that tests login at any application to be claimed.
* Attestation of ownership
	* User can make a cryptographically secure verifiable claim to ownership / control of their attributes 
* Validation
	* Users can validate the ownership attestations of others they know
	* Validations have a cost/value that incentivizes high trust density
* Attestation of uniqueness
	* Upon request, Greencheck attests that said user is a unique human in its registry
	* Such attestations are to a specific degree of confidence, e.g. 98%
	* And include the GCIDs of the validators

* Interoperability
	* GreenCheck IDs allow single sign-on to any applications that support it
	* All nodes and edges directly related to a given user can be encapsulated in a cryptographically secure microledger that can be used by any application to edit/maintain it independent of GC.
	
* Pseudonymity and anonymity
	* User can have multiple DIDs 'owned' by their GC DID
	* Attestations can be zero-knowledge, (e.g. simply returns verification that DIDx corresponds to one and only one human in the GC registry);
	* or include scopes of additional information (particularly what GCIDs have validated the given user)
* Who verifies the verifier? Validators do!
	* Just as with any web of trust, the true test of validity is the validators
* Sybil and collusion resistance
	* Make creation of multiple illegitimate virtual personas too costly / difficult
	* Make detection of such personas easy
* Sufficiently decentralized
	* Users own a direct relationship with their audience and;
	* Developers can always build apps on the network.
	* See [Sufficient Decentralization for Social Networks](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks)
* Blockchain-independence and compatibility
    * Must be useful for normal people
    * Web 2.5 (e.g. [MagicLink](https://magic.link/))
    * Micro-ledgers (e.g. [JLinx](https://whitepaper.jlinx.io/JLINX-WhitePaper.pdf))

#### Comparables
* [Gitcoin Passport](https://passport.gitcoin.co/)
* [Hello](https://www.hello.coop/)
* [BrightId](https://www.brightid.org/)

#### Glossary
* Trust density
* Web of trust
* Verifiable credential
*

#### Use Cases
* Proof of Personhood
* One person / one vote
* Zero knowledge proof of expertise
* 


#### Links
[Who Watches the Watchmen?](https://www.frontiersin.org/articles/10.3389/fbloc.2020.590171/full)

[Verifying Identity as a Social Intersection](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3375436)


#### Microledger details
[Discussion with JLinc about how to use microledgers](https://drive.google.com/file/d/1xE0bEWEUqPJ-IVN7xfiaOKJktfIUoRMt/view?usp=sharing)
##### Video Sections

* Portability / custody / decentralization discussion 0-10:30
* Portability/decentralization distilled starting at 10:30 - 15:00
* Federation of custodians / interoperability 15:00 -  17:00 (punt on this for MVP)
* Single sign-on process discussion 17:00 - 27:22
* Possible use of OAuth mechanism for MVP 27:30 - 31:30
* Scoping of effort 31:30 - 45:45
* Microledgers on IPFS via Ceramic/Hypercore 101 45:50 - 50:25
* Murmurations re: microledgers and portable communities 50:25 
* Essence of microledgers "immutable JSON document where each entry in the ledger is a change. JSON doc with versioned changes over time" 55:00 - 56:40

