InfoCard and e-Commerce

-= Introduction =-

This document describes a scheme to enhance Internet and mobile commerce using a new Identity Metasystem proposed by Microsoft, called InfoCards. This scheme builds on the existing 3-D Secure e-commerce scheme developed by Visa and adopted by MasterCard, Visa, and JCB.

The existing 3-D Secure scheme is implemented in the worldwide payment networks. However the adoption by merchants, consumers, and issuers has been low. The proposed scheme requires little modification to the existing 3-D Secure scheme, but could provide enhanced security, reduced fraud, and an improved consumer e-commerce shopping experience. Most importantly, it could result in greater adoption by merchants and consumers, and thus, issuers.

The sections below review the 3-D Secure scheme, the planned first use of InfoCards for authentication, and then the proposed use of InfoCards for e-commerce. Finally, a summary section lists the changes and resulting benefits. If a reader is familiar with either 3-D Secure or InfoCard, these sections may be skipped.

-= 3-D Secure =-

Overview

The 3-D Secure e-commerce payment scheme was developed by Visa as a second generation version to the Secure Electronic Transaction (SET) scheme. 3-D Secure is offered by Visa as Verified by Visa, by MasterCard as SecureCode and by JCB as J/Secure.

3-D Secure derives its name from the three domains in the scheme: the Issuer domain, the Acquirer domain, and the Interoperability domain. The payment card issuers are the issuer domain. The merchant and their acquiring financial institution are the acquiring domain. The interoperability domain is provided by the payment card industry associations, including MasterCard, Visa, and JCB.

The scheme works as follows. A cardholder signs up for the scheme at the card issuer’s Web site. Then when the consumer is checking out at an e-commerce site and has entered their payment details, such as card number, expiration date, and card verification value, they can engage in a 3-D Secure transaction if the merchant supports it. The merchant uses the card number to look up in the interoperability domain the Web site address of the issuer’s Access Control Server and redirects the consumer’s Web browser to it, along with encoded transaction details. The Access Control Server shows the consumer a secret that only the two of them should know, and then it asks the consumer to authenticate. If this is successful, the issuer redirects the consumer’s Web browser back to the merchant site, appending a cryptogram that the merchant can attach to the payment transaction data sent into the network.

The merchant is incented to offer this service by a lower merchant interchange rate on the payment and a shift in chargeback risk from the merchant to the issuer. The consumer is presumably incented by a feeling of higher security and possibly specific incentives offered by the issuer. The issuer is incented by a lower card and merchant fraud loss.

Unfortunately, like its SET predecessor, 3-D Secure has seen very low adoption rates in the years since it went live.

Components

3-D Secure is implemented in four components.

Merchant Plug-In

The merchant plug-in is installed in the shopping cart software used by the merchant. It is invoked when a consumer submits their payment details to the merchant site. The plug-in handles all the details of interacting with the interoperability domain and the issuer domain. It returns a status indicating what happened, and if a successful 3-D Secure authentication resulted, a cryptogram, the payment response, that the merchant can use when sending the transaction payment details to the acquirer’s payment interface.

As part of interacting with the issuer’s Access Control Server, the merchant plug-in passes transaction details such as ID and amount in the redirect. These are passed in a payment request structure. This allows the Access Control Server to record the transaction details before generating the payment response cryptogram.

Interoperability Domain

The interoperability domain interacts with the merchant plug-in to determine whether a given card number might participate in 3-D Secure and to direct the plug-in to the issuer’s Access Control Server.

Issuer Access Control Server

The issuer’s Access Control Server interacts with the merchant plug-in to validate whether a given card number is participating in 3-D Secure, and if so to present an issuer authentication page to the consumer and to authenticate the consumer. In all cases, it returns a status back to the merchant plug-in and a payment response cryptogram if a successful 3-D Secure authentication occurred.

Payment Networks

The payment networks enhanced their message formats to include transaction type codes for 3-D Secure and to carry the payment response cryptogram. The online payment authorization system at the issuer was enhanced to validate that the payment response cryptogram was generated by the Access Control Server and that the transaction details match the ones asserted in the payment request at the time of the consumer authentication.

Transaction Flow

http://partnernetwork.visa.com/pf/3dsec/download/trk_3dsec_intro_v102.pdf

The consumer enters their payment details in the merchant Web site’s checkout page and clicks “Submit”.

The merchant checkout page invokes the merchant plug-in software with the transaction details and the payment details.

