cAPI - mSIGNIA

A New Framework… a Client API and Universal SDKs

There is a convergence occurring between payment, identity, and privacy technology standards which is causing industry confusion, delaying adoption, and damaging the consumer experience.

Ultimately, the various efforts shown in mSIGNIA’s defined Innovation Arc will yield a Secure Connected Commerce (SCC) experience which unifies safe, easy, private, multi-factor authenticated payments using the same methods whether the transaction is done face-to-face or remote.

However, today’s goal of a frictionless consumer experience is being lost as the chaotic, ad hoc rollouts of EMV 3-D Secure (3DS), PSD2 Strong Consumer Authentication (SCA, which includes behavioral biometrics and dynamic device identifiers), FIDO, and EMV Secure Remote Commerce (SRC) are being brought to market.

Consumers conducting online payments in markets requiring strong authentication (i.e., Europe, India, and others) are being challenged to provide additional data after they emotionally buy the product by hitting the ‘Buy’ button in 98% of transactions!

In the following pages, mSIGNIA offers our current implementation of a Client API (cAPI) and Universal SDK (uSDK) functionality as an initial candidate for industry standardization.

mSIGNIA originally submitted a client API (or cAPI) proposal for standardization to EMVCo, W3C, and FIDO in May 2021.

mSIGNIA can demonstrate our operational system to interested parties. While much of the design is patent pending protected by mSIGNIA, should such a cAPI + uSDK standard be created, mSIGNIA would work to donate this IP to the appropriate standards organization.

For Merchants, Easy Integration using a Single Client API and Universal SDKs

Merchants are being instructed to adopt 3DS, and use 3DS for SCA compliance, but for SCA compliant authentication, a 2^nd factor (such as FIDO or behavioral biometrics) must be added to any existing device recognition solution (such as Threatmetrix-style device IDs or text verification).

Merchants are caught in an integration battleground where they may be required to integrate five (repeat… 5!) SDKs into their browser and mobile app experiences, specifically SDKs for 3DS, device recognition, behavioral biometrics, FIDO, and SRC. A merchant might even need to consider more SDKs for tokenization and QR Code payments! The result is bloated online storefronts that are difficult to manage and update.

Whatever the ultimate SDK count is, the problem is multiplied because a merchant must perform vastly different integrations for 3DS data exchanges with browser and mobile app transactions.

The industry is trying to resolve the issues of a poor user experience and complex integration, but the solutions come with their own problems:

The next 3DS version 2.3 is expected to unify browser and app integrations and address the related problem of 3^rd Party data blocking by browsers… but current EMV 3DS plans include doubling the number of certified SDKs from 4 to 8
3DS’s Delegated Authentication enabled merchants to engage Trusted Third Parties (TTPs) to score risk as part of the transaction, not as an interruption later… but the TTP interface and liability shift rules are vague

Unfortunately for the consumers and industry, often the merchant’s response is “analysis paralysis” … doing nothing!

Merchants require easy integration that enables frictionless consumer payment experiences for browser and app transactions that are compliant with 3DS and SCA.

The integration must include a migration path which embraces new standards and subsequent versions without causing unnecessary re-integrations.

To achieve these industry requirements, mSIGNIA has proposed a Client API (cAPI) and Universal SDK (uSDK) standard to groups like EMVCo 3DS, FIDO, and W3C. cAPI + uSDKs allow various web protocols to specify the client and user data I/O the protocols require, not to certify specific SDKs that performs these tasks. A cAPI standard abstracts the diversity and complexity of client capability from the related ‘cloud’ standards protocols.

Since all SDKs use the same system resources to gather data – iFrames, app permissions, etc. – the 5+ SDKs perform the same, fundamental services regardless of the client. A cAPI + uSDK standard can certify an SDK’s ability to:

Extend a consistent interface and data experience by leveraging native device capabilities and augmenting functionality as required.

Collect USER input including user interface actions, data input, and biometric capture.
Collect DEVICE data typically used for authentication of the device
Perform device functionality including network transfer, storage, digital ciphering, key generation, etc.

