CIP 2: Professional Verifier Pool #2
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@nambrot can we close? |
|
I'd say this CIP is still open so I'd actually argue we should merge it as a draft? |
nambrot
added a commit
that referenced
this pull request
Oct 16, 2020
YazzyYaz
suggested changes
Nov 10, 2020
| @@ -0,0 +1,93 @@ | |||
| # CIP 2: Professional Verifier Pool | |||
There was a problem hiding this comment.
Please ensure your title follows the new cip-template.md file.
Also ensure status is Draft.
https://github.com/celo-org/celo-proposals/blob/master/CIPs/cip-template.md
Also please ensure the rest of the document headings are following the new CIP template document. Abstract, Simple Summary, Motivation, Rationale, Specification, CopyRight, Implementation, etc.
| We should effectively revive the pool part of the old verification pool and the verifier app, and adjust it to the new interface to work as a module to the attestation service. Since this service is not expected to run by validators, but by specific entities, building this on top of proprietary tooling is likely ok. We could provide sybil resistance through dedicated APIs such as [https://developer.android.com/training/safetynet/attestation](https://developer.android.com/training/safetynet/attestation) or [https://developer.android.com/training/articles/security-key-attestation](https://developer.android.com/training/articles/security-key-attestation). If we deem these APIs to not be broadly available in our target markets, we could fallback to classic sybil mechnisms like Social Networks, although they are 1. not as sybil resistent and 2. not as permissionless/inclusive. | ||
|
|
||
|
|
||
| ### Alternative Solution |
There was a problem hiding this comment.
I'd like to see this whole document following the new template so we can have consistency.
prestwich
suggested changes
Dec 1, 2020
|
I'll close as not relevant |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the early prototypes of the lightweight identity protocol, Celo had a concept of a verifier app. It would send text messages on behalf of the protocol and would receive a share of the attestation fee revenue. It was a truly permissionless on-ramp. However, over discussions, we had sybil and game-theoretic concerns over the viability of that scheme. This CIP proposes a return of the verifier app in the context of a professionally run text message provider that uses verifier apps to send the message. In this scheme, the provider has a reputation to uphold and acts as a possible alternative to providers like Twilio.