The merchant plug-in checks with the interoperability domain to see if this card might participate in 3-D Secure. If not, it returns a status to the checkout page indicating that 3-D Secure is not possible. Otherwise, the merchant plug-in is returned the URL of the issuer’s Access Control Server. The merchant plug-in then creates a payment request message, appends it as a query to the URL, and redirects the consumer’s browser to the Access Control Server.

The Access Control Server checks to see if this particular card number is enabled for 3-D Secure. If not, it returns the consumer back to the merchant plug-in with the appropriate status appended to the return URL, which likewise returns the status to the merchant checkout page. Otherwise, it displays a page with a secret previously agreed upon when the consumer enrolled for 3-D Secure at the issuer’s Web site. The consumer views this to be assured that they are actually interacting with the issuer. If not, they can cancel the transaction and return to the merchant site. Otherwise, the consumer enters their authentication data, such as a password or one-time password token value. The Access Control Server then validates this. If invalid, they will offer one or more retries. If the authentication still fails, it returns the consumer back to the merchant plug-in with the appropriate status appended to the return URL, which likewise returns the status to the merchant checkout page. Otherwise, it generates a payment response cryptogram and returns the consumer back to the merchant plug-in, appending the payment response cryptogram to the return URL.

The merchant checkout page uses the returned status and cryptogram in formatting a payment authorization request to the payment interface on their acquirer’s system.

Security Concepts

3-D Secure has many security features. The scheme grew out of SET, but attempts to strike a better balance between security and ease of use.

The interactions between the merchant plug-in and the interoperability domain are all protected using public key cryptography. Likewise, the payment response cryptogram is encrypted. Merchant fraud is eliminated, because the merchant cannot forge the payment response.

The use of the shared secret on the issuer’s Access Control Server is designed to avoid spoofing of the issuer to the consumer by a fraudster. Likewise, the use of an issuer specified authentication method to authenticate the consumer assures the issuer that it is really the cardholder performing the transaction.

Business Concepts

Any payment scheme affects five stakeholders: the consumer, the merchant, the acquirer, the network and the issuer.

The consumer benefits from an increased feeling of security when performing e-commerce transactions. The issuer or the merchant could offer financial incentives, although in practice, this has not been common.

The merchant benefits from a lower merchant interchange rate and a shift of the risk of a chargeback (a disputed charge) from the merchant to the issuer. Additionally, if consumers feel more secure, they may be inclined to shop more and spend more per transaction.

The acquirer benefits primarily through a potential for an increased transaction volume. The acquirer had to make only minor changes to accept the payment response, so they don’t need much incentive. At any rate, they must conform to card association mandates.

The network benefit is identical to the acquirer’s.

The issuer benefits from reduced card and merchant fraud. Additionally, if consumers feel more secure, they may be inclined to shop more and spend more per transaction.

This scheme is not freely available. It is intellectual property owned by Visa and licensed to other card associations.

Problems with Adoption

The uptake of 3-D Secure has been very low, reportedly on the order of a few percent.

Other methods still accepted

The card associations did not make 3-D Secure universal to all payment cards, nor did they mandate it for all e-commerce for a given card brand. As a result, merchants still needed to accept traditional card details, without any 3-D Secure validation and authentication.

Poor merchant adoption

Some large Internet merchants reportedly felt that their fraud losses were under control, and they did not want to want any more clicks and pages during the checkout process, to avoid shopping chart abandonment.

Smaller merchants were faced with implementing the merchant plug-in, a potentially difficult and expensive project, for an uncertain return. They, too, were concerned about the extra steps involved in checkout.

Poor issuer adoption

Issuers needed to implement an Access Control Server, or outsource it to a service provider. If implemented by the issuer, this was a major consumer-facing server, with stringent security requirements. If outsourced, the issuer must release their entire cardholder database to an outside firm, with potential privacy, security, and asset loss risks.

Poor consumer adoption

Consumers got no benefit except the possibility of an increased feeling of security. Many experienced on-line shoppers might have already felt secure enough, and did not want to go through the inconvenience of enrolling and using the service at checkout. The rollout at the issuers was uncoordinated and lacked enthusiasm.

-= InfoCards for Authentication =-

Overview

InfoCards are an authentication scheme developed by Microsoft, as a part of vision they have called the Identity Metasystem. http://www.identityblog.com/?page_id=355 The protocols used in the scheme are public and any Identity Provider and Relying Party may participate. In fact, no Microsoft software or involvement is required, although Microsoft is implementing a key user component: an Identity Selector, called CardSpace, for release in Windows Vista, Windows XP, and Windows Server 2003.

