The Super Suica Touchless Connection

The recent flurry of press releases and news reports for touchless walkthrough transit gates and handsfree touchless store payments sheds considerably more light on the next generation Suica architecture and FeliCa OS. The new Suica card due in spring 2021 does not have an official name. I call it Super Suica. Here’s what has been announced so far.

Next Generation Suica “2 cards in 1” architecture, new FeliCa OS, new IC card format announced by Sony, JR East, JR East Mechatronics (JREM) in September 2018.

Handsfree touchless Mobile FeliCa payments technology based on UWB+Bluetooth on Mobile FeliCa announced by Docomo, Sony, NXP Semiconductors in December 2019. A new JR East touchless transit gate was also reported by Kyodo News around the same time and was confirmed by JR East. The new touchless payments technology uses FeliCa for transactions but uses a UWB+Bluetooth front-end instead of NFC.

No delivery date for touchless gates or touchless payments has been announced but as Junya Suzuki pointed out in his recent article, Japanese transit infrastructure investment runs in 7~8 year cycles. The Takanawa Gateway station opening and the Tokyo Olympics in 2020 are the kickoff for the next transit infrastructure cycle. I see 3 basic transitions for JR East and the other major transit companies.

  • Suica transition from legacy architecture to next generation ‘2 cards in 1’ Super Suica staring in spring 2021.
  • FeliCa transition from NFC only front-end to incorporate UWB+Bluetooth radio technologies for handsfree touchless payments. News reports suggest deployment of JR East touchless walkthrough gates starting in 2023.
  • QR Code transition from legacy magnetic strip and other paper ticketing. Testing and evaluation is due to start at Takanawa Gateway station in 2020 with new Suica+QR Code dual reader transit gates.

Next generation Suica and Touchless Mobile FeliCa represent an interesting twist in that both require a new version of FeliCa. My take is that the new versions of FeliCa OS are one and the same, and that both Super Suica and Touchless incorporate UWB and Bluetooth protocols for transactions in addition to NFC-F.

Zero-sum Game Reset?
People are already complaining ‘oh no, not more JR East/FeliCa proprietary BS,’ but that snap judgement is way too early. Outside of the basic technologies we don’t know what standards are involved for handsfree touchless payments, but we do know that NXP is partnering with Docomo and Sony on the effort. That means MIFARE is already working on it too. JR East announced at the 2016 Tokyo NFC Forum conference that they are dedicated to working for open compatible transit payments (i.e. open ticketing between transit operators, not EMV).

Let’s take JR East at their word and assume that there is just one flavor of UWB+Bluetooth touchless, that it is fast, that it is open. In this scenario the same UWB+Bluetooth touchless front-end could be used by anybody from the large established proprietary players like EMV, FeliCa and MIFARE to open transit payment associations like Calypso. I hope this is the scenario that plays out. We don’t need a repeat of the ‘let’s make NFC A-B (Philips and Motorola) an open standard and shut NFC-F (Sony) out of the game’ nonsense that didn’t help anybody except QR Code players.

The Apple angle is interesting. Global NFC support put Apple Pay ahead of the curve. Apple putting UWB into iPhone 11 this year could be another ‘get ahead of the curve’ move so that everything is ready to roll with Super Suica on iOS 15/watchOS 8 in late 2021. I doubt anybody will see it this way, but I think touchless Mobile FeliCa and JR East plans for it are one factor in Apple’s decision.

Handsfree Touchless Smartcards?
One very important question: does this stuff work on smartcards? So far only smartphones have been mentioned in the press releases. Indications are that Super Suica is launching with new IC smartcard issue, by necessity it will have be backwards compatible with current transit card IC infrastructure.

If JR East plans to deploy touchless gates systemwide starting in 2023, Super Suica plastic transit cards must work seamlessly with the new gates. It doesn’t make any sense to issue yet another card, Super Duper Suica, to work with handsfree touchless. It also doesn’t make sense if touchless is only for smartphones. If it’s going to work in the minds of transit users and be used at all, all of it has to work perfectly, out of the gate.

Advertisements

One down, two to go on Apple Pay Express Transit 2019 'coming later this year' list

Apple Pay Express Transit arrived on the Transport for London system over the weekend, some 6 months after it was announced. The other 2 remaining Apple Pay Transit cards announced for later this year are Chicago Ventra and Hong Kong Octopus. I already wrote about Octopus not launching this year. The Ventra odds seem a little better. On the bright side Ventra is run by Cubic, the same folks who operate the TfL and New York OMNY systems and already have EMV Apple Pay Express Transit support up and running. Also the Ventra Chicago Twitter account did mention Apple Pay Ventra as ‘coming later this year’ in a Nov 30 tweet.

