search

OriginProtocol / origin-bridge

We've moved to a monorepo: https://github.com/OriginProtocol/origin/tree/master/infra/bridge
MIT License
15 stars 7 forks source link

storage for Phone and Email verification codes #46

Closed ambertch closed 6 years ago

ambertch commented 6 years ago

Generated phone and email verification codes are currently stored in the database. They could also be stored in the session, which is used when generating the claim for twitter.

ambertch commented 6 years ago

Some thoughts:

Storing email / phone #'s could be good if standards for identity change (or there are multiple identity standards), the protocol ends up operating on multiple blockchains, etc. It would make it easier to port identities around and/or link them across multiple standards.

Not storing this information could be looked at as a privacy protecting feature as well ("link your email and phone # to your blockchain identity, note: we will not store this information")

joshfraser commented 6 years ago

Storing them in the database is okay for now. Long term, we'd rather not have the liability that comes with holding personally identifiable information.

Had a chat with Vitalik about this at Edcon. His advice was for us to store the root of a merkle tree onchain so people can prove their data has been verified by us without their actual data being stored onchain or on our servers.

tomlinton commented 6 years ago

Phone storage was removed in PR #113 so it'd be nice to change the email verification to use a server side session as @ambertch suggested. Then nothing is being stored on the bridge servers and we can do away with this database table.

franckc commented 6 years ago

+1 to using session for email verification so that we can get rid of the "verification_code" DB table in origin-bridge. The less PII we store in the bridge server, the better :)

tomlinton commented 6 years ago

In the engineering call it sounded like we may want to keep around a record of successful attestations (in the short term at least). Just wanted to note that the verification_code table never did that, it's only a record of codes generated for an email or phone number, the success/failure of the attestation was never recorded. We can fire up a record of attestations as a separate issue if it is wanted. :+1:

franckc commented 6 years ago

Yes agreed, we can have a separate table for recording attestations if needed - and we can design it to be flexible enough so that it can record all types of attestations: phone, email, airbnb, fbook, twitter and future ones. I'll chat with folks and we'll file a separate issue if worth implementing.

franckc commented 6 years ago

Closing this issue - implemented in #119