InfoCards are issued by Identity Providers to Subjects, such as consumers. Subjects install these on their local device, such as a PC, a phone, or a set-top box, by importing them into a card store maintained by an Identity Selector.

Relying parties can request that the Subject authenticate using an InfoCard. The Relying Party requests one or more signed claims about the Subject, from an Identity Provider that it trusts. The user interface will then launch the Identity Selector. The Identity Selector informs the Subject of the request by the Relying Party and allows them to select an InfoCard. The Identity Selector then uses the information in the InfoCard to allow the user to authenticate to the associated Identity Provider. The Identity Provider returns a security token that is returned to the Relying Party to authenticate the user.

For a technical in-depth discussion of integrating with InfoCard, see “A Guide to Integrating with InfoCard v1.0”, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/infocardwebguide.asp

Components

The InfoCard scheme is implemented in five components.

Subject

The Subject is a human user. They have a relationship with an Identity Provider, such that the Identity Provider can make certain claims, or attributes about the Subject to relying parties. The Subject has a relationship with a Relying Party such that the Relying Party needs certain claims made by that Subject, their identity to that Relying Party.

Identity Provider

The Identity Provider has a relationship with a Subject. The Subject enrolls at the Identity Provider, establishes some shared secret for authentication, asserts some claims that the Identity Provider will vouch for, such as name, address, telephone number, and email address, and receives an InfoCard, which is an textual XML document containing a unique identifier and information to assist an Identity Selector in processing a card.

The Identity Provider provides a service interface that can be accessed by an Identity Selector.

The Identity Provider may be a self-asserted provider. This is a provider local to the Subject’s device. Its only capability is the ability to prove cryptographically that it is the same provider every time it is accessed. That is, the self-asserted provider possesses a cryptographic secret and can prove it on demand. Thus a Relying Party can be sure that the Subject is the same Subject each time the Subject accesses the Relying Party. This functions identically to the common self-assertion of a user ID and password by a Subject to a Relying Party.

Relying Party

The Relying Party is an application that needs to authenticate a Subject by receiving claims from a trusted third party.

The trusted third party may be a self-asserted Identity Provider that is assumed to be under exclusive control of the Subject. As the Relying Party builds a relationship with the Subject, the self-asserted Identity Provider may be used repeatedly to authenticate that the Subject is the same person each time.

The trusted third party may be an actual external Identity Provider that the Relying Party trusts. This may also be used in a self-asserted role, or the claims provided by the identity party may be trusted explicitly if the Identity Provider is already known and trusted by the Relying Party.

InfoCard

An InfoCard is an XML document. It has a unique identifier, data for access to the Identity Provider, a list of claims that the Identity Provider can supply, a list of accepted Subject authentication methods and a list of security token types that the Identity Provider can supply. The InfoCard is signed with a private digital signing key owned by the Identity Provider.

The InfoCard is provided by the Identity Provider to the Subject and is used by the Identity Selector during authentication.

Identity Selector

The Identity Selector is a device local subsystem that interacts with a user (Subject) to store InfoCards, to allow the selection of one during an authentication operation, and to convey Subject authentication data to the Identity Provider. The Identity Selector is activated when a Relying Party needs identity claims, and mediates between the Relying Party, Subject, and Identity Provider.

The Identity Selector will keep a secure list of which InfoCards a Subject has used with which relying parties. This will assist the Subject in assuring themselves on repeated visits to the Relying Party that the Subject is interacting with the expected Relying Party.

Transaction Flow

Enrollment with the Identity Provider

The Subject accesses an Identity Provider and presents security tokens or credentials to identify themselves. This may range from nothing more that access from a user account to a local self-asserted provider, to a physical world credential such as a driver’s license or birth certificate, to a complex financial history vouched for by a financial institution or a credit bureau. The Subject and the Identity Provider agree to a set of claims about the Subject. There may range from self-asserted claims such as email address or phone number, to highly accredited claims such as a bank account number or a reputation, such as above a legal drinking age, or credit worthiness.

As a final set, the Identity Provider generates an InfoCard for the Subject and delivers it to them, either via physical media such as a smartcard or USB token, or via download through a secure channel to their device.

Usually, an Identity Selector will allow the Subject to copy the InfoCard into a InfoCard store managed by the Identity Selector. InfoCards are tamperproof and do not contain any secrets themselves, so they do not require secure storage, although an Identity Provider may elect to store them securely.