On the not so bright side, Apple Pay Ventra is the native MIFARE transit card, the first native transit card that Cubic has ported to a digital wallet and a big complicated transit system at that. Nevertheless, Ventra is telling users that Apple Pay is coming this year. Let’s hope for a successful 2019 launch in the next few weeks.

Fields of Dreams: the endlessly looping open loop vs closed loop transit debate

MacRumors reported that Apple Pay Express Transit support is finally arriving, bit by bit, on the TfL system after being announced back in May. I only noticed the piece because somebody threw a link to my site in one of the forum comments and the discussion has some interesting, and deliciously snarky, open loop bank cards for transit vs. native transit card debate.

The ‘Japan has a transit IC card problem’ angle is interesting. Yes, Japan does have a transit IC card problem, if you work for a bank credit card operation that wants to promote open loop, which I suspect is the case in the forum debate. The counter argument presentation-like power points are just too glib: to date no major transit system has junked native transit cards for bank cards, not even Oyster. Transit is a license to print money and the huge transaction volumes in Tokyo alone are mouth watering. The ‘problem’ for bank card players is how to angle for a bigger cut of the action.

The debate perfectly represents the plastic era transit card vs credit card mindset. More interesting to me are the things people don’t discuss: the impact of Apple Pay and Google Pay digital wallet platforms and transit business models. My take is that smartphone digital wallets do away with old plastic era distinctions and create new business opportunities for transit companies, if they chose to pursue them. Most don’t.

Tech analysts love to talk about ‘value capture’. The current cashless payments frenzy in Japan is all about capturing users to sign on with a payment platform then growing the ecosystem with more and more services that users, hopefully, want to pay extra for. Nobody talks about this in the open loop vs closed loop debate. The bank that owns the credit card owns the customer going through the transit gate, not the transit company. Put it this way, JRE POINT that go back into free Suica recharges, Green Car upgrades, etc. are vastly different from bank card points, as are the business platforms they feed customers back into. Moving people are money in motion, who gets a cut and what businesses do with that cut is everything.

It an interesting paradox that Europe and America talk about privatizing public transportation in various degrees but to date only Japan and Hong Kong have built highly successful businesses based on ‘value capture’. The endless open loop vs closed loop debate always comes down to this: you can argue all you want about the parts but in the end it is meaningless. To truly understand things, you have to examine the whole business model, how everything fits together, and how that can benefit everybody while growing and evolving.

What does open Apple NFC really mean?

The German law to force Apple to open it’s “NFC chip” is a confusing one. Why does an EU country with one of the lowest cashless usage rates single out one company’s NFC product in a last minute rider to an anti-money laundering bill? That’s not banking policy, it is politics. Details are few but let’s take a look at what it could mean because when it comes to NFC technology, details are everything.

Background stuff
The so called Apple ‘NFC chip’ is not a chip at all but a hardware/software sandwich. The Apple Pay ecosystem as described in iOS Security 12.3 is composed of: Secure Element, NFC Controller, Wallet, Secure Enclave and Apple Pay Servers. On one end is the NFC chip controller front end that handles NFC A-B-F communication but does not process transactions, on the other end there is the Secure Enclave that oversees things by authorizing transactions. The fun stuff happens in the Secure Element middle where the EMV/FeliCa/MIFARE/PBOC transaction technologies perform their magic with Java Card applets.

The A/S Series Secure Enclave and Secure Element are the black box areas of Apple Pay. The iOS Security 12.3 documentation suggests the Secure Element is a separate chip, but Apple’s custom implementation of the FeliCa Secure Element, and the apparent ability of Apple to update Secure Element applets to support new services like MIFARE in iOS 12 suggests something else, but it is anybody’s guess. Apple would like to keep it that way.

So what does ‘open NFC’ really mean?
It’s helpful to look at the issue from the 3 NFC modes: Card Emulation, Read/Write, Peer to Peer.

Peer to Peer
Apple has never used NFC Peer to Peer and I don’t think this is a consideration in the ‘open NFC’ debate.

Read/Write
This was a limitation up until iOS 12, but everything changed when iOS 13 Core NFC gained Read/Write support for NDEF, FeliCa, MIFARE, ISO 7816 and ISO 15693. Developers can do all the NFC Read/Write operations they want to in their apps, I don’t think this is a consideration in the ‘open NFC’ debate.

Card Emulation
Apple limits NFC Card Emulation to Apple Pay Wallet with NDA PASSKit NFC Certificates. This is what the ‘open NFC’ debate is all about. I imagine that German banks and other players want to bypass the PASSKit NFC Certificate controlled Apple Pay ecosystem. Instead, they want open access to the parts they want, like Secure Element, NFC Controller, Secure Enclave, and ignore the parts they don’t want like Wallet and Apple Pay Servers. They want the right to pick and choose.

