15 ms·
(Stripe cofounder.) > Considering that Stripe was originally known for letting websites accept credit card payments without seeing your credit card number, one
by pc 5y ago
(Stripe cofounder.)
> 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.
- agwa 5y agoThanks for your reply. > 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.
- breakfastduck 5y agoDepending on where you're located, there is a responsibility to only take information you require. I get your point, but you seem to be implying this data is captured without the customer being aware. That will not be the case, surely.
- pc 5y agoAppreciate your feedback. On the first point, limitations on what the secret key can access are coming very soon. > 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. Yes, per GP comment, I think this is a good idea. I suspect we'll do it.
- SmellTheGlove 5y ago+1 on being able to choose. I’m building a personal finance app right now, and where I can I’m choosing to not ingest or retain sensitive data. While the origin of this is scratching my own itch, I suspect that I’ll get better traction if I can overtly say I’m not collecting data I don’t need or holding onto it for longer than you want me to. I’d love to be able to just get a Boolean back.
- unityByFreedom 5y agoHere we go, online IDs. It seems inevitable that some entity will leak this data at some point. Then what?
- dcow 5y agoBusinesses collecting identity information is nothing new. Somebody like Stripe putting a concerted effort out there to make it more secure and improve the experience so that identity information is stored in a less ad-hoc way is a win and will reduce the odds of some catastrophic leak. If you are only worried about identity leaks now then you are simply miss-calibrated on your assumptions about the nature of online identities. If you are seriously this worried, then you probably shouldn't be using the internet for anything.
- echopom 5y agoHey Patrick, > 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.
- maccard 5y ago> 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 ? Discord only has access to your passport if you upload it to them. They don't have access to it by virtue ofthem being a stripe customer.
- rbobby 5y ago> With card numbers, you (generally) don't really care about the number -- you just want the payment. 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 :)
- jart 5y agoDo 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?
- caslon 5y agoDo 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?
- neolog 5y ago> 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.
- Geee 5y agoThere 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.
- hn_throwaway_99 5y agoVery 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".
- jiux 5y agoAny plans to add developing countries, in particular the Philippines?
- fay59 5y agoOne 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?
- dcow 5y agoI sure hope so! Anonynimity is not a fundamental human right, it is a tool that should be used sparingly and only when the situation is appropriate (whistleblower, for example). The internet would be a better place if there were more identity requirements SO LONG AS companies are not legally allowed to sell or transmit that information to advertisers or other third parties without explicit opt-in consent ideally on a per-use basis. Or simply at all. If easier access to online identity systems means we as a society turn focus on legal ground rules governing how that data is treated and used, then we'll be in a really good position (: I'm excited.
- unityByFreedom 5y ago> The internet would be a better place if there were more identity requirements SO LONG AS companies are not legally allowed to sell or transmit that information to advertisers or other third parties without explicit opt-in consent ideally on a per-use basis. Or simply at all This is a pipe dream. The online world spans the globe and we can only enforce the law in our own respective countries. And even if all countries were cooperative about enforcement, distributed communication tools already exist. The internet has always been a place where you can go to share your thoughts without worrying about what your family or friends think. I don't think that will change in our lifetime, if ever. Anyway, the market can sort this out. If using an ID to authenticate your Twitter account makes Twitter more successful than its competitors, great! I would not count on it.
- dcow 5y agoA fully anonymous society is also a pipe dream. It doesn't work. You already provide your name and phone number and email to Twitter. You already identify yourself. We're talking about making that exchange more reliable and more secure...
- pbreit 5y ago> subject to compliance requirements that mandate that they themselves possess or have access to the raw information It's literally called "(K)now (Y)our (C)ustomer".
- grzm 5y agoAnd such a short edit distance from CYA!
- newbie789 5y agoEmphasis mine. > 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.
- aliasEli 5y agoHow 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.