Access to a Relying Party Resource

The Subject attempts to access a secured resource at the Relying Party. The Relying Party returns a challenge that indicates the kind of security token they require, the claims that they need, and the kind of Identity Provider that they will accept. The Relying Party also provides a signed certificate that indicates the Relying Party’s name, location, and logo.

This activates the Identity Selector. The Identity Selector examines the InfoCards in the InfoCard store and determines which Identity Providers can fulfill these three criteria. The Identity Selector then interacts with the Subject, displaying the Relying Party’s information, the Relying Party’s certificate authority information, and asks the Subject to select the InfoCard that they want to use from the list. If the Subject has used one or more of the InfoCards with this Relying Party before, the Identity Selector should indicate this to the Subject.

The Subject selects an InfoCard to use. The Identity Selector then interacts with Subject to collect the required authentication data, such as user ID and password, or an X.509 certificate, or even a self-asserted identity InfoCard. The Identity Selector connects to the Identity Provider using the security method indicated in the InfoCard, presents the Subject’s authentication over the connection, and receives a signed security token containing the required claims.

The Identity Selector returns the security token to the Relying Party. The Relying Party validates the security token and if valid, grants access to the secure resource.

Security Concepts

User Security

InfoCard satisfies seven laws of identity as presented by Kim Cameron of Microsoft: http://www.identityblog.com/?page_id=354

User Control and Consent:

During authentication, the Subject is presented with information identifying the Relying Party and claims they are requesting. The Subject selects which InfoCard to use. The Subject authenticates to the Identity Provider.

Limited Disclosure for Limited Use:

Each time an InfoCard is used, only the claims requested by the Relying Party for that use are disclosed.

The Law of Fewest Parties:

When an InfoCard is used, only a specific Relying Party, the Subject, and a specific Identity Provider are involved in the interaction.

Directed Identity:

The claims provided to a Relying Party for a Subject by an Identity Provider can be identified by a pseudonym for the Subject, which is unique to that Relying Party and that Identity Provider.

Pluralism of Operators and Technologies:

Any Identity Provider may provide an InfoCard, as long as relying parties will accept it. The security token provided during an authentication interaction need only be understood by the Identity Provider and that Relying Party.

Human Integration:

The Subject is involved in obtaining the InfoCard from the Identity Provider, in selecting an InfoCard to use for a Relying Party, and in providing authentication information to the Identity Provider when using the InfoCard.

Consistent Experience Across Contexts:

Developers of Identity Selectors are encouraged to present the same user interface experience to the Subject as all other Identity Selectors.

Relying Party Security

The Relying Party identifies itself using X.509 certificates that include their name, location, and logo. The security tokens they receive from the Identity Providers presumably contain security tokens proving the identity of the Identity Provider and presumably provide the required level of confidentiality and integrity.

Identity Provider Security

During authentication, the request for a security token provides proof of the validity of the InfoCard and associated Subject, and authentication data to authenticate the Subject.

Identity Selector Security

The Identity Selector must be implemented in a very secure manner on the user’s device, such that the Identity Selector cannot be spoofed or modified, and such that there are trusted display and input paths. This should eventually used trusted hardware, such as provided by Trusted Platform Modules as defined by the Trusted Platform Group.

Business Concepts

InfoCard for authentication is designed to address severe identity problems in using the Internet and wireless phone networks, including phishing and identity theft. They are specifically meant to replace the ubiquitous user ID and password.

Consumer fear

Consumers are becoming increasingly reluctant to engage in secure activities over public networks, especially e-commerce. If InfoCards can provide improved security, improved privacy, and a simpler, standard, more reassuring authentication experience, consumers will increase their trust in using these networks.

Fraud

InfoCards can provide much stronger authentication that currently is commonly possible. If they become widely deployed, they can reduce fraud against secure resources.

Industry support

InfoCard is an open system that is relatively easy to implement, especially for relying parties. If Identity Selectors become available on most devices and most Identity Providers support them, then the Identity Metasystem will become pervasive.

-= InfoCards for E-Commerce =-

InfoCards for e-commerce builds on the 3-D Secure scheme, simplifying it and enhancing it. From the consumer's point of view, this is just another way to use their payment card and just another use of InfoCard.

Overview

InfoCard can simplify the 3D-Scheme by eliminating the need for the backend Internet implementation of the directory, and the complex redirect/authentication mechanism to authenticate the consumer.