The success of Apple Pay has been founded on the ease of use and high level of integration from a massive investment in the A/S Series Secure Enclave and other in-house implementations such as global FeliCa, etc. Outside players forcing Apple to open up the Apple Pay ecosystem represent not only a security risk to Apple but also a reduced return on investment. One commentator on MacRumors said it’s like Apple took the time and expense to build a first class restaurant and outsiders are demanding the right to use Apple’s kitchen to cook their own food to serve their own customers in Apple’s restaurant. It’s a fair analogy.

The NDA PASSKit NFC Certificate gate entrance rubs bank players the wrong way as they are used to giving terms, not accepting them. The Swiss TWINT banking and payment app for example is a QR Code based Wallet replacement that wanted the ability to switch NFC off, and got it.

My own WWDC19 Apple Pay Wish List did include a wish for easier NFC Card Emulation, but nothing appeared. It’s certainly in Apple’s best interest to make it as easy as possible for 3rd party developers to add reward cards, passes, ID cards, transit cards, etc. to Wallet. However given that the EU is hardly what I call a level playing field, the fact that bank players and politics go hand in hand in every nation, and the fact we don’t know the technical details of what the German law is asking Apple to do, all we can do is guess. In general, I think Europe will be a long rough ride for Apple Pay. At least until EU bank players get deals they are happy with.

No global NFC evolution for Pixel 4?

iFixit posted a teardown of the Pixel 4 and we have a new NFC chip: STMicroelectronics ST54J NFC controller. This replaces the NXP PN81 used in Pixel 3 but still has a embedded secure element (eSE) that supports all the global NFC technologies: NFC A-B-F/EMV/FeliCa/MIFARE.

NFC Forum device certification requires NFC A-B-F hardware support, but Google went the cheap route again with the extra step of not installing FeliCa transaction keys in non-JP Pixel 4 models. This means only Pixel JP models are global NFC devices, users with non JP models cannot add and use the Japanese Suica transit card or Hong Kong Octopus. iPhone and Apple Watch have global NFC as a standard feature on all worldwide models since iPhone 8/X and Apple Watch Series 3.

Pixel 3 was step towards global NFC with the Japanese models. The Pixel 3 Global NFC Evolution post examined the possibility of Google creating their own ‘in house’ embedded secure element (eSE) for all NFC transactions technologies implemented on their own Secure Enclave Pixel platform. I was wrong and made some bad assumptions:

  • Apple was already doing global NFC transactions on the A/S Series Secure Enclave, so Google would try to do the same with their Titan chip.
  • The Pixel Phone hardware page states: if you purchased your Pixel 4, 3a or 3 phone in Japan, a FeliCa chip is located in the same area as the NFC. The wording suggests a separate FeliCa chip for JP Pixel models but this is not the case.

FeliCa Dude was very considerate of my Pixel global NFC fantasy even though it made no sense at all cost-wise or software-wise having an extra NFC FeliCa chip and multiple eSE just for JP models. He extensively tested a Pixel 3 JP model, a single global NFC NXP PN81B chip was the only answer.

The iFixit teardown confirms that Pixel 4 simply repeats last year’s Pixel 3 strategy of having global NFC hardware but only buying FeliCa transaction keys for JP models. It’s a weird strategy because the whole point of the NXP PN81 and ST54J chips is to provide customers with a convenient off the shelf global NFC package with all the hardware (NFC A-B-F) and software (EMV/FeliCa/MIFARE) ready to go.

The Pixel 4 looks like a great device but the NFC story angle remains a disappointment. As I have said before, the Android equivalent of global NFC iPhone and Apple Watch has yet to appear.

UPDATE
FeliCa Dude posted a deep dive into the Pixel 4 ST54J NFC chip and comes up with some fascinating analysis. He points out there were three model classes for Pixel 3:

  • Devices with eSIM functionality and without Mobile FeliCa
  • Devices without eSIM functionality and without Mobile FeliCa: the carrier-neutered model with a locked bootloader.
  • Devices without eSIM functionality and with Mobile FeliCa (the G013B/G013D models)

Pixel 4 delivers eSIM and FeliCa together to the Japanese market for the first time and this appears to be a reason behind Google choosing the ST54J that has eSIM + global NFC eSE on a single die. FeliCa Dude does not have a Pixel 4 yet so there is more analysis to do, but the important point is this:

if the Japanese SKUs of the Pixel 4 are indeed based on the ST54J, then there should be no technical reason why such <Mobile FeliCa> functionality can’t be delivered OTA <over the air update> to the ROW <rest of world> SKUs should Google desire to provide that service

The Pixel 4, the ST54J and Mobile FeliCa

It would be nice indeed if Google left the door open for adding Mobile FeliCa later to all non JP Pixel 4 models with a software update, especially for markets like Hong Kong that can use it. Whether Google will actually do that is another matter entirely.