As the diagram to the right shows, a single uSDK integrated by a client provider (such as a merchant) could process data I/O requests for multiple standards (3DS, Delegated Authenticators, FIDO, Behavioral biometrics, W3C, SCA, Device IDs like Threatmetrix, SRC …).

As the diagram also shows, Trusted Third Parties (TTPs such as the Issuer, Delegated Authenticators, FIDO reliant parties, etc.) can interface with cAPI to request additional data and functionality from the same uSDKs. By pre-declaring risk data needs that satisfy SCA, etc., iFrame callouts and challenges become unnecessary except for extraordinary risk situations where only additional data (and friction) would yield a transaction approval.

As the diagram below shows, cAPI Instructions create a single, consistent, ‘frictionless flow’ data exchange process for both the merchant implementation and the TTP data collection; the same process is used for both browser and app-based transactions.

Merchants can also interface with cAPI to

Transparently view and ultimately manage the availability and privacy compliance of cAPI data instructions TTPs are requesting of the merchant’s consumers
Enable payment orchestration such as rules regarding the choice between credit and debit processing.

Read on for cAPI + uSDK benefits with Trusted Third Parties or explore more mSIGNIA differences here.

For Trusted 3rd Parties, a Single Client API Interface for Data

Trusted Third Parties (TTPs such as Issuers, Delegated Authenticators, FIDO Reliant Parties, Risk Engines, and even some Merchants) require the ability to assess risk data using enhanced, next-generation capabilities (i.e., Biometrics, FIDO, etc.) while maintaining compliance without disrupting the consumer experience.

mSIGNIA has designed a Client API (cAPI) and Universal SDK (uSDK) system which allows TTPs to request specific client functionality for better data and improved risk scoring.

As the 3DS example diagram to the right shows, cAPI Instructions can be passed by either a 3DS issuer or delegated authenticator to both browser and app clients.

Issuers pass cAPI Instructions in EMV 3DS compliant extensions to the 3DS ARes/AReq protocol.

Delegated Authenticators can pass the same instructions through a cAPI web API.

In today’s EMV 3DS version 2.2, there are certified SDKs for iOS and Android; there is no certified SDK for Browsers. The next version of EMV 3DS available in 2022 changes this and includes a certified Browser SDK. mSIGNIA already offers TTPs a Browser uSDK which is capable of processing the cAPI Instructions that yield enhanced data. This Browser uSDK replaces the 3DS Method issuers have been required to provide in the past.

When merchants use the EMV 3DS Browser SDK, the same cAPI functionality enables data written in a browser transaction to be processed as 1^st Party writing (i.e., done within the merchant’s web origin). 1^st Party written data is not subject to blocking by new browsers as 3^rd Party written data is.

With either browser or app transactions, any TTP can use a single method – a set of extensible cAPI Instructions – for accessing enhanced data and functionality. In either case, the uSDK collects the 3DS specified data plus any data defined by the cAPI Instructions.

User actions (like biometric capture or knowledge-based input) and data are processed as part of the buy sequence, not as a later step-up such as a challenge or OOB. This allows the 3DS spec and custom data to be passed in the initial frictionless flow so more transactions are approved and related efforts like SCA and FIDO can be accomplished without user interruption. Ultimately, better data exchange approves more transactions and reduces cart abandonment.

cAPI Instructions are one of the cAPI + uSDK protocols, detailed here. The genesis of the cAPI instructions was to enable PSD2 SCA compliance over EMV 3DS data exchanges without requiring a step-up interruption. So, the current instruction format and design are influenced by SCA and 3DS, as shown below.

A more generalized specification for cAPI Instructions could transmit cAPI data in HTTP headers to be even more protocol agnostic than the current 3DS “message extension” format.

The following table provides an overview of twelve (12) cAPI data and functionality instructions. Click here to schedule a demo and review a more detailed proposed cAPI instruction specification.

Read on for cAPI + uSDK protocol standardization efforts or explore more mSIGNIA differences here.