The directory is eliminated because issuers can simply issue their cardholders InfoCard version of their credit cards from the issuer’s online banking site. The consumer also enters their shipping addresses on the issuer’s online banking site, so that won’t have to during the checkout at an e-commerce site.

The complex interaction is not only eliminated, but the whole checkout is simplified because the consumer no longer has to enter either payment or shipping information. The consumer simply indicates at the start of checkout that they want to use an InfoCard. The same interaction sequence occurs as for InfoCard authentication, and at the end the Relying Party, the merchant, is returned the 3-D Secure payment response and the shipping address.

Transaction Flow

Issuing the InfoCard

The consumer will go to the issuers online banking site, authenticate as usual and request an InfoCard. The issuer creates an InfoCard unique to this consumer and allows the cardholder to download the InfoCard to their device (PC, phone, or set-top box). The consumer installs the InfoCard in the Identity Selectors InfoCard store.

As noted above, the consumer maintains their shipping information with their account on the issuer’s online banking site. This way, the consumer can change this in one place, and have it take effect for all subsequent purchases.

Checkout at an E-Commerce Site

When checking out, the consumer indicates that they want to use an InfoCard, optionally specifying a nickname for a shipping address. The merchant is now the Relying Party. The site returns a page that activates the Identity Selector, and includes claims for a 3-D Secure payment request token and for shipping data. The merchant indicates the payment schemes accepted by listing multiple identity provider types. The consumer selects an appropriate InfoCard and enters authentication data as required by that issuer’s InfoCard. The Identity Selector interacts with the issuer’s 3-D Secure Access Control Server, obtains a security token with a 3-D Secure payment response token and returns it to the merchant.

The merchant submits a standard payment transaction with the 3-D Secure information to their acquiring bank, receives an authorization, saves this and the shipping information, and presents the consumer the purchase receipt page.

3-D Secure Claims

3-D Secure requires the exchange of a payment request and a payment response between the merchant and the payment provider. The content of these is proprietary to the 3-D Secure protocol, but they include enough merchant, transaction, and card information to allow a secure payment transaction to be performed.

When exchanged via an HTML form, these are compressed and encoded with Base64.

The merchant will include a variable claim in its token request, with the payment request data after the question mark in the claim URI. Likewise, the payment provider will include the payment response data after the question mark in the returned claim URI.

Thus, the merchant token request claim might look as follows

http://visa.com/ThreeDSecure?COMPRESSED AND BASE-64 ENCODED REQUEST HERE

And the payment provider token response claim might look as follows

http://visa.com/ThreeDSecure?COMPRESSED AND BASE-64 ENCODED RESPONSE HERE

Additionally, a claim will need to be defined to indicate the acceptable payment schemes, such as Visa, MasterCard, Amex, etc. This might be done via the accepted Identity Provider claim in a standard InfoCard.

Shipping Detail Claims

The definition of these fields is found in RFC 4112 – ECML v2 Specification.

The merchant token request claims will include only through the question mark. The payment provider will append the actual consumer data values in the token response claims.

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_Name_Prefix?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_Name_First?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_Name_Middle?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_Name_Last?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_Name_Suffix?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_Company?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_Street_Line1?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_Street_Line2?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_Street_Line3?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_City?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_StateProv?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_PostalCode?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Postal_CountryCode?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Telecom_Phone_Number?

urn:ietf:params:ecml:v2.0:Ecom_ShipTo_Online_Email?

A new InfoCard specific shipping address claim could be defined that allows the Relying Party to indicate the consumer’s nickname for a shipping address. The consumer could enter this name in a field on the checkout page, before selecting the InfoCard option. If the field is blank, the default shipping address is returned by the Identity Provider.

CardSpace Claim Processing Changes

In version 1.0 of the Microsoft Identity Selector, CardSpace, there is no support for variable claim data. Since claims are Universal Resource Identifiers (URIs), the ability of URNs to carry query data could easily be used.

