Idea: Verify Airbnb identity for ERC725

[wanderingstan]

Once we roll out fractional usage, it will be useful for people to be able to "import" their reputation from centralized services. If you have a ton of great reviews on Airbnb, it'd be useful to prove this fact and give assurance to people renting from you via an Origin Dapp.

There are many fun ways to do this via steganography, by hiding a challenge-response in one's profile, listing photos, or elsewhere. My current favorite, and I think most simple, would follow this flow :

1. User clicks to verify their Airbnb identity
2. User pastes in URL to their Airbnb listing
3. Bridge server looks up calendar for listing for 2 years in future
4. User is prompted to temporarily change the listing price on a specified day about that time in future to new price. Price is something like 2x normal price, plus normalized salted hash of user's eth address. --Anything that would be uniquely identifiable.
5. After making changes, user clicks "Verify" on Dapp
6. Bridge server confirms that price change has been made, thus proving ownership of Airbnb account
7. Dapp records attestation on ERC725 contract and prompts user that they can undo price change.

This is similar to how website verify bank accounts by making 2 small deposits and asking you the amount.

A similar approach could of course be used for all other centralized sharing economy services--anything with a reputation.

Related: We should totally make a browser extension that scrape data from your Airbnb listsings, or cross-post to both Origin and Airbnb. :)

[joshfraser]

We could also have them add a string to their listing description that says:

Origin verification code: 0x123xyz

This would have the added benefit of providing free marketing for Origin & it wouldn't have to be taken down or changed afterwards. In fact, we could encourage people to keep this code on their accounts to prove ongoing ownership instead of only confirming ownership at a single point in time.

This method is very versatile as we could use the same verification mechanism across all different types of listings.

[matthewliu]

I love these ideas. Although Josh, if we achieve scale there’s a good chance Airbnb would scrub us out of descriptions. Great growth hack idea in the early days though.

On Tue, Jun 5, 2018 at 12:32 PM Josh Fraser ***@***.***> wrote: We could also have them add a string to their listing description that says: Origin verification code: 0x123xyz This would have the added benefit of providing free marketing for Origin & it wouldn't have to be taken down or changed afterwards. In fact, we could encourage people to keep this code on their accounts to prove ongoing ownership instead of only confirming ownership at a single point in time. This method is very versatile as we could use the same verification mechanism across all different types of listings. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#226 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEuxNw6r8yc7IU0eYAootgqt7FeTHeIQks5t5ty0gaJpZM4UbWRh> .

-- Cofounder of Origin <http://www.originprotocol.com> Join our Telegram <http://t.me/originprotocol>

[tyleryasaka]

I wonder if it would be easier from a UI perspective to just ask them to use a specific image with the unique identifier encoded? (Maybe even a QR code?) This was my first thought when you used the word steganography 😄 .

But yeah, I like it!

[wanderingstan]

Yeah, I may have been skipping ahead to the "Airbnb cracks down" phase. :) The Keybase-style explicit version could be a great growth hack.

I might be missing something, how come the verification needs to be on the listing?

When listings and reviews are being imported from another platform, if what's being verified is that the user which requested the import has access to the account on the other platform, then a modification to the profile with an Origin verification code / UUID would allow all of that profile's listings to be linked.

[wanderingstan]

@ambertch The idea was to hide the verification from Airbnb (thus the Steganography), but Josh makes a good point that until they crack down, there's no reason not to put it in the open.

[sparrowDom]

If we are not hiding the confirmation code I really like @ambertch 's proposal. So possible user path would be:

1. User clicks to verify Airbnb identity
2. User pastes link to his Airbnb profile
3. Confirmation code is generated hash(AirBnB user id + eth public key)
4. User edits AirBnb profile description to add confirmation code in (as in @ambertch 's comment)
5. After making changes, user clicks "Verify" on Dapp
6. Bridge server reads confirmation code, proving ownership of Airbnb account
7. Dapp records attestation on ERC725 contract

Does that make sense?

I could have a go at this one. Would be a nice challenge for a first ticket :)

[wanderingstan]

Hi @sparrowDom , that does make sense and I agree that would be a great first ticket. It would mean changes to both the DApp and the bridge server (and probably origin-js too), so don't be afraid to reach out here or on Discord for getting oriented on those codebases.

I won't know the answers but I'll be able to point you to who does.

[sparrowDom]

If one of our motivations is to (at some point) allow users to import their Airbnb information then it would probably make sense to store Airbnb user id on the bridge server?

As far as I can see we do not store emails and phone numbers on the bridge server for the purposes of mapping wallet_address to them. We store them only for the purpose of validation code steps.

Does anybody have any thoughts on how to handle this?

[wanderingstan]

@sparrowDom we quite intentionally don't store user data on the bridge server.

The Airbnb ID should IMO be stored as data associated with an erc725 claim. For the purposes of this issue , the claim in English would essentially be "I, the origin ID bridge server, have confirmed that the owner of eth public key 0x1234...ABCD is also the owner of Airbnb id 12345678."

The data of his claim would be stored in IPFS whose hash is referenced from the ERC 725 smart contract. @nick can you elaborate? I forget how it's actually structured.

[sparrowDom]

Aha ok that makes sense.

So to clarify, when doing email & phone attestation we emphasise that email & phone shall not be stored on the blockchain. And in the case of Airbnb this shall be different since the claim shall contain Airbnb user id data. And that can be later used for importing different data points.