The Proposal: a Client API +Universal SDKs for Independent Data Collection

In mSIGNIA’s proposal, shown in the diagram to the right, cAPI is a network endpoint which creates an abstraction between

Various network protocols (i.e., 3DS, FIDO, W3C, SRC, etc.), cAPI can unpack and package data exchanges according to protocol formats
Various client endpoint devices, each client operates uSDK code which leverages functionality native to the endpoint and augments / encodes other functionality to satisfy cAPI requirements including client data collection and user input.Ultimately, the client concept expands to include the Internet of Things.

An industry standard cAPI / uSDK architecture…

Presents a single, consistent data exchange between various network protocol ecosystems and the abstract definition of client
Enables various network protocols to leverage the same, single uSDK to satisfy their client requirements
Enables TTPs (such as Issuers, Delegated Authenticators, FIDO Reliant Parties, and Risk Engines) to request data they require as part of initial transaction
- Virtually eliminating step-ups, step-ups would only be necessary when secondary auth and increased friction are required due to transaction risk… not SCA compliance
Enables Payment Orchestration so merchants can control decisions like Credit/Debit processing
Promotes data transparency
- Merchants know what data is being collected
- All parties (merchants, acquirers, issuers, TTPs) can enforce international privacy regulations

Overall, the cAPI / uSDK architecture requires five (5) interfaces to be standardized, these are described below:

@Server

① Merchant portal into consumer, device, auth, and transaction data exchange; enables payment orchestration by presenting the data collected from the client. Data includes a concept of ownership so that TTP provided data (such as a device identifier or token) is declared but not shown to the merchant. Data not specifically provided by the TTP is visible to the merchant since it is the collected from within the merchant context. Data specifically from the device (i.e., such as a device fingerprint) can be signed so that it can be trusted by merchants and TTPs.

② Instructions that merchants and TTPs can use to request risk data within protocol exchanges. This enhanced data collection yields more frictionlessly approved transactions and fewer step-ups. In particular, enhanced data eliminates the step-up interruptions required for SCA and FIDO compliance. See the cAPI Instruction table for details on data instructions.

Server <> Consumer Device

③ The API between the network and endpoint clients. This protocol and exchange are internal to the cAPI/uSDK system; merchants and TTPs do not need to process or understand this API. This hides the complexity of a single cAPI communicating with multiple, diverse clients from the reliant system. Protocol complexities such as HTML exchanges, app constructs, and unique device requirements are contained within. In addition, client capabilities (i.e., secure memory, display, UI, biometrics sensors, etc.), integrity (i.e., OS version, debugger/emulator detection, etc.), and secure communication are established within and benefit the reliant system.

④ Since data requirements of any TTP can be collected via a set of extensible instructions (interface ② above), virtually all step-ups are eliminated. Only extraordinary risk situations where secondary data (and friction) are required to yield a transaction approval would require a step-up. This interface design should focus on functionality and native client support, not aesthetics. Thus, the near universal availability of HTML makes HTML the most useful format.

@Consumer Device

⑤ A single API between the merchant’s storefront client and the SDK regardless of the physical client. This simplicity reduces the effort a merchant must exert to support multiple client types. uSDKs themselves must universally process data and functionality needs such that only a single uSDK is required for various protocols. Otherwise, a merchant might need to implement 5 or more SDKs (i.e., 3DS, SCA (device ID like Threatmetrix + Behavioral Biometrics like BehavioSec, FIDO, and soon SRC). uSDKs must store data with various owners at the client and could also enforce international data privacy regulations.

As FIDO has defined data I/O and added declaration regarding the quality of data collected (i.e., biometric sensor ‘ratings’), FIDO seems more advanced than 3DS in managing client functionality and is likely a strong candidate to lead cAPI standardization… coordinated via W3C/EMVCo but possibly driven by FIDO, especially with app-based exchanges on devices where physical biometric sensors are most prevalent.

See cAPI + uSDK benefits for merchants and Trusted Third Parties or explore more mSIGNIA differences here.