The syntax of URIs is defined in RFC 1630. It has three major parts, a scheme, a path, and an optional search (also known as a query. The scheme and path are separated by a colon and the path and search are separated by a question mark. For example:

http://visa.com/ThreeDSecure?COMPRESSED AND BASE-64 ENCODED REQUEST HERE

Scheme: http

Path: //visa.com/ThreeDSecure

Search: COMPRESSED AND BASE-64 ENCODED REQUEST HERE

Currently, CardSpace and other Identity Selectors are expected to match each claim URI in a Relying Party token request exactly with a claim in the claims list of an InfoCard. A simple change to the interior match logic to match claims only up and including the question mark if present would allow search strings to be included in the Relying Party’s claim URIs.

In the request from the selector to the Identity Provider, the complete Relying Party claims, including scheme, path, and search, are copied into the Claims element under the RequestSecurityTokenTemplate element in the RST message sent to the identity party. This is identical to the current selector behavior.

CardSpace Identity Provider Processing Changes

In version 1.0 of the Microsoft Identity Selector, CardSpace, there is no support for the Relying Party to indicate support for multiple identity providers. The WS-Policy only allows a WS-SecurityPolicy for one identity provider. The identity provider may be omitted, indicating any identity provider.

In e-commerce, a given merchant will only accept certain payment providers. For example, they may accept Visa but not MasterCard, or Visa and MasterCard, but not Amex or Discover. The merchant needs a way to indicate to the consumer’s identity selector which payment providers they will accept. The solution to this is to define a standard identity provider URL for each of the providers, such as http://visa.com/ for Visa, http://mastercard.com/ for MasterCard, etc. Then the merchant plug-in can generate WS-SecurityPolicy metadata for each of the payment providers.

Merchant Plug-in Changes

Currently in the 3-D Secure scheme, the merchant plug-in handles all the interactions with the 3-D Secure directory and redirects to the issuer’s Access Control Server.

This would be modified to eliminate the entire directory interactions. The interaction with the Access Control Server would be changed to use the standard InfoCard Relying Party technique.

Additionally, the API to the merchant plug-in would now return shipping information, too, if the issuer returned this in the security token.

Issuer Access Control Server Changes

The issuer’s Access Control Server will be changed to use the standard InfoCard Identity Provider interaction and protocols. Since authentication data is included in the payment data request, no interaction with the consumer is necessary.

The Access Control Server should return a pseudo card number. This number is drawn from a pool of available numbers that are only valid for e-commerce transactions. The numbers will include adequate prefix digits to allow the payment transaction to be routed to the issuer. Use of a pseudo card number protects the identity of the cardholder and prevents the construction of fraudulent magnetic stripe cards.

The Access Control Server will need to have access to the consumer’s shipping data preferences.

Payment Network Changes

No changes are required to the payment network. However the payment card industry may want to define a new transaction type code to distinguish the use of InfoCard.

Ubiquity

The 3-D Secure scheme is a licensed, proprietary scheme. To achieve consumer and merchant adoption, this scheme needs to be supported for all payment types. This could cause rapid adoption by merchants because they will expect most consumers to be able to use, and could cause rapid adoption by consumers because their card issuer will offer it to them.

-= Summary =-

Combining 3-D Secure and InfoCard for e-commerce offers many benefits.

Minor change to 3-D Secure components

Only minor changes to 3-D Secure components are required. Both the merchant plug-in and the Access Control Server become simpler and more secure.

The payment request and payment response tokens are unchanged.

Eliminates directory domain

The entire directory system can be eliminated. All the expense, administrative overhead, and security risk are gone.

No change to the payment networks

The worldwide payment networks require no change. The significant investment and deployment are already complete, thanks to the 3-D Secure implementation.

Improves consumer shopping experience

Fear

Consumers now can have confidence in the security and privacy protections provided by this scheme. They will develop confidence in InfoCard through both the authentication and e-commerce experience. They will see that this security is available everywhere: on PCs, on phones, and on set-top boxes.

One-click check out

Whereas the current 3-D Secure scheme adds additional steps to e-commerce checkout, this InfoCard scheme would reduce the number of steps and amount of data entry. The consumer simply picks an InfoCard and enters their authentication data. Errors in data entry are eliminated.

Reduces card and merchant fraud

The InfoCard e-commerce scheme eliminates the need for merchants to collect payment information and to maintain “wallets” of consumer payment and shipping choices.

Through the use of pseudo card numbers, card fraud is reduced.

Enhances the value of InfoCards

The use of InfoCards to eliminate user ID’s and passwords represents a major step forward in online security. Using the exact same technology to eliminate entering payment details in e-commerce transactions represents a major step forward in e-commerce security, too. Together, they provide a powerful reason for consumer and merchant adoption.

Needs unrestricted IP

The InfoCard authentication scheme is open to all Identity Providers and all relying parties. To achieve universal adoption of InfoCard for e-commerce, the InfoCard scheme should be open to all payment providers and all merchants.