An app-based authentication request tells the issuer a great deal about the device. It also carries 3DS app provenance, meaning information about the app the transaction came from, and this part goes almost entirely unused.<\/p>\n
Specifically, it can tell you where the app was installed from. A merchant app obtained through the official store on its platform is a different proposition from one sideloaded onto a device, and the difference is available to your risk model if you look for it.<\/p>\n
For issuers running app-based traffic, this is a low-cost input that most ACS platforms currently discard.<\/p>\n
For a transaction initiated from a mobile device, the ACS receives the app store from which the requestor app was loaded, as part of the device information.<\/p>\n
The mechanism differs by platform because the platforms expose it differently. On iOS, elements within the app bundle indicate whether the app was obtained and installed from the App Store. On Android, an element reporting the installer package name identifies the Google Play Store as the source from which the package was loaded.<\/p>\n
EMVCo’s guidance on what to do with it is short and useful. The ACS should verify whether the app store is a trusted source for the requestor app in its market, and use that information in its risk assessment.<\/p>\n
The phrase in its market is doing real work. Which stores are legitimate distribution channels varies by region, and an issuer operating in a market where an alternative store is the normal route for a large share of legitimate apps should not treat it the way an issuer in a market where it is not would.<\/p>\n
There is a companion verification available in the same data, and it is arguably more interesting.<\/p>\n
The ACS can verify that the SDK app identifier and SDK reference number supplied in the authentication request are the same as those provided in the SDK device information.<\/p>\n
Consider why that comparison is meaningful. The device information is encrypted by the SDK using the Directory Server public key, forwarded by the 3DS Server without being readable, and decrypted by the Directory Server. The values in the authentication request travel in the clear through the requestor environment and the 3DS Server.<\/p>\n
So you are comparing a value that passed through intermediaries against the same value that did not. A mismatch is a genuine integrity signal rather than a data quality nuisance.<\/p>\n
The same principle underpins a related check EMVCo recommends at the Directory Server. The SDK transaction identifier can appear up to three times in an app-based authentication request: supplied by the 3DS Server, inside the encrypted device data generated by the SDK, and inside signed content generated by a Split-SDK where one is in use. Its presence in the encrypted and signed content is specifically to prevent replay attacks, and EMVCo strongly recommends the Directory Server verify that the value is the same in all three places.<\/p>\n
Be careful about how much weight this carries, because it is easy to overread.<\/p>\n
Store provenance tells you where an app was installed from. It does not tell you that the app is unmodified, that the device is not compromised, or that the cardholder is genuine. An app installed from an official store on a fully compromised device still reports an official store.<\/p>\n
It is also worth knowing where the boundary of the specification sits. The requirement that the 3DS Server ensure the SDK is authentic exists, but how that is done, and which party does it, depends on the integration model chosen for the components in the requestor environment. The actual method is outside the scope of the Core Specification. In one possible model a 3DS Server outsources the verification to the requestor, assuming it has a way to trust the requestor and the relationship between the requestor and the SDK, and other models are equally possible.<\/p>\n
So SDK authenticity is a distributed responsibility with no single prescribed mechanism, and provenance data at the ACS is one signal within that, not a substitute for it.<\/p>\n
Three practical points.<\/p>\n
Treat it as a risk input, not a rule.<\/strong> A non-store installation is a signal that should shift a score, not a condition that should decline a transaction. Legitimate enterprise distribution, developer builds and regional store differences all produce non-standard provenance for entirely ordinary reasons.<\/p>\n Calibrate per market.<\/strong> Build the trusted-source judgement per market rather than globally. This is the one piece of explicit EMVCo guidance attached to the feature and it is the piece most likely to be skipped in a global implementation.<\/p>\n Log the identifier comparison outcomes.<\/strong> Even if you do not act on mismatches immediately, recording them gives you a baseline. A mismatch rate that is stable and low is background noise. A mismatch rate that moves is worth investigating, and you cannot detect movement you never measured.<\/p>\n App-based authentication generally produces better outcomes than the browser channel, which means issuers are increasingly inclined to trust app traffic. That trust is largely justified by the richer device data the SDK provides.<\/p>\n It is worth remembering what that trust rests on. The security model depends on device data being collected by a genuine SDK, encrypted to the Directory Server, and unreadable by the requestor. Provenance and identifier checks are among the few signals available to an ACS about whether the chain that produced the data was what it appears to be.<\/p>\n Using them is cheap. Not using them means extending trust to app traffic on the basis of data whose origin you have chosen not to examine.<\/p>\n How does the ACS learn which app store the app came from?<\/strong><\/p>\n Through the device information. On iOS, elements within the app bundle indicate whether the app was obtained and installed from the App Store. On Android, an element reporting the installer package name identifies the store from which the package was loaded.<\/p>\n Should a non-store installation be declined?<\/strong><\/p>\n No. EMVCo’s guidance is that the ACS should verify whether the store is a trusted source for the requestor app in its market and use that in risk assessment. Enterprise distribution, developer builds and regional differences all produce non-standard provenance legitimately, so treat it as a score input rather than a rule.<\/p>\n What does comparing the SDK identifiers actually tell us?<\/strong><\/p>\n It compares a value that travelled through the requestor environment and the 3DS Server in the clear against the same value inside the device data that the SDK encrypted to the Directory Server. Because the second path is not readable by intermediaries, a mismatch is an integrity signal rather than a formatting problem.<\/p>\n Whose job is it to verify the SDK is authentic?<\/strong><\/p>\n The requirement sits on the 3DS Server, but how it is met and who does what depends on the integration model chosen for the components in the requestor environment, and the method is outside the scope of the Core Specification. One model has the 3DS Server outsource verification to the requestor; others are equally possible.<\/p>\n Reviewing your ACS risk inputs?<\/strong> ActiveAccess<\/a> is the GPayments Access Control Server solution for issuers and processing centres. Speak with a 3DS specialist<\/a> about app-based risk assessment.<\/p>\n\n\n\n\n","protected":false},"excerpt":{"rendered":" An app-based authentication request tells the issuer a great deal about the device. It also carries 3DS app provenance, meaning information about the app the transaction came from, and this part goes almost entirely unused. Specifically, it can tell you where the app was installed from. A merchant app obtained through the official store on […]<\/p>\n","protected":false},"author":13,"featured_media":3113,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[2],"tags":[19,37],"class_list":["post-3102","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article","tag-3d-secure","tag-acs"],"aioseo_notices":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/comments?post=3102"}],"version-history":[{"count":2,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3102\/revisions"}],"predecessor-version":[{"id":3104,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/3102\/revisions\/3104"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media\/3113"}],"wp:attachment":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media?parent=3102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/categories?post=3102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/tags?post=3102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Why this matters more than it used to<\/strong><\/h2>\n
Frequently Asked Questions<\/strong><\/h2>\n