Considering that Stripe was originally known for letting websites accept credit card payments without seeing your credit card number, one might assume that Stripe Identity only allows websites to see the verification result, and not your selfies and scans of your identity documents.
That would be an incorrect assumption. Per https://support.stripe.com/questions/managing-your-id-verifi... customers of Stripe Identity have API access to "captured images of the ID document, selfies, extracted data from the ID document, keyed-in information, and the verification result".
Thus, when you use Stripe Identity to verify your identity, you have to trust that:
1. The website doesn't download, retain, and later leak your selfie and identity information.
2. The website's Stripe API token isn't compromised and exploited by identity thieves to access your selfie and identity information.
Stripe appears to be leaning heavily on their claim that they don't disclose "biometric identifiers" to websites and that these "biometric identifiers" are deleted from their systems within 48 hours. This is extremely deceptive considering that biometric identifiers can be reconstructed from the selfie.
> Considering that Stripe was originally known for letting websites accept credit card payments without seeing your credit card number, one might assume that Stripe Identity only allows websites to see the verification result, and not your selfies and scans of your identity documents.
A few points:
- Fundamentally, Identity makes it possible to choose how much of this data traverses / is stored on your servers, just as Stripe did with card numbers.
- There's a basic difference between card numbers and identity verification. With card numbers, you (generally) don't really care about the number -- you just want the payment. With ID verification, however, many businesses have good reason to want more than just the verification result. For example, they are often subject to compliance requirements that mandate that they themselves possess or have access to the raw information. They may need or wish to perform additional checks on their side. Etc.
- The relevant UI in Identity is deliberately very clear on this points in order to avoid the assumption you're stating. The flow explicitly says "Stripe and [Business] may each use your data." Even though an end user might consider it suboptimal for the business to have their data, we still view it as an improvement to the usual status quo, where this data is frequently stored in very ad hoc fashion and without rigorous security protections.
- While many of the businesses initially building on Identity wanted access to the raw information, it may well make sense for us to enable them to restrict themselves in the future. In this world, Stripe could tell their customers that the business doesn't have access to the raw details. (This might even make sense for Stripe payments in the future.) As a philosophical matter, we consider ourselves to serve the business, which means that limiting access to what we consider to be the business's own information feels a bit strange. That said, it might sometimes be in the interests of the business to allow them to limit themselves in this fashion (especially as Stripe's brand recognition among consumers grows).
- There's a separate concern about compromise of the business's credentials leading to inadvertent disclosure of this information (a situation analogous to an S3 bucket key getting leaked). This is of general concern to us in lots of situations, not just with Identity. We have some new functionality on the way here.
> Fundamentally, Identity makes it possible to choose how much of this data traverses / is stored on your servers, just as Stripe did with card numbers.
There's a stark difference in how Stripe treats exports of card numbers versus exports of raw identity verification data. This makes it way easier, and more likely, for Stripe customers to choose to store raw identity verification information.
> With ID verification, however, many businesses have good reason to want more than just the verification result. For example, they may be subject to compliance requirements that mandate that they themselves possess or have access to the raw information. They may need or wish to perform additional checks on their side. Etc.
I acknowledge that some businesses have a need for this. But I see Discord and Clubhouse among your customer logos, and your product page talks about non-KYC use cases. Many of your customers will have access to identity documents without really needing it. That sucks for the end users of Stripe Identity, because it makes it more likely their data will be misused.
A concrete suggestion: make it possible for businesses to choose whether they have access the raw data, and expose the choice to the end user in the Stripe Identity flow. Ideally, businesses that want the raw data would be subject to security compliance requirements. This is an opportunity for Stripe to be a leader in setting high standards on how this type of data should be handled.
> As a philosophical matter, we consider ourselves to serve the business, which means that limiting access to what we consider to be the business's own information feels a bit strange.
Maybe I'm wrong , but once a customer upload the document on Stripe Identity they are supposed to be YOUR documents.
I worked in Bank as a Service , fundamentally when a customer goes through a verification process , the documents uploaded are not the owned by the partner using our APIs. They are owned by us , the Bank.
For Stripe Identity the same should have apply. Here the goal is not "Lock the Partner" but rather to protect them.
Now that discord has access to my Passport , in case of an identity theft could you tell me EXACTLY whose liable for the leak in regards to the law ?
With BaaS it's pretty clear , the Bank carry the responsibility to keep those documents safe , thus it's safer to not give access to a basic business to the raw details.
With the current API design you are offering, it's more ambigous and more prone very large leak within a business information system like Discord or Uber etc..
Do you verify when a business downloads our identity documents from your servers that they're only doing so to meet regulatory requirements? What promise do we have you're not just making it as easy as possible to obtain drivers licenses, passports, birth certificates, etc. so that every little monster who has something we want will start making it a requirement? Have you considered how your service might impact trans people or undocumented citizens?
There are many use cases where it's enough to verify that the user is an actual person, and also to prevent the same person to have multiple accounts. So, it would make sense that Stripe verifies the person, but keeps the details from the business itself.
I trust Stripe more than a random online forum, a dating app, or a social network, which might offer a higher quality service when people are verified. There's a high risk that the ID documents will leak from these services at some point if they get access to them. I don't want them to know who I am at all, if they don't need to know.
It would also offer a way for preventing sybil attacks on P2P networks, or help connecting to non-evil nodes on a P2P network (such as Bitcoin Lightning Network) without knowing the other person. In these cases there could be a some kind of signature generated by Stripe that could be used as an additional trust factor without centralizing the system.
One of the points brought up by privacy folks in review of Apple’s plan to have your ID in your digital wallet is that the mere convenience of allowing access to ID may create ID requirements for users where none existed before, which is a loss for privacy. Do you think that Identity is going to create such new requirements?
> it may well make sense for us to enable them to restrict themselves in the future. In this world, Stripe could tell their customers that the business doesn't have access to the raw details
This sounds great -- I don't want to be handling sensitive data of users, and I don't want to give sensitive data to businesses. But I'd rather this be a separate Verification product, with different branding, docs, and UI, so users and businesses are all clear on what's happening to user data.
Very glad to see that 4th bullet point there. I really like the option of, as a business, being able to say "No, I want to know whether the ID matches their Name/Address, but I don't want to be able to access the image data".
How are you going to handle E.E.U. citizens? It seems that the GDPR applies here. The only real solution I see is to have a separate E.E.U.-based company.
Do you feel in doing this that you're making the web worse? As a business, you certainly have no obligation to be ethical, but doesn't it feel a bit strange as a person who presumably grew up with the web to be playing such a big role in harming the people who use it?
> They may need or wish to perform additional checks on their side. Etc.
So they get all the data in the off chance that a Stripe customer might want to do something with the data aside from the basic “yeah our large global identity verification service says this person is legit.”
I’m not super clear what a company might ”wish to” do with that data that isn’t served by the basic “this person is who they say they are” function (Does Stripe need their clients to act as guinea pigs to see if the service actually works as intended? If their mysterious black box “wishes” turn up a case where this isn’t working as intended, are your customers required to share that data with you to ensure the overall reliability of the Stripe Identity service? Or do they just get to build a database of info they get from Stripe Identity?)
> While many of the businesses initially building on Identity wanted access to the raw information, it may well make sense for us to enable them to restrict themselves in the future.
Oh nevermind, asked and answered! Just turn on the data hose to whoever has a website and will pay Stripe for identity data and maybe adjust it later if you catch some flack for this practice?
It’s kinda hilarious that the whole “people trust Stripe with their data” as part of the sales pitch as if this didn’t come across to me (a layperson) as a direct violation of that particular trust.
It's unfortunate , I'm an Enterprise Architect in Banking and honestly I wouldn't have let that feature go in production.
Businesses that do not have a legitimate reason to view my sensitive document like Passport , should not be allowed to do so.
Only authorized institutions like Licensed Payment Institution / Banks / Insurances etc... should be allowed to do so and AFTER they've been approved.
It's sad because you can tell right away that this will we be abused by Stripe's customers inadvertently. Just like Uber "God View" thats you view any customer ride...
Pretty sure the amount of "Identity Theft" or "Privacy" Scandal is going to explode with such technology available for everyone.
I don't know how a product manager at stripe could tell himself that "Yes , it make sense to give access to sensitive documents" in an age where people are seeking more privacy.
> Businesses that do not have a legitimate reason to view my sensitive document like Passport , should not be allowed to do so.
I get parent comment's totally legitimate security concerns. And businesses that have no business having my identity should surely not be asking for it. But I don't honestly understand how this has anything to do with Stripe. These businesses (which for whatever reason are asking for ID verification before doing business with you) are just using Stripes API to verify identity instead of just taking your info themselves.
Any customer giving their information presumably knows they are giving said business their identity documents, the customers might not even know that the business is using Stripe's API.
Furthermore, Stripe is ostensibly coming in here to streamline the process for business taking identity info from customers. Why - in your opinion - is it worse for consumers when these-type businesses (which ask for identity), use their own-rolled id verification than using Stripe's?
As a person that still is trying to recover from identity fraud that happened many years ago. I am always very weary of companies that demand ID papers. Most of the time I will avoid them.
Most companies aren't even supposed to ask for identity papers is Stripe verifying with the passport issuer whether the country allows given their passport to some identity?
I think there should be some sort of consent system built in were when the API consumer wants to download a passport the customer gets an email with the question if they consent in them fetching a copy.
But, also as an Enterprise Architect in Banking, if you were considering Stripe Identity wouldn't you rely on it for KYC compliance? You can't just say Oh we outsource that to a third-party called Stripe, can you?
> Considering that Stripe's original selling point was that it let websites accept credit card payments without seeing your credit card number
This is true, but it's also kind of a misleading statement; the original selling point was that you could accept credit cards without having to deal with the requirements of PCI compliance and merchant accounts, which is done (partially) by you not ever seeing the card data.
If there was similar compliance regulation around document storage, I would assume that Stripe would use "Identity-Document-Standards" compliancy as a selling point. As far as I know, there are no such requirements.
I do think your #2 point though is exceptionally valid, and would hope that the majority of Stripe keys are scoped to not even provide access to this data/endpoints.
Edwin from Stripe here. The two cases are actually very similar. If you want to avoid ID documents ever being stored on your servers, Identity makes it easy to do that. (Just as Elements/Stripe.js makes that easy for card numbers.) On the other hand, if you want to score card numbers or ID documents (and there are sometimes good reasons for doing this!), Stripe makes that straightforward.
I do agree the cases are very similar, which makes it all the more jarring how differently Stripe treats the data.
If you want to export credit card numbers from Stripe, you can only have it transferred directly to another PCI DSS Level 1-compliant payment processor, and Stripe imposes rather strict requirements on the transfer: https://stripe.com/docs/security/data-migrations/exports#whe...
If you want to export ID documents or selfies, you can just make an API call or use the web interface. This can and will be abused.
Conflating credit card #'s and personal biometrics/SSNs is your first mistake. You think they are the same, they feel the same, but the risk to the customer is so much bigger.
When a hotel copies my passport, they get a jpg. If they use Stripe, now I know they have my biometrics serialized to JSON. That feels way riskier and scarier to me, especially now that it's all centralized by Stripe.
We hear about our personal data getting leaked and hacked every day, and here is Stripe making themselves an enormous target and serializing all the data for malicious actors.
This feels like a really tone deaf misstep by the company.
I suspect most (if not all) KYC regulations require you to keep the evidence you used to verify the identity - even landlords in the UK are required to keep the evidence they saw of your right to live in the UK, let alone any institution that actually needs to prevent fraud etc. I suspect it's just a basic requirement of selling such a service to most medium-large businesses.
You're probably right about KYC, but KYC is just one of the four use cases presented by Stripe, and their customer logos include Clubhouse and Discord, which I highly doubt have KYC requirements or any need to access the underlying evidence.
Stripe could do this differently:
1. Allow the customer to choose whether or not they need access to the evidence.
2. If customer has chosen to receive access to the evidence, the Stripe Identity UI should clearly disclose this. (And they shouldn't try to deceive users by talking about deleting biometric identifiers.)
Stripe could have been a leader in setting high standards on how this type of information is handled. Instead they've opted to go the easy route and maximize profits while the rest of us pay the negative externalities from identity theft.
>Considering that Stripe's original selling point was that it let websites accept credit card payments without seeing your credit card number
I thought that Stripe's original selling point was that you could easily accept payments online without having to integrate with complicated bank and payment processor tech.
As I understood it at the time, alternatives required PCI compliance, which Stripe allowed you to sidestep thanks to tokenization, so I do believe that was a selling point. But this is besides the point I'm making, so I've edited my comment.
I wonder if instead Stripe could have routed calls through itself, filling in the secret info. Perhaps it was discussed?
For example, imagine Joe Biden buys a widget from WidgetsR.us and wants it shipped to his home address of 1600 Penn Ave in DC.
WidgetsR.us -> Fedex.com/order_XYZ/ship-to/Joe Biden at 1600 Penn Ave in DC
WidgetsR.us <- Fedex.com "201 CREATED"
Instead they could route through Stripe (where 123_joe corresponds to Joe Biden's identity docs in Stripe), which fills in the missing info.
WidgetsR.us -> Stripe.com/identity/123_joe?redirect=Fedex.com/order_XYZ/ship-to/$NAME at $ADDRESS
Stripe.com -> Fedex.com/order_XYZ/ship-to/Joe Biden at 1600 Penn Ave in DC
Stripe.com <- Fedex.com "201 CREATED"
WidgetsR.us <- Stripe.com '"201 CREATED"'
That way WidgetsR.us never knew the $NAME or $ADDRESS of user 123_joe, but was still able to use them. (Yes, they could send that info to themselves, but then they're on the hook for protecting it.) The huge downside here is putting Stripe in your business's critical path. But if it's already there for payments, then why not for identity?
Just an update on this—we've some changes in flight. Accessing sensitive verification results like date of birth, extracted document numbers, or collected images will soon require the use of restricted API keys. (More at https://stripe.com/docs/identity/verification-sessions#resul....) Thanks again for your feedback. I'll shoot you an email to chat more too.
The landing page contains logos for clubhouse, discord, and shippo, which are presumably companies use the service. Does anyone find those usages to be unnecessarily intrusive? Maybe it's just me, but a chat app or shipping site asking me for a drivers license scan + selfie would make me never want to use the service again. It's appalling how this sort of stuff is getting normalized, eg. google asking for id scans for age verification.
I honestly find it weird having all of these things suddenly want a copy of my passport in the cloud just sitting there waiting to be hacked in years to come when the security measures drop.
At this point there is giant databases containing everything people need to take complete control of your identity sitting there just waiting to be hacked.
I have no idea how to change it/fix it. But it seems weird to me.
The fix is for the government to make it a service. Right now, the government is punting responsibility to private actors who do not have the legal tools to operate an identity service.
The government already operates an identity service via passports. The only reason they do not have an electronic identity service yet is because it is beneficial for them to be able to blame private actors when things go wrong.
You've nailed the complexity of this. On privacy, people are rightfully spooked about this for all the reasons you've mentioned. On safety, people are really happy about these initiatives as accounts backed by user identity are less likely to be used for harm. On security, leaks of these databases create issues to other sites and companies (eg: if Company X is compromised, then identity documents could be used to disable/bypass 2FA for Bank Y).
To make it even more complicated, regulators often hold contradictory views. They want to see increased safety, but in the same breath will announce actions against companies for violating privacy. This is a super-difficult balance to strike.
Specifically for Stripe, I trust them. So if I see that a new start-up is using them rather than rolling their own solution, that increases my trust. But it means there is now a big giant server in the cloud with millions (billions?) of identity documents that is worth a lot of money for hackers.
Regular Discord users don't need to send in anything. It's used to verify your bot (only applicable for bots that are in more than 75 servers), which seems like a reasonable use case.
Does Discord only allow bot developers from Stripe Identity's supported countries to verify? Stripe is only supported in 44 countries[1], and Stripe Identity seems to support 56 (by counting options in the select dropdown in [2]), so that leaves out a lot of countries.
More a requirement at this point. Discord had to crack down on malicious bot developers after some decided to log essentially every bit of information ever sent to them to be put on the internet, including information from private channels. Some scopes require this verification outright now.
Discord uses it to verify the identity of bot makers - my understanding is that bots have been abused for a long time for data collection (think logging when users come online, go offline, change status, etc).
I don't get it. They're concerned about people abusing the system, and their solution is... requiring KYC? How does that solve the issue? It sounds like bot makes can still passively collect the info, it's just that when it gets discovered they can point to a real person to blame. Moreover, why do bots even need to know the online/offline status of users? Why not add a permission system so users can opt in/out of providing this sort of information to bots? I'm not a discord bot maker, but there's plenty of hobby/side projects I'm willing to provide to users for free, but not willing to attach my real life identity to.
Clubhouse lets you collect payments to join some channels. Isn’t KYC reasonable in that case?
Re: Age Verifications on Google & YouTube: this has been covered well elsewhere. Google is required to do so by EU law. Blame regulators not the companies.
> Clubhouse lets you collect payments to join some channels. Isn’t KYC reasonable in that case?
If it's limited to only people receiving payments, then it's far more reasonable than what I thought was happening (eg. people getting randomly asked for ID scans to use their service).
They’re required to verify that users are above a certain age. There are no requirements to solicit and keep information or documents beyond that. Just because the easiest shortcut to age verification is requiring a copy of a government ID, this doesn’t mean that that’s a good idea.
Chat apps use Identity to verify bots and prevent bad bots from spamming real users. And shipping services use Identity when a user is suspected as a fraudster—to double check before creating fraudulent shipping labels.
> Chat apps use Identity to verify bots and prevent bad bots from spamming real users.
Is bot spam rampant on discord or something? Are less invasive forms of verification (eg. SMS, credit card, or requiring a deposit) not enough? Can it not be solved via technical means? eg. requiring users to opt-in before receiving messages from a bot?
> And shipping services use Identity when a user is suspected as a fraudster—to double check before creating fraudulent shipping labels.
Yet I can buy hundreds of dollars of goods off amazon (or any other e-commerce site) without uploading my ID and giving them a live video feed of my face.
For both of these use cases, I don't doubt that ID verification provides benefit, I just find the privacy tradeoff to be unacceptable. As an analogy, a store can probably cut down on shoplifting if they performed ID checks at the entrance and kept a visitors log, but I think most people would find that unnecessarily intrusive and would refuse to patronize that store.
Discord only uses identity verification for a small subset of developer accounts—when your bot application fetches the full member list or timestamped "online/away" data, AND is in more than 100 servers. Normal Discord users (and most bot developers!) don't interact with the identity verification process.
What's the difference between filling out your address in text versus scanning? Is your face not on the internet yet? Just curious what specifically would make you never want to use it?
Scanning lets you audit for photoshopping and sets a vastly higher bar for counterfeiting. (For example, Blizzard’s name change process requires you to cover irrelevant areas of your ID with actual paper, because no digital editing permitted.)
If you enter an address in as text you're in control of the data you're supplying. If you have to upload/scan a document then there might be other information they extract/store. I'm not someone concerned with such things but it's easy to see how they're different.
Smart. Banks haven't been allowed to monetize their KYC data, but this new non-bank class of payments companies have this opportunity. Interac has been trying to do this for many years.
Some years ago I worked on a system let banks do identity assertions with proofs via SAML attributes instead of sharing customer PII. It is now a federation of banks in wide use for govt services in Canada. The use cases were really limited because the federation partners were too conservative to extend the identity services to relying party consumer applications real people actually wanted to use, and institutional sales cycles meant product feedback was glacial, so it has existed for over a decade in this relative backwater of gov-tech. I think identity companies have mostly failed to get traction because of a terminal lack of consumer sexiness, whereas Stripe has the jelly.
Other companies in the identity space have been working on protocols and platforms, but none of them had a user base to extend an identity federation services into, which means they have never been able to make a real or viable product, just interesting techs. An internet payment provider with young consumer traction getting into identity is a Very Big Deal.
It's going to position Stripe to knock out a lot of retail banks who can't offer similar services. Imo, this could make them bigger than Apple.
Do banks want to monetise their KYC data? In the UK, the government launched a similar system in 2014 called Verify, a platform for banks and other firms with existing customer relationships to offer identity verification as a service to the government, and eventually, third party sites. Users would choose a participating bank they has a relationship with and login to their account as verification.
But despite paying over £20 a user for each verification they only got one or two banks to join, and the scheme was a disaster.
"Banks haven't been allowed to monetize their KYC data"?
I work for a major US Bank and they are most definitely monetizing KYC data, in fact we have made several billion dollar acquisitions just to scoop peoples data.
The convention in Canada was there were limits on how much customer PII banks and the payment networks could collect, use, and share or sell, and how. "Monetize," in my comment means "sell to others like a social platform / ad-tech company," whereas I would agree it could be monetized in other ways.
What I see is that Stripe doing IAM for platforms and services that people use daily sets them up to dominate retail and small business banking services if they wanted to go there.
Actually, it seems that this did go into production - you can now verify identity using the service. For example, you can identify yourself for Govt. of Canada services (immigration, taxes) by logging into to your banking platform that then vouches for your identity using a service called SecureKeyConcierge / Verified.Me - note that ALL of Canada's major and quite a few minor banks are signed up to the service.
The way the service works by getting permission from you, the user, to share some part of your identity with the destination and you can chose what you share. You could pick for example just to share name and not DoB.
The one reason I hate this otherwise superbly designed service and refused to use it is that is has a dark pattern where it creates a "SecureKey / Verified.Me Concierge Account" for "you" when you use it and starts proxying/pre-emptying the bank-login-as-verification process.
WHICH IS STUPID
AND SCAMMY
IF YOU ARE READING THIS VERIFIED.ME, THIS IS DARK PATTERN BEHAVIOR AND IT IS NOT RIGHT OR FAIR
/start rant
From my perspective, the whole point is - inhale - "I sorta trust my bank because I have to so I will log on to them so that they can vouch for me but I definitely don't trust you so why are you being a dick and making me make an account with your service that I don't trust and will never trust" - exhale
Just let the bank vouch for me each time, this is what I expect a reasonable and non-scammy service provider to do. Don't wait till you have my info then tell me, hey, I will make an verified.met / secureconcierge account for you so that <insert your preferred monetization rationale here> before you do what you promised to do.
I get the idea that they want to consolidate a profile so that you can pick what to share without entering it each time but they way it is done right now feels really slimy.
I wrote an identity verification process with Verified.Me. I understand your concern regarding SecureKey's creation of a user account for its service built around identity verification sources such as the chartered banks. Your Verified.Me account is tied to your mobile device, and that it doesn't have any extra PII. You can delete your Verified.Me account from the app at any time. If you move to a new device and want to use Verified.Me, it will tell you that your account is already on another device and needs to be deleted from it before proceeding. The PII that is shared from the banks to the Verified.Me consumer is name, email, and phone number. At all times SecureKey said that it's the conduit and doesn't see that data.
Similar to Stripe, SecureKey currently offers an analysis service for photo ID that looks for anomalies and calls them out. The next version of the service integrates with provincial records to concretely confirm validity.
There's definitely a market for this. Back when I worked in porn (in the camming sphere), we had a team of moderators whose main job was verifying the identity (especially age) of performers. With over 10k performers, this was a lot of work. And you can't just do it once. You have to do it every time a performer starts a performance. People would try all sorts of tricks, like taking a picture of themselves with an older sister's ID, all kinds of fake IDs, some better than others. Verifying an identity over webcam is no easy feat, those moderators had to be able to tell different passports apart (many, many, nationalities), tease out the fakes, and then make sure that they person in the ID is the same person presenting the ID. Problem is multiplied by the number of performers in the room. Performers who are eager to start making money instead of satisfying the moderators checklist.
Agreed, there is a big market here. I worked on a real estate rental platform where we required ID verification for all listings and applications. At the time we used Berbix (YC company), which is practically the same as Stripe Identity. I would probably just use this Stripe feature today, since we were already using Connect for payments.
Oh I'm not saying Stripe has a magic way of solving this. I'm merely stating that this is a hard and annoying problem, that many businesses would gladly let someone else handle.
Does Stripe intend to make a giant online database of international identity documents? Why should we trust Stripe to secure these? It could be Equifax levels of problematic if there would be a intrusion, but I also can't tell how Stripe plans to use this information.
These databases already exist. For example, all driver's licenses issued in a state are part of the public record, and many companies already maintain databases of them. For example, you can sign up for an account with the NY DMV that allows you to search all DMV records, as long as your use falls within one of a dozen permissible use-cases (including "To verify the accuracy of information submitted by the individual to the business"). Identity documents are designed to be verifiable, which in this case generally precludes them from being secret
No. 1. Stripe cares tremendously about and knows the importance of security—we’ve learned a lot from securely processing hundreds of billions of dollars in payments annually, and Identity is built from those learnings. (https://stripe.com/docs/security/stripe).
2. Any biometric identifiers that are created to perform the verification are never stored or retained—they are fully removed from all of our systems within 48 hours (usually within minutes).
> We will typically store the rest of your submitted identity information for 3 years. This includes all images captured, extracted data from your ID document including name, date of birth, and ID number, and any information submitted via forms such as name, date of birth, SSN, email, and phone number, and the verification response.
That doesn't make me feel a lot better. :( The images are enough to generate biometric data such as facial recognition profiles.
Well, I don't believe what Stripe (or anyone) says; I believe what you do.
Does Stripe have a legal contract with users that says something to the effect of "if it does 1 and 2 above (by mistake or by choice doesn't matter) - that they will be liable for it". If not, all the support documents and technical security documentation is moot. I want to see "skin in the game" by Stripe. If you're so sure about "security" sign a legal contract.
This is only about the specific image processing Stripe does to match your selfie with your ID document. The rest of the information on the document—which is what the GP comment was asking about—is retained for 3 years. Referencing the 48 hour retention period instead of the 3 year one is very misleading in this case.
I never wanted Equifax to have any of my data, and yet here we are. After the breach, I wouldn’t ever be a paying customer to them if I had a choice. (Indirectly, I am still a “customer” in the sense that they probably still have my data and get new data about me—but apart from canceling all my cards, not sure what choice I have). In comparison, Stripe seems to charge for each product it offers. I think that’s a more fair and transparent model.
If the company you're interacting with uses Stripe ID verification and you are forced to use it to pay them, I'm not sure it's much better than going to a bank and opening an account and then Equifax getting the information immediately.
Edit (sorry, I don't think I can edit my own comment at this point): I think I was missing the point. Storing user data for 3 years after verification seems unnecessary for the user. So yes, it does sound like some data-mongering f*ckery is going to happen/is happening.
You are not a credit bureau's customer - the stores, public utilities, cell phone companies, banks, and so forth, are. They share that information to minimize their risk in extending credit (even something like billing you at the end of the month for services rendered is a form of credit) to you.
And frankly, if Stripe is offering any form of credit, it's likely working with the credit unions too.
Vote for representatives that pass laws similar to the GDPR but for USA? If Equifax or you were EU-liable, you could ask them to show, modify or remove any and all of your data.
These databases already exist. Typically the way it works is after you claim an identity, they will look up past addresses, phone numbers or employers then present multiple choice questions asking which one is part of your past. The companies I've seen that do these are not hosting (or claim to not host) any of the data, but rather have hooks to fetch it from financial institutions. I think it's mostly credit bureaus, but could also be banks.
The only way i would trust such a thing is if i have complete control over my data and how it's used (that's probably never gonna happen from a for-profit imo)
> It could be Equifax levels of problematic if there would be a intrusion
I'm sure they're not as lax as Equifax. I would hope that Stripe compartment all these documents so that a compromise of one database is not a compromise of the whole database. That's basic data storage hygiene in the information age. `Don't put all your eggs in one basket` as the saying goes.
I think the Estonian e-Card scheme is the right one despite hiccups in its implementation and ID verification should be the domain and responsibility of governments. Each ID card has an embedded private key-public key pair and you can sign to reveal your identity without having to resort to giving away anything else about yourself. There is already a zero-risk way for customers to verify themselves, so giant ID databases are a step backwards.
I am too, but that's not an endorsement. And more pertinently, that is nowhere nearly enough.
Every database of value tends towards uncontrollable sharing over time. The more available and more valuable it is, the harder it is to fight that trend.
The best thing for humanity is to stop making high-value data hordes like this. Unfortunately, the interests of smaller groupings are the reverse.
Stripe hires elite Stanford grads unlike Equifax is the simplest answer they probably wouldn’t say publicly. But the pedigree and engineering talent is miles better.
I really despise this trend of uploading your ID and a selfie for verification. I know it makes sense in some legal frameworks, but beyond that I find it invasive and risky (and rude.)
I recently had, twice, to do stuff WAY more intrusive. Video/conf call, need to hold my passport, need to have my phone on hand... People on the other side would call me on my phone to verify it's my number and they'd also send me a SMS with a code to verify on that phone.
After that they have: my face, copy of my passport, my voice, my phone number, my IP (unless I'm really going out of my way to obfuscate it), my email, etc.
Once I did this, then the series of documents to sign using Docusign came in.
That was the most serious KYC/AML I've ever seen.
I don't like it much but I gotta say: I can definitely see how it raises the bar for would be scammers/impersonators.
You said it happened twice. I haven't yet had to face this level of intrusiveness, but I fear that it's coming for all of us. May I ask what companies these were? If you don't want to name the exact companies, could you say the general purpose (opening a bank account, buying or selling real estate, incorporating a business, etc.)? Also, which country (I'm assuming the U.S.)?
It also outright disincentivizes usage for some people. The biggest group is probably people without a proper ID (a very US-only issue), but I personally avoided showing or sending my ID anywhere before I was able to change my legal name to one that didn't make me want to rip my eyes out.
MasterCard and their "True Name" program did a good thing there.
It’s not really a “trend”—if you think about it, ID verification is already required when checking into hotels, buying alcohol, or when visiting a bank teller.
As more commerce moves online, Stripe Identity was built to significantly reduce the number of organizations and humans that would touch your ID—in a faster, secure way that’s hosted by Stripe (https://support.stripe.com/questions/common-questions-about-...).
In very few of those use-cases does the entity 1) _retain_ any of that data, 2) posses an internet-scale database of identities.
And as we've all come to know the distinction between "able to surveil" and "collect it all" crosses a threshold to make it of a different kind.
If one's mindset is that in general, tech companies, unlike those other entities store it all, then there actually is a recent "trend" to migrate a normal behavior into an abnormally socially adjusted space.
It is very much a trend and that is very much what you are describing. The problem with identity verification is
a) Business that have no business requesting them do so. Linkedin, Google, Facebook does this when they suspect you are a bot. But if you have been a long time user, they hold your account with your personal data as hostage. You cannot delete your account if you object to providing your official documents.
b) There is very little legal protection if companies (not saying Stripe will) use your official documents to build an extremely detail online profile of you. Its all based on trusting what these companies say.
Just last month I had a DJ company ask for an ID and selfie for a $200 software purchase.
Maybe these things are designed for KYC’ing crypto and buying alcohol but it’s definitely a trend to apply this process broadly. All for the fear of generally preventing everyday fraud, piracy, and maybe just collecting data for some nebulous future use. Of course they rarely do the actual basics and apply any thought to not treating your real customers like criminals.
I don’t doubt Stripe can make the process better and do it in a good way, but can Stripe minimize what this process is even applied to in the first place and avoid manufactured consent.
One of the nice things about the internet is/was that it requires less bullshit and red tape than many real-life interactions. The internet becoming as bureaucratic and oppressive as, say, international travel, is absolutely a trend - and a very harmful one.
It's not a good trend though. I actually prioritize doing business with vendors that don't do this (I only shop at stores that don't generally card for alcohol for instance)
At work we do eIDV of customers and we tested 5 companies. One was quality but too expensive and required too large commitments; two couldn't detect badly photoshopped frauds we threw together, another couldn't detect a printed or on-screen copy of a document being captured (vs the real document - difficult to do, but important). The fifth which we're using can detect printed copies of documents around half the time, but their OCR is shockingly poor when it comes to recognising DoBs so we have to manually check and update the age.
We'll try Stripe and see how much fraud they can detect.
It is absolutely impossible to validate the authenticity of an ID document from a photo. Even if you capture a high-res photo and have it inspected by a trained document expert.
Fortunately, it is not necessary to do this. Modern passports and many identity cards contain NFC chips that allow you validate the data on an identity document with complete certainty (as in: you know that the data is correct and not tampered with). In the majority of cases (depending on the document supporting the necessary protocols) it is also possible to prove that the chip is authentic and not a clone.
Since the chip also contains a good quality color photo of the document holder, it is then possible to match this with the person holding the phone and do liveness detection.
Remote optical verification of documents is impossible, and anyone who claims they can do it isn't being honest.
It's a cheap way out. Anti-counterfeiting feasures like color shifting ink, paper feel, polymers, watermarks, microprinting, UV strips cannot be checked over a webcam.
Original paper documents are an anachronism. Any serious ID verification involves phoning home. Like police searching their database, border guards scanning your passport, or calling the car insurance company. Visa has depreciated offline EMV transactions. Offline credentials can't revoked so there's only the expiration date.
A bunch of verification systems use a video feed instead of a static photo. This helps a lot to weed out photoshops, and you can also check for reflections (the ones I had to go through ask you to move your camera under different angles)
While there is no infallible system, I think we currently have decently efficient solution (with sizable trade-offs of course, as you rely on the user having a smartphone that is supported, with a decent camera, decent lighting etc.)
Very curious to hear your results. In the past we used Onfido but eventually switched to Jumio. This was mostly due to Jumio performing better with Passport and VISA documents. We may in future move to Persona as we use them for SSN verifications and their customer support / account management team is fantastic.
The Stripe Identity product is fantastic. Some of the most impressive things:
1. If you are at a desktop, there is an easy transition to using your phone to take a picture of your ID (or a selfie if that's the use case - it will match selfies with ID photos), and then complete verification on the desktop.
2. It does all the image analysis (i.e. is the ID in focus, etc.) in browser without the need for a native app.
This almost proves that webapps are a competitive substitute to AppStores - making the consumer detriment very hard to prove in the current anti-trust framework.
> If you are at a desktop, there is an easy transition to using your phone to take a picture of your ID (or a selfie if that's the use case - it will match selfies with ID photos), and then complete verification on the desktop.
Meaning they can identify my laptop and phone as belonging to the same person. I prefer they don't.
Just be aware that, no matter how seamless it is, you still getting crazy bounce rates for it. You would need a really good reason to use it (basically, be a bank and need KYC or something).
Of course, a common use case for this would be to only show the Stripe Identity UI when a user has a higher chance (based on IP, time of day, other on-site behavior, etc.) of being fraudulent in the first place, in which case a higher bounce rate is a feature, not a bug.
Readit News
That would be an incorrect assumption. Per https://support.stripe.com/questions/managing-your-id-verifi... customers of Stripe Identity have API access to "captured images of the ID document, selfies, extracted data from the ID document, keyed-in information, and the verification result".
Thus, when you use Stripe Identity to verify your identity, you have to trust that:
1. The website doesn't download, retain, and later leak your selfie and identity information.
2. The website's Stripe API token isn't compromised and exploited by identity thieves to access your selfie and identity information.
Stripe appears to be leaning heavily on their claim that they don't disclose "biometric identifiers" to websites and that these "biometric identifiers" are deleted from their systems within 48 hours. This is extremely deceptive considering that biometric identifiers can be reconstructed from the selfie.
> Considering that Stripe was originally known for letting websites accept credit card payments without seeing your credit card number, one might assume that Stripe Identity only allows websites to see the verification result, and not your selfies and scans of your identity documents.
A few points:
- Fundamentally, Identity makes it possible to choose how much of this data traverses / is stored on your servers, just as Stripe did with card numbers.
- There's a basic difference between card numbers and identity verification. With card numbers, you (generally) don't really care about the number -- you just want the payment. With ID verification, however, many businesses have good reason to want more than just the verification result. For example, they are often subject to compliance requirements that mandate that they themselves possess or have access to the raw information. They may need or wish to perform additional checks on their side. Etc.
- The relevant UI in Identity is deliberately very clear on this points in order to avoid the assumption you're stating. The flow explicitly says "Stripe and [Business] may each use your data." Even though an end user might consider it suboptimal for the business to have their data, we still view it as an improvement to the usual status quo, where this data is frequently stored in very ad hoc fashion and without rigorous security protections.
- While many of the businesses initially building on Identity wanted access to the raw information, it may well make sense for us to enable them to restrict themselves in the future. In this world, Stripe could tell their customers that the business doesn't have access to the raw details. (This might even make sense for Stripe payments in the future.) As a philosophical matter, we consider ourselves to serve the business, which means that limiting access to what we consider to be the business's own information feels a bit strange. That said, it might sometimes be in the interests of the business to allow them to limit themselves in this fashion (especially as Stripe's brand recognition among consumers grows).
- There's a separate concern about compromise of the business's credentials leading to inadvertent disclosure of this information (a situation analogous to an S3 bucket key getting leaked). This is of general concern to us in lots of situations, not just with Identity. We have some new functionality on the way here.
> Fundamentally, Identity makes it possible to choose how much of this data traverses / is stored on your servers, just as Stripe did with card numbers.
There's a stark difference in how Stripe treats exports of card numbers versus exports of raw identity verification data. This makes it way easier, and more likely, for Stripe customers to choose to store raw identity verification information.
> With ID verification, however, many businesses have good reason to want more than just the verification result. For example, they may be subject to compliance requirements that mandate that they themselves possess or have access to the raw information. They may need or wish to perform additional checks on their side. Etc.
I acknowledge that some businesses have a need for this. But I see Discord and Clubhouse among your customer logos, and your product page talks about non-KYC use cases. Many of your customers will have access to identity documents without really needing it. That sucks for the end users of Stripe Identity, because it makes it more likely their data will be misused.
A concrete suggestion: make it possible for businesses to choose whether they have access the raw data, and expose the choice to the end user in the Stripe Identity flow. Ideally, businesses that want the raw data would be subject to security compliance requirements. This is an opportunity for Stripe to be a leader in setting high standards on how this type of data should be handled.
> As a philosophical matter, we consider ourselves to serve the business, which means that limiting access to what we consider to be the business's own information feels a bit strange.
Maybe I'm wrong , but once a customer upload the document on Stripe Identity they are supposed to be YOUR documents.
I worked in Bank as a Service , fundamentally when a customer goes through a verification process , the documents uploaded are not the owned by the partner using our APIs. They are owned by us , the Bank.
For Stripe Identity the same should have apply. Here the goal is not "Lock the Partner" but rather to protect them.
Now that discord has access to my Passport , in case of an identity theft could you tell me EXACTLY whose liable for the leak in regards to the law ?
With BaaS it's pretty clear , the Bank carry the responsibility to keep those documents safe , thus it's safer to not give access to a basic business to the raw details.
With the current API design you are offering, it's more ambigous and more prone very large leak within a business information system like Discord or Uber etc..
Those leak will happen.
I don't ever want to have a card number in my database or via a administration system (my own or my provider's).
So I care... but just perhaps not in quite the way you're thinking :)
I trust Stripe more than a random online forum, a dating app, or a social network, which might offer a higher quality service when people are verified. There's a high risk that the ID documents will leak from these services at some point if they get access to them. I don't want them to know who I am at all, if they don't need to know.
It would also offer a way for preventing sybil attacks on P2P networks, or help connecting to non-evil nodes on a P2P network (such as Bitcoin Lightning Network) without knowing the other person. In these cases there could be a some kind of signature generated by Stripe that could be used as an additional trust factor without centralizing the system.
This sounds great -- I don't want to be handling sensitive data of users, and I don't want to give sensitive data to businesses. But I'd rather this be a separate Verification product, with different branding, docs, and UI, so users and businesses are all clear on what's happening to user data.
It's literally called "(K)now (Y)our (C)ustomer".
> They may need or wish to perform additional checks on their side. Etc.
So they get all the data in the off chance that a Stripe customer might want to do something with the data aside from the basic “yeah our large global identity verification service says this person is legit.”
I’m not super clear what a company might ”wish to” do with that data that isn’t served by the basic “this person is who they say they are” function (Does Stripe need their clients to act as guinea pigs to see if the service actually works as intended? If their mysterious black box “wishes” turn up a case where this isn’t working as intended, are your customers required to share that data with you to ensure the overall reliability of the Stripe Identity service? Or do they just get to build a database of info they get from Stripe Identity?)
> While many of the businesses initially building on Identity wanted access to the raw information, it may well make sense for us to enable them to restrict themselves in the future.
Oh nevermind, asked and answered! Just turn on the data hose to whoever has a website and will pay Stripe for identity data and maybe adjust it later if you catch some flack for this practice?
It’s kinda hilarious that the whole “people trust Stripe with their data” as part of the sales pitch as if this didn’t come across to me (a layperson) as a direct violation of that particular trust.
Businesses that do not have a legitimate reason to view my sensitive document like Passport , should not be allowed to do so.
Only authorized institutions like Licensed Payment Institution / Banks / Insurances etc... should be allowed to do so and AFTER they've been approved.
It's sad because you can tell right away that this will we be abused by Stripe's customers inadvertently. Just like Uber "God View" thats you view any customer ride...
Pretty sure the amount of "Identity Theft" or "Privacy" Scandal is going to explode with such technology available for everyone.
I don't know how a product manager at stripe could tell himself that "Yes , it make sense to give access to sensitive documents" in an age where people are seeking more privacy.
I get parent comment's totally legitimate security concerns. And businesses that have no business having my identity should surely not be asking for it. But I don't honestly understand how this has anything to do with Stripe. These businesses (which for whatever reason are asking for ID verification before doing business with you) are just using Stripes API to verify identity instead of just taking your info themselves.
Any customer giving their information presumably knows they are giving said business their identity documents, the customers might not even know that the business is using Stripe's API.
Furthermore, Stripe is ostensibly coming in here to streamline the process for business taking identity info from customers. Why - in your opinion - is it worse for consumers when these-type businesses (which ask for identity), use their own-rolled id verification than using Stripe's?
Most companies aren't even supposed to ask for identity papers is Stripe verifying with the passport issuer whether the country allows given their passport to some identity?
I think there should be some sort of consent system built in were when the API consumer wants to download a passport the customer gets an email with the question if they consent in them fetching a copy.
Dead Comment
This is true, but it's also kind of a misleading statement; the original selling point was that you could accept credit cards without having to deal with the requirements of PCI compliance and merchant accounts, which is done (partially) by you not ever seeing the card data.
If there was similar compliance regulation around document storage, I would assume that Stripe would use "Identity-Document-Standards" compliancy as a selling point. As far as I know, there are no such requirements.
I do think your #2 point though is exceptionally valid, and would hope that the majority of Stripe keys are scoped to not even provide access to this data/endpoints.
Edit: grammar
If you want to export credit card numbers from Stripe, you can only have it transferred directly to another PCI DSS Level 1-compliant payment processor, and Stripe imposes rather strict requirements on the transfer: https://stripe.com/docs/security/data-migrations/exports#whe...
If you want to export ID documents or selfies, you can just make an API call or use the web interface. This can and will be abused.
When a hotel copies my passport, they get a jpg. If they use Stripe, now I know they have my biometrics serialized to JSON. That feels way riskier and scarier to me, especially now that it's all centralized by Stripe.
We hear about our personal data getting leaked and hacked every day, and here is Stripe making themselves an enormous target and serializing all the data for malicious actors.
This feels like a really tone deaf misstep by the company.
Stripe could do this differently:
1. Allow the customer to choose whether or not they need access to the evidence.
2. If customer has chosen to receive access to the evidence, the Stripe Identity UI should clearly disclose this. (And they shouldn't try to deceive users by talking about deleting biometric identifiers.)
3. Require customers with access to evidence to adhere to certain security standards, similar to how they treat exports of credit card numbers: https://stripe.com/docs/security/data-migrations/exports#whe...
Stripe could have been a leader in setting high standards on how this type of information is handled. Instead they've opted to go the easy route and maximize profits while the rest of us pay the negative externalities from identity theft.
I thought that Stripe's original selling point was that you could easily accept payments online without having to integrate with complicated bank and payment processor tech.
For example, imagine Joe Biden buys a widget from WidgetsR.us and wants it shipped to his home address of 1600 Penn Ave in DC.
Instead they could route through Stripe (where 123_joe corresponds to Joe Biden's identity docs in Stripe), which fills in the missing info. That way WidgetsR.us never knew the $NAME or $ADDRESS of user 123_joe, but was still able to use them. (Yes, they could send that info to themselves, but then they're on the hook for protecting it.) The huge downside here is putting Stripe in your business's critical path. But if it's already there for payments, then why not for identity?At this point there is giant databases containing everything people need to take complete control of your identity sitting there just waiting to be hacked.
I have no idea how to change it/fix it. But it seems weird to me.
The government already operates an identity service via passports. The only reason they do not have an electronic identity service yet is because it is beneficial for them to be able to blame private actors when things go wrong.
To make it even more complicated, regulators often hold contradictory views. They want to see increased safety, but in the same breath will announce actions against companies for violating privacy. This is a super-difficult balance to strike.
Specifically for Stripe, I trust them. So if I see that a new start-up is using them rather than rolling their own solution, that increases my trust. But it means there is now a big giant server in the cloud with millions (billions?) of identity documents that is worth a lot of money for hackers.
[1] https://stripe.com/global
[2] https://stripe.com/docs/acceptable-verification-documents
Re: Age Verifications on Google & YouTube: this has been covered well elsewhere. Google is required to do so by EU law. Blame regulators not the companies.
If it's limited to only people receiving payments, then it's far more reasonable than what I thought was happening (eg. people getting randomly asked for ID scans to use their service).
No. This is something we’ve become dangerously desensitized to.
Is bot spam rampant on discord or something? Are less invasive forms of verification (eg. SMS, credit card, or requiring a deposit) not enough? Can it not be solved via technical means? eg. requiring users to opt-in before receiving messages from a bot?
> And shipping services use Identity when a user is suspected as a fraudster—to double check before creating fraudulent shipping labels.
Yet I can buy hundreds of dollars of goods off amazon (or any other e-commerce site) without uploading my ID and giving them a live video feed of my face.
For both of these use cases, I don't doubt that ID verification provides benefit, I just find the privacy tradeoff to be unacceptable. As an analogy, a store can probably cut down on shoplifting if they performed ID checks at the entrance and kept a visitors log, but I think most people would find that unnecessarily intrusive and would refuse to patronize that store.
This doesn't seem like it works.
Careful there, mate. This is just another form of the infamous "Nothing to hide" fallacy.
https://en.wikipedia.org/wiki/Nothing_to_hide_argument
See also: https://news.ycombinator.com/item?id=27503674
Some years ago I worked on a system let banks do identity assertions with proofs via SAML attributes instead of sharing customer PII. It is now a federation of banks in wide use for govt services in Canada. The use cases were really limited because the federation partners were too conservative to extend the identity services to relying party consumer applications real people actually wanted to use, and institutional sales cycles meant product feedback was glacial, so it has existed for over a decade in this relative backwater of gov-tech. I think identity companies have mostly failed to get traction because of a terminal lack of consumer sexiness, whereas Stripe has the jelly.
Other companies in the identity space have been working on protocols and platforms, but none of them had a user base to extend an identity federation services into, which means they have never been able to make a real or viable product, just interesting techs. An internet payment provider with young consumer traction getting into identity is a Very Big Deal.
It's going to position Stripe to knock out a lot of retail banks who can't offer similar services. Imo, this could make them bigger than Apple.
But despite paying over £20 a user for each verification they only got one or two banks to join, and the scheme was a disaster.
E.g. when I registered for Covid vaccine I logged in using my bank login.
There are other ways to do it too but since I already had an account in a participating bank I didn’t bother looking into them.
I don’t know if banks earn anything from it. I’d be surprised if they did.
I work for a major US Bank and they are most definitely monetizing KYC data, in fact we have made several billion dollar acquisitions just to scoop peoples data.
What I see is that Stripe doing IAM for platforms and services that people use daily sets them up to dominate retail and small business banking services if they wanted to go there.
See this page:
https://services.securekeyconcierge.com/cbs/saml/login?l=1&l...
The way the service works by getting permission from you, the user, to share some part of your identity with the destination and you can chose what you share. You could pick for example just to share name and not DoB.
The one reason I hate this otherwise superbly designed service and refused to use it is that is has a dark pattern where it creates a "SecureKey / Verified.Me Concierge Account" for "you" when you use it and starts proxying/pre-emptying the bank-login-as-verification process.
WHICH IS STUPID AND SCAMMY IF YOU ARE READING THIS VERIFIED.ME, THIS IS DARK PATTERN BEHAVIOR AND IT IS NOT RIGHT OR FAIR
/start rant
From my perspective, the whole point is - inhale - "I sorta trust my bank because I have to so I will log on to them so that they can vouch for me but I definitely don't trust you so why are you being a dick and making me make an account with your service that I don't trust and will never trust" - exhale
Just let the bank vouch for me each time, this is what I expect a reasonable and non-scammy service provider to do. Don't wait till you have my info then tell me, hey, I will make an verified.met / secureconcierge account for you so that <insert your preferred monetization rationale here> before you do what you promised to do.
I get the idea that they want to consolidate a profile so that you can pick what to share without entering it each time but they way it is done right now feels really slimy.
/end rant
Similar to Stripe, SecureKey currently offers an analysis service for photo ID that looks for anomalies and calls them out. The next version of the service integrates with provincial records to concretely confirm validity.
How would Stripe solve something like this?
That doesn't matter.
2. Any biometric identifiers that are created to perform the verification are never stored or retained—they are fully removed from all of our systems within 48 hours (usually within minutes).
More on this at https://support.stripe.com/questions/managing-your-id-verifi....
That doesn't make me feel a lot better. :( The images are enough to generate biometric data such as facial recognition profiles.
Does Stripe have a legal contract with users that says something to the effect of "if it does 1 and 2 above (by mistake or by choice doesn't matter) - that they will be liable for it". If not, all the support documents and technical security documentation is moot. I want to see "skin in the game" by Stripe. If you're so sure about "security" sign a legal contract.
No need to go any further for an example than Google and its "Don't be evil" somehow evolving into "Normalize the creepy".
They could be charging you AND creating an international ID database.
And frankly, if Stripe is offering any form of credit, it's likely working with the credit unions too.
The only way i would trust such a thing is if i have complete control over my data and how it's used (that's probably never gonna happen from a for-profit imo)
I'm sure they're not as lax as Equifax. I would hope that Stripe compartment all these documents so that a compromise of one database is not a compromise of the whole database. That's basic data storage hygiene in the information age. `Don't put all your eggs in one basket` as the saying goes.
I am too, but that's not an endorsement. And more pertinently, that is nowhere nearly enough.
Every database of value tends towards uncontrollable sharing over time. The more available and more valuable it is, the harder it is to fight that trend.
The best thing for humanity is to stop making high-value data hordes like this. Unfortunately, the interests of smaller groupings are the reverse.
If there was, all black-hats would be coming from Ivy League schools. They’re not.
After that they have: my face, copy of my passport, my voice, my phone number, my IP (unless I'm really going out of my way to obfuscate it), my email, etc.
Once I did this, then the series of documents to sign using Docusign came in.
That was the most serious KYC/AML I've ever seen.
I don't like it much but I gotta say: I can definitely see how it raises the bar for would be scammers/impersonators.
MasterCard and their "True Name" program did a good thing there.
As more commerce moves online, Stripe Identity was built to significantly reduce the number of organizations and humans that would touch your ID—in a faster, secure way that’s hosted by Stripe (https://support.stripe.com/questions/common-questions-about-...).
We are also very direct about collecting consent: https://support.stripe.com/questions/common-questions-about-....
And as we've all come to know the distinction between "able to surveil" and "collect it all" crosses a threshold to make it of a different kind.
If one's mindset is that in general, tech companies, unlike those other entities store it all, then there actually is a recent "trend" to migrate a normal behavior into an abnormally socially adjusted space.
> As more commerce moves online
It is very much a trend and that is very much what you are describing. The problem with identity verification is
a) Business that have no business requesting them do so. Linkedin, Google, Facebook does this when they suspect you are a bot. But if you have been a long time user, they hold your account with your personal data as hostage. You cannot delete your account if you object to providing your official documents.
b) There is very little legal protection if companies (not saying Stripe will) use your official documents to build an extremely detail online profile of you. Its all based on trusting what these companies say.
Maybe these things are designed for KYC’ing crypto and buying alcohol but it’s definitely a trend to apply this process broadly. All for the fear of generally preventing everyday fraud, piracy, and maybe just collecting data for some nebulous future use. Of course they rarely do the actual basics and apply any thought to not treating your real customers like criminals.
I don’t doubt Stripe can make the process better and do it in a good way, but can Stripe minimize what this process is even applied to in the first place and avoid manufactured consent.
Dead Comment
We'll try Stripe and see how much fraud they can detect.
Fortunately, it is not necessary to do this. Modern passports and many identity cards contain NFC chips that allow you validate the data on an identity document with complete certainty (as in: you know that the data is correct and not tampered with). In the majority of cases (depending on the document supporting the necessary protocols) it is also possible to prove that the chip is authentic and not a clone.
Since the chip also contains a good quality color photo of the document holder, it is then possible to match this with the person holding the phone and do liveness detection.
Remote optical verification of documents is impossible, and anyone who claims they can do it isn't being honest.
Original paper documents are an anachronism. Any serious ID verification involves phoning home. Like police searching their database, border guards scanning your passport, or calling the car insurance company. Visa has depreciated offline EMV transactions. Offline credentials can't revoked so there's only the expiration date.
While there is no infallible system, I think we currently have decently efficient solution (with sizable trade-offs of course, as you rely on the user having a smartphone that is supported, with a decent camera, decent lighting etc.)
1. If you are at a desktop, there is an easy transition to using your phone to take a picture of your ID (or a selfie if that's the use case - it will match selfies with ID photos), and then complete verification on the desktop.
2. It does all the image analysis (i.e. is the ID in focus, etc.) in browser without the need for a native app.
Other apps cannot do the same.
Like messaging or social networks need things like notifications. Or those for IoT related tasks, which would need Bluetooth or such.
Meaning they can identify my laptop and phone as belonging to the same person. I prefer they don't.