3DS Authentication Protocol

When people hear 3DS, they usually think something about going to a movie and watching a new experience. The 3DS secure authentication protocol is rather a way to help merchants prevent fraud. In this video, we are going to:

  • Review the 3DS authentication protocol
  • What it is
  • How it works, and
  • What it does to help prevent fraud

Hi, I'm Sully Perella, a manager here at Schellman, and we're going to talk about the 3DS authentication protocol. So, 3DS applies to the card-not-present transactions. Think about what you're doing when you make a transaction online or with your mobile phone.

And this is you, our good friend, the nesting doll. When that transaction is made. There are details about the transaction itself and metadata from your system or mobile phone, which are going to be sent to this first step.

Now, let's take a pause here. We've got the 3DS server, the 3DS directory server, and the access control server. Often managed by different organizations, each of these has a separate function. This system is going to make sure that the correct elements were collected as a part of that transaction. These two systems are going to perform mutual authentication between them. So that when the data is exchanged, this system trusts this one and vice versa. This system is going to the directory server is going to route your authentication to the correct issuer because you've got to know who you're talking to here. And then the access control server is usually often referred to as the issuer domain. This is the environment that the cardholder has a relationship with.

So let's put this together in a generalized transaction. You want to purchase some new pants, so that transaction goes in. This is you at home on your mobile phone. That data, the metadata about the transaction, including your card number, is going to get sent to the 3DSS (I hope you like acronyms, there's more coming).

That data, mutual authentication to the directory server it's going to say: OK, now that I've got the correct data, I'm going to send you to this intermediary. This intermediary organization is going to say; are you part of the 3DS authentication protocol?

The 3D directory server is going to then route your data to the appropriate issuer. Everyone has a different issuer. And so you want to make sure that goes to the right place because they're the ones who are going to make risk decisions based upon that information. So that information gets handled to the access control server. The access control server, often managed by the issuer but can be done by a third party, is going to do essentially a risk analysis on this transaction. Looking at that metadata where you are, what time of day it is, maybe we're going to look a little deeper, how often you make online transactions, what is the cost of that transaction? Regardless of how far we go down that rabbit hole, the threat tolerance is going to be unique to the issuer when the risk tolerance is met, meaning that they feel that it is not a risky transaction. Then data goes back to where you are confirming that transaction.

If, however, the access control server says, I don't know if this really is who I think it is, I'm going to send back a challenge and that challenge is going to go all the way back to. At this point, you will be able to enter a pin answer question or whatever other authentication value you have established with your card issuer. Upon verification of that data, the transaction will be complete. And if it's not there, the transaction fails. Helping to prevent fraud. It is apparent that all of these data elements help prevent fraud for card-not-present transactions.

There's a lot going on here. There's a lot of data elements that are being handled. There's a lot of secure mutual authentication occurring between these data elements to protect the things that are essentially: you.

Do you have questions about 3DS, how it works, how it pertains to your organization, or how your organization can benefit from the fraud prevention services with the 3DS authentication protocol? Reach out to us, we'd love to answer those questions. 

About the Author

Sully Perella

Sully Perella is a manager at Schellman who leads the PIN and P2PE service lines. His focus also includes the Software Security Framework and 3-Domain Secure services. Having previously served as a networking, switching, computer systems, and cryptological operations technician in the Air Force, Sully now maintains multiple certifications within the payments space. Active within the payments community, he helps draft new payments standards and speaks globally on payment security.

More Content by Sully Perella
Previous Video
Risk Assessment and Threat Analysis in SSF
Risk Assessment and Threat Analysis in SSF

Next Video
The Cost of an EU Cloud Code of Conduct Assessment
The Cost of an EU Cloud Code of Conduct Assessment