Apple announced a new iOS 18.1 API for iPhone: the NFC & SE Platform, a new framework for in-app NFC transactions using iPhone XS and later Secure Element. The key part of the PR announcement, which was also translated on the Apple Japan site, is the last bit listing conditions and availability:
To incorporate this new solution in their iPhone apps, developers will need to enter into a commercial agreement with Apple, request the NFC and SE entitlement, and pay the associated fees. This ensures that only authorized developers who meet certain industry and regulatory requirements, and commit to Apple’s ongoing security and privacy standards, can access the relevant APIs. The NFC and SE APIs will be available to developers in Australia, Brazil, Canada, Japan, New Zealand, the U.K., and the U.S. in an upcoming developer seed for iOS 18.1, with additional locations to follow. Developers and users will continue to have access to the easy, secure, and private experience of Apple Pay and Wallet.
Notice who’s missing from the lineup? The EU dictated less secure, messy iOS 17.4 Host Card Emulation market, that’s who. ‘How it Works’ details are listed on the Apple developer site, highly recommended reading if you have any interest. The main SE and NFC points:
- NFC transactions. Users of eligible iOS apps can initiate NFC transactions from within the app with compatible NFC terminals.
- Default app settings. Users can choose any eligible app as their default contactless app which will enable the app to support Field-detect and Double-click features.
- Field-detect. The default contactless app automatically launches when a user presents their iPhone to a compatible NFC terminal and after user authentication (if their iPhone is locked).
- Double-click. The default contactless app automatically launches when the user double-clicks the side button (for Face ID devices) or the Home button (for Touch ID) and after user authentication (if the iPhone is locked).
- Support for non-default apps. Eligible apps running in the foreground can prevent the system default contactless app from launching and interfering with the NFC transaction.
In short 3rd party apps can replace Wallet app and get all the Double-click Secure Intent goodness of Apple Pay, and the foreground app gets NFC priority even when another app is set as default. It comes with conditions, an approval process and fees, similar to the previous process for Apple Pay Wallet Secure Element and NFC access. But unlike the previous blackbox process, there is a clear path for developers to obtain and implement NFC entitlement and SE access in their apps. It sounds like fun, but it could be a headache for users when it comes to Wallet app Express Mode. Yes folks, despite all the excitement the potential downside is that we might have to deal with NFC-clash. Let’s take a look at in-App supported transactions broken out by Wallet app Express Mode and non-Express Mode categories:
Double-Click required Non-Express Mode transactions: In-store NFC payments, Event Tickets, Government ID, Loyalty/Reward programs
Wallet App supported Express Mode transactions: Closed-loop transit, Keys (Car Keys, Office Keys, Home Keys, Hotel Keys), Student ID
What’s missing? Right, open-loop transit (OMNY, Transport for London, etc.). Apple developer documentation states: An NFC transaction can be made only after authorization from the Secure Enclave. On iPhone, this involves confirming that the user has authenticated with Face ID, Touch ID, or the device passcode.
There we have it, all in-app NFC transactions require double-click authorization, they don’t get Express Mode which remains a Wallet app exclusive. Good thing because that last thing we need in our ever expanding digital wallet life is dealing with clashing in-app NFC transactions. Can in-app NFC transactions play nice with Express Mode Wallet? Perhaps, Apple outlines something called Presentment Intent Assertion:
You can acquire a presentment intent assertion to suppress the default contactless app when the user expresses an active intent to perform an NFC transaction, like choosing a payment or closed-loop transit credential, or activating the presentment UI. You can only invoke the intent assertion capability when your app is in the foreground.
In order to enable a seamless transaction experience, eligible app developers can prevent the system default contactless app from launching and interfering with contactless transactions.
Does this mean that if the user has a bank app in for the foreground, they can tap in at an OMNY gate using in-app transaction even though Express Transit Mode is turned for the same bank card in Wallet app? It appears so but we’ll have to see how Presentment Intent Assertion pans out in real world use.
Apple Pay-like on-device security without Apple Pay servers
There’s another big difference between Apple Pay Wallet SE transactions and in-app SE transaction: the Apple Pay backend. Apple requires that developers have a robust and secure backend in place for transaction processing, outlined in the developer documentation: the disclosure, processing, and remediation of potential vulnerabilities in your iOS app and back-end NFC & SE Platform related infrastructure. If the developer’s backend infrastructure isn’t up to spec or appears to be compromised in any way, the develop’s secure element applet is deleted by Apple.
Apple Pay servers are limited to initial provisioning of the developer’s secure element applet: On a request from your iOS app running on your user’s iPhone for provisioning a card, the Apple server will download the signed applet corresponding to the card scheme that is requested by the user, create a memory partition on the Secure Element for the card…then pass control to the NFC & SE Platform partner servers for personalizing the card. After provisioning is complete, the developer’s secure element applet and backend does everything else.
DYI Tokenization
The biggest question in my mind is tokenization: as Apple Pay plays no part in the transaction the developer’s secure element applet has to handle tokenization. Documentation states: When the user authorizes a transaction, which includes a physical gesture communicated directly to the Secure Enclave, the Secure Enclave sends signed data about the type of authentication and details about the type of transaction to the Secure Element. The applet within the Secure Element associated with the user’s selected credential prepares the transaction data, which is routed to the NFC field.
It’s important to note here that only iPhone XS and later 2nd generation embedded Secure Element (eSE), aka Power Reserve Secure Element, iPhone devices are eligible for in-app NFC / SE transactions. I told you that iOS 17 was all about clearing the deck of 1st generation secure element iPhone models for real, iOS independent, eSE empowered open NFC, not crummy insecure HCE. The EU went ahead and demanded HCE anyway, even though Apple most certainly told them open NFC / SE was in the works. So EU countries are not getting NFC & SE Platform access. And if the EU asks for NFC & SE Platform access you can bet that Apple will tell them they already signed off on ‘open’ HCE flavored NFC, the cheaper, less secure, protocol limited, internet dependent version.
As said before, we’ll see how the iPhone open NFC & SE Platform pans out, but the days of Apple Pay Wallet transaction simplicity are gone for good. Apple Pay has been tremendously successful because it’s super easy to understand and use, the only way to do NFC transactions. It was Apple Pay lock in and security that made it successful with users. The lock in raised hackles with some in the developer community who couldn’t abide with the NFC Entitlement blackbox, and eventually governments started listening to them.
There is still enormous incentive for developers to choose the traditional Apple Pay Wallet NFC entitlement route. Wallet App has the tremendous Apple Pay Cloud system behind it, taking care of everything and users really like the ‘it just works’ appeal and doing everything with just Apple ID instead of juggling app accounts. Developers like JR East like it because Apple Pay handles all the Suica localization, it saves them the costs of non-Japanese language Suica App support for a tiny, but vocal, potential user base that will never use the extra features. Wallet Suica handles the basic needs of most users. JR East also gets the benefit of new Wallet features like iOS 17 Multi-device provisioning, saving them system development and support costs.
All things change, it’s a start of a new chapter in the iPhone NFC saga. In Japan we’ve seen the proliferation of QR Code payment apps, part of the profound mobile payment changes wrought by Apple Pay, that people try to open in network challenged store environments, holding up the checkout line. My one hope is that the QR payment app checkout line curse is not visited on iPhone users with iOS 18.1 in-app NFC transactions, but that’s a story for somebody else to cover. It’s been fun writing about Apple Pay…thanks for reading.
That’s all folks!
You must be logged in to post a comment.