So my name is Uri Beck. I'm a distinguished architect at eBay and Identity. I'm also building up teams in Berlin and looking for senior software architect in IM. So if you're interested in working for me, please reach out to me after this, after this presentation. So today I'll talk about our journey to strong customer authentication as part of the PS two, two regulation briefly about eBay.
I, I assume that most of you know about eBay, a big marketplace. We have at any time about 2 billion live listings, 132 million active buyers worldwide in over a hundred, in 190 markets, and about $73 billion global merchandise value. That's the value of the items that are sold within a in a year. What fewer people may know about eBay is that it isn't just a marketplace, it is also a financial service company.
And, and more and more so, just to give you a few examples of what we're doing in this area, we, for example, offer finance solutions for our sellers together with some, some banks and other finance partners.
We have credit cards in certain certain countries and also we, we allow our sellers to keep their proceeds within their account. So you sell something, you keep the amount stays in the, at eBay, and then you can use it to either buy on eBay to buy shipping labels to issue returns or refunds, or also trigger in on demand payout.
And because we do, so, this is close to a bank, as you can imagine, it's not quite a banking license, but it gets in that area. And so that triggers the PSD two regulations, specifically the requirement to do, to perform strong customer authentication. But apart from being forced to do so, it's also some something that matters to us now that we, we keep the proceeds, the funds of our sellers. We have a large responsibility and we want to protect our sellers and, and therefore also protect us quick.
I mean, this probably comes to no surprise to to this audience, but most of our users still unfortunately use passwords and username passwords, and that's just a poor, it's a poor solution. Passwords are shared across multiple webpages. Many who don't use password managers reuse the same password. So attackers can guess for leaked passwords, try them out on, on websites such such as eBay, even if the leak wasn't announced. And those can lead to account takeovers fraud, which which is financially bad for both the users as well as for us.
Now, the PSD two regulation, specifically the regulatory technical standard on strong customer authentication re requires strong customer authentication or two factor authentication for our subset of our users, specifically sellers in Europe, the regulators in Europe, we have two the CSSF in Luxembourg and we have the FCA in, in the UK because of Brexit. The, the documents, the legal documents, you can see the links here. There are actually two versions because of Brexit.
Again, we have a, a second VER version that is specific to the uk. It is mostly identical, but there are some changes that the u UK regulators see a bit differently. In a nutshell, these documents, they specify that you have to do as an A-S-P-S-P account servicing payment service provider, which is us and I, I struggle pronouncing this every time I, I use this word they to require SCA for payment initiations as well as accessing account sensitive, sensitive payment data such as account numbers of credit cards.
It also specifies and leverages certain exemptions.
So the regulators appreciated that. Strong customer authentication is also a friction for users. So they allow banks or as psps such as us to use certain exemptions where we don't have to use SCA. This applies to low amount transactions. So anything below a hundred euros or I think 85 pounds can be, can be exempted from SCA as well as low risk trusted beneficiaries. If I perform frequent transactions to the same recipient, I can trust this and I don't, this is a recipient and don't have to perform SCA again, what is SCA?
It is two factors out of three buckets, knowledge, possession and inherit samples for, for knowledge is passwords, pins, possessions could be like what you own on my phone. So typically S-M-S-O-T-P or email OTP authenticator app pass keys, I would also consider in that, in that bucket and inherit is what you are.
So biometrics such as your fingerprint. Now our journey to this implementation, this, you see this tired man that was me and a lot of our staff.
It is, it is quite involved in particular for a company as large as eBay. And we have a lot of teams that not always, you know, they, they work a little bit in in silos such as it often happens in big companies. We needed to identify the flows where we had to identi add strong customer authentication. We found about a hundred such flows where we either initiate a payment or show a payment sensitive data and that impacted more than 50 teams. So the change was small for each team, but you need to reach out to coordinate and they need to plan for it.
We also explored exemptions for SCA, which we previously didn't need so that the friction is lower. We have some of the exemptions in particular, the low amount exemption is something that we offer and we're exploring adding some of the other exemptions. We also added more SEA factors to have more flexibility for our users such as pass keys. We were one of the first larger tech companies offering tech pass keys on our webpage authenticator apps as well as what I call device binding.
So basically a challenge response where we store certain information in addition to a private key about the device and we can recognize if this device was previously signed on and so indicating as a more trust, trustworthy device. We also, and I'll talk about this in a little bit at the end, had to accept EIA certificates for certain regulated third party providers and also added digital signatures on certain external APIs. I'll come to that. So let me talk a little bit about PAs keys. I think there were some presentations already about it.
The intention is to replace passwords as the name kind of implies. They're highly secure based on private and public key infrastructure, very user friendly. Contrary to the passwords, they're cloud synced and and cross device cloud SYC means I can install, sign up on one device on my iPhone, then go go to my Mac OS and immediately have the same PAs key available. I don't need to sign up again.
This show basically shows the architecture where we, you can sign up on my phone, the pass the public keys uploaded to us and then the platform providers sync sync the private key in the background and I can have access from other machines. It Fido is also working. The Fido alliance is also working on protocols that allow, allow synchronization across platform providers. I think that's something that would be really great for user friendliness right now. Even when I use Google Chrome on my Macs, it's not auto automatically picking up the key from my iPhone. I think that would be great.
So the benefits that we see is an improved sign-in success rate, I talked about it in the panel earlier today. So our password sign-in success rate is about 70%. That's not great. It means that 30% of all cases people either type in a wrong password or for some other reasons are not. Maybe they don't remember the password so it fails. Whereas with PAs keys we have close to a hundred percent, I think around 97%. We also see a reduced time to authenticate, whereas it usually typically takes six seconds with a password.
We can, we see a reduction about 50%. We see also see a lower recovery churn that forget your password flow is something that is each one of you, I'm sure is threading, threading to to use. It's not fun and we see a lot less of that. And overall a, a reduced reliance on passwords.
The challenges that we see is that we don't see, think their users are aware already yet in many cases. So we have about, I would say 10 or 12% of our users who use pass keys. We'd love to see that to go to a hundred percent.
Some of our users are, or many of our users are not aware of what my pass key is, but some also don't have the capabilities particular on the desktop version of eBay. We see that only about fif half of our users have a capable OS or hardware support.
On, on the mobile side, we're pretty good. We have close to a hundred percent support the interoperability between different cloud providers. I mentioned it. That's something that I think is still a friction that needs to be resolved for this to be really appealing to users. Another open question is regulatory compliance acceptance.
The, the fact that those private keys are synced within the platform kind of defeats the purpose of the proof of possession. So it's gonna be interesting if in PSD three we see some feedback on that, how this is handled by regulators and then the forget your password flow is, is still one of the, the the weak link. It doesn't help if you have the strongest pass keys and if I can just go and forget your, forget your password and then reset your account and access your account.
We also have offer some other SCA factors, S-M-S-O-T-P and as a fallback email, O-T-P-S-M-S-O-T-P is certainly the most prevalent two-factor authentication factor that we leverage. Most people know it are familiar with it. Of course it has security issues that we're familiar with. It has also issues with non received or delayed reception of of SMS and it is very expensive.
I'm, I'm, I was told by our lawyers not to disclose how much we pay for it, but I could retire and be on my yacht instead talking here, email, OTP is frowned upon by regulators for good reason. Even accounts are often compromised, the risk is much higher. Doesn't really prove possession. We also added authenticator apps. Those have a pretty wide acceptance.
They're much cheaper for us than than SMSI personally don't like them much because in particular on the native phone because you always have to switch to the authenticator app, copy the code, go back, enter it, and hopefully the, the mobile, the platform providers such as Apple or Google could make this a little bit easier.
That like for S-M-S-O-T-P where it's pre-filled, I, I'd like to see that more. I'm sure it's, it'll come. That's another o option we have as well as device binding.
So where we have a challenge response on the device, it has lower user friction because it's, it's transparent to the user. They don't see that SEA is actually happening. So we like it quite a bit and it is obviously cheaper than SMS. Now coming to the EIA certificates, that's something that is in my opinion a little bit un unfortunate in the regulation, is the regulation is targeted to banks. We are not a bank, we're e-commerce company that just happened to be co covered by this regulation. And so we need to expose certain APIs for these regulated third party providers.
This is basically was the intention I believe of the regulation in this part was to reduce scraping when you, before there were third party providers that connect to multiple banks and would show all your, your different bank accounts in one place and you can see, you know, your transactions and maybe have a, do a wire transfer from one of your three bank accounts.
And to avoid, to avoid scraping, they would add these APIs and require access via e ida certificates.
For us, it doesn't really match this, this business model. So we don't really have an interest in those. We don't have any ETPs that I'm aware of, but we still had to implement a huge, you know, thing about, around accepting those qua certificates as well as letting them enable app register apps via dynamic client registration. We also added, and this is the final slide here are the digital signatures.
Some, some of our API non-regulated APIs that would provide some integrity on the payload that is being sent so that it's a sick digital signature. On the HTT P payload, we're leveraging two new ITF standards. They've just been published a few months ago where essentially we let the one time the developer downloads a private and public key and then every time they make an API call to these APIs, then they sign the the HT TP content and, and put it in a header. And we have various SDKs for standard languages such as Java that summarizes this my talk. Do you have any questions?
Thank you, Laurie. I'll just borrow up for a sec.
Thanks. Thank you. One question about using passkey for a ca I was just talking to someone from one of the large payment networks and they were basically of the opinion that you could not use passkey simply for the reasons you stated that they're synced. So what you're saying is you're, you know, hoping it's better to apologize than ask, ask for permission. Is that what you Yeah.
Okay, cool.
