Apple Pay First up of course, is Apple Pay. After Jennifer Bailey’s WWDC21 appearance where she announced home keys, hotel keys, office keys and ID for iOS 15 Wallet, and the separate Tap to Pay on iPhone PR announcement release in January, I don’t think Jennifer will be in the WWDC22 keynote. She’s not going to appear just to explain that Apple Pay is not a monopoly, that’s Tim’s job with CEO level pay grade, it’s unlikely she’s doing to appear to just recap details of what’s already been announced.
Bailey’s job is to announce new features, and I don’t think that after the big iOS 15 rollout of new Wallet features and Tap to Pay on iPhone there’s nothing really new. And it’s not her job to announce new frameworks, that’s what the sessions are for. Things that I have been wishing for these past few years such include easier, more open NFC Pass certification process and/or new frameworks for developers to access the secure element for payments or use Tap to Pay on iPhone. There needs to a clearer path for developers who want to use the secure element for payments (Wallet) or iPhone as payment terminal (Tap to Pay on iPhone).
Apple needs to open up the NFC/Secure Element Pass certification process and clarify the process
The only possible ‘new’ Apple Pay Wallet feature I can think of is the long in the works Code Payments. It has been lurking in the iOS shadows since iOS 13, so long that Apple legal inserted official mention in a recent Apple Pay & Privacy web page update: “When you make a payment using a QR code pass in Wallet, your device will present a unique code and share that code with the pass provider to prevent fraud.” If Apple Pay delivers native device generated QR code payments without a network connection, just like all Apple Pay cards to date, it would be quite a coup but by itself, but probably not worth a Jennifer Bailey appearance. Other future goodies like passport in Wallet or ID in Wallet for other countires are too far out to mention, at least in the iOS 16 time frame.
Apple Maps The only new Apple Maps feature that suggests itself is AR enhanced ‘Look Around’ indoor maps for stations. That’s the conclusion after examining the current (February ~ May 2022) backpack image collection in Tokyo, Osaka, Kyoto and Nagoya. It is highly focused on stations, and stations such as Shinjuku, Tokyo, Shibuya, Ikebukuro, etc., are mostly underground, surrounded with densely packed extensive maze like malls.
This means Apple image collection in Japan is going indoors for the first time, likely at pre-arranged times when people are scarce. This is hard to do at a place like Shinjuku station as multiple companies collectively manage the entire site (JR East, Odakyu, Keio, Seibu, Tokyo Metropolitan Bureau of Transportation, Tokyo Metro, just to name a few).
Apple needs something new with indoor maps as the current incarnation is inadequate for stations. As Google Maps Live has shown in Tokyo station, AR walking guidance is a good fit for indoor maps that navigate users through intricate, information dense underground station mazes, though Google’s version has its problems. New and improved, AR enhanced “Look Around” style indoor station maps with walking directions that seamlessly guide users from transit gate to final destination would be far more useful than they are now.
Recent image collection suggests Indoor Station Maps might be coming in iOS 16Apple backpack Image Collection was mostly focused on station areas in 2021
Overall, I am not optimistic that Apple Maps in Japan can become a top tier digital map service. The local 3rd party map and transit data suppliers that Apple depends on to make up the bulk of the Japanese service are decidedly not top tier. Old problems remain unfixed. In the case of the main Japanese map data supplier things have deteriorated.
Increment P (IPC) was 100% owned by Pioneer but was sold to Polaris Capital Group in June 2021 with a new CEO (ex Oracle Japan) who quickly changed the name to GeoTechnologies Inc. Under hedge fund Polaris Capital Group led management the company has been busy inflating the number of cushy company director positions, never a good sign, and pushing out shitty ad-ware apps like Torima. The focus is leveraging assets not building them.
Apple’s Japanese map problem can only be fixed by dumping low quality GeoTechnologies for a top quality digital map supplier like Zenrin (the amateurish UK backed Open Street Map effort in Japan is not worth serious consideration) or Apple aggressively mapping Japan themselves. Apple has not pursued either option: the image collection effort in Japan is leisurely and limited, its use remains restricted to Look Around. Until this changes, expect more of the same old fundamental Japanese map problems in iOS 16 and beyond. Apple Maps is a collection of many different service parts. Some evolve and improve, some do not. Let’s hope for a good outcome with the data Apple is collecting for indoor station maps.
Apple Typography TextKit 2 migration WWDC21 saw the unveiling of TextKit 2, the next generation replacement for the 30 year old TextKit, older than QuickDraw GX even, but much less capable. TextKit 2 marked the start of a long term migration with most of TextKit 2 initially ‘opt in’ for compatibility. We’ll find out how much of TextKit 2 will evolve to default on with an ‘opt out’. There are holes to fill too: the iOS side didn’t get all the TextKit 2 features of macOS such as UITextView (multiline text), some of the planned features like NSTextContainer apparently didn’t make the final cut either. We should get a much more complete package at WWDC22. Once the TextKit 2 transition is complete, I wonder if a Core Text reboot is next.
watchOS 9 Express Cards with Power Reserve? Mark Gurman reported that watchOS 9 will have “a new low-power mode that is designed to let its smartwatch run some apps and features without using as much battery life.” While this sounds like Express Cards with Power Reserve (transit cards, student ID, hotel-home-car-office keys) and it might even mimic the iPhone feature to some degree, it will not be the real thing. Power Reserve on iPhone is a special mode where iOS powers down itself down but leaves the lights on for direct secure element NFC transactions. iOS isn’t involved at all.
Real Power Reserve requires an Apple silicon design that supports the hardware feature on Apple Watch, it cannot be added with a simple software upgrade. Until that happens, a new watchOS 9 low-power mode means that watchOS still babysits Express Cards, but anything that gives us better battery life than what we have now is a good thing. We’ll find out later this year if Apple Watch series 8 is the real Power Reserve deal.
(The) Digital Markets Act will…require companies designated as gatekeepers to ensure effective interoperability with hardware and software features they use themselves in their ecosystems. This includes access to NFC for mobile payments.
Today’s case addresses a conduct by Apple that has been ongoing since Apple Pay was first rolled out in 2015 <sic, 2014 actually>. This conduct may have distorted competition on the mobile wallets market in Europe. It prevented emergence of new and innovative competition that could have challenged Apple.
Mark Gurman and Jillian Deutsch at Bloomberg also did everybody a favor unmasking PayPal as one of the instigators behind the EU Commission Apple Pay investigation. Yes, that PayPal…the financial service that snuffs out user accounts whose politics they don’t like, or worse just seizes their money.
Both pieces miss important context surrounding the debate however…and with this issue context is all, especially how Apple Pay is playing out in other global markets. Most of what follows I’ve covered in earlier posts but hope to pull the various issues together in one post. Yet again, we kickoff with an updated Apple Pay diagram.
The so called Apple ‘NFC chip’ is not a chip at all but a hardware/software sandwich. The Apple Pay ecosystem described in iOS Security is a collection of tightly integrated polished pieces: Secure Element, Secure Enclave, NFC Controller, Wallet and Apple Pay Servers, all wrapped into a slick, easy to use UI with a final security wall of ‘secure intent’, a double-click side button hot-wired to the Secure Element. This approach has been so successful that people divide mobile payments history into pre-Apple Pay and post-Apple Pay eras.
NFC has been on Android far longer than iPhone, and ‘open NFC’ at that, but is far less successful capturing mobile payment users than Apple Pay. This is because Android device manufactures made the classic mistake of taking the ‘let’s take awesome NFC technology and figure out how we’re going to market it’ approach. Jennifer Bailey’s Apple Pay team choose the hyper focused Steve Jobs approach of starting with the customer experience and building backwards while asking: “what incredible benefits can we give the customer, where can we take the customer?” That choice made all the difference.
Apple Pay has a very simple rule: any card that loads a Java Card applet into their embedded secure element (eSE) has to reside in Wallet app. The maximum number depends on how many Java Card applets it can hold at any one time, the previous limit was 12, the iOS 15 Wallet limit is 16 cards. Developers have two ways to access iPhone NFC: 1) Core NFC framework for NFC operations that don’t use the secure element, 2) Secure Element pass certificates for NFC operations that need secure element transactions (payments, keys, ID, passes). Any developer who wants to run applets in the eSE has to apply for a PassKit NFC/Secure Element Pass Certificate. This is covered by NDA but a company called PassKit (not Apple) gives us an idea what Apple’s Secure Element Pass guidelines are:
Apple care a great deal about the user experience. Before granting NFC certificate access they will ensure that you have the necessary hardware, software and capabilities to develop or deploy an ecosystem that is going to deliver an experience consistent with their guidelines.
The end to end user experience, the whole reason behind the success of Apple Pay. But this gatekeeping is what riles banks and financial service providers who want to load their applets into the secure element without the Apple Pay gatekeeping, without the Apple Pay ecosystem and without the Apple Pay commission. They want to do their own transactions with their own app for free. This is what the EU Commission means when Vestager says: “Evidence on our file indicates that some developers did not go ahead with their plans as they were not able to to (sic) reach iPhone users.” It should read: when they were not able to reach iPhone users for free. Either the developer didn’t apply for a Secure Element Pass, didn’t pass the certification process, balked at Apple’s certification conditions, or couldn’t agree on Apple Pay commission rates.
Secure element gatekeeping is not new, it is an essential part of the secure element system:
A Secure Element (SE) is a microprocessor chip which can store sensitive data and run secure apps such as payment. It acts as a vault, protecting what’s inside the SE (applications and data) from malware attacks that are typical in the host (i.e. the device operating system). Secure Elements handle all sorts of applications that are vital to our modern digital lives…
Mobile Payments Here, the Secure Element securely stores card/cardholder data and manages the reading of encrypted data. During a payment transaction it acts like a contactless payment card using industry standard technology to help authorize a transaction. The Secure Element could either be embedded in the phone or embedded in your SIM card.
Lifecycle management It’s crucial that SE-embedded devices are secure throughout their lifecycle. That’s why Secure Elements need to have an end-to-end security strategy. It’s no use developing a robust security solution for a device which becomes obsolete after a period of use. This is why Secured Elements can be updated continuously to counter new threats.
Few people, especially a PayPal or EU Commission vice president, discuss the crucial secure element lifecycle management aspect. It’s not convenient for them to say the secure element ‘gatekeeper’ is responsible for keeping it secure. Far more convenient for their arguments to omit this, portray gatekeeping as unnecessary and gatekeepers as evil. In the end however, Apple has to maintain secure element updates from the various licensed secure element providers (EMV,FeliCa Networks, MIFARE, and so on) if secure payments are going to work at all This is what people who say, ‘it’s my device, we should be able to use NFC how we want,’ do not understand.
People also forget that nothing is free, you get what you pay for. With Apple Pay as gatekeeper, users get simplicity, innovation and feature updates. Simplicity: users get NFC they can use out of the box without Android-like NFC complexity such as secure element positions and obscure express mode settings.
The user finally got his Mobile Suica to work right on Android after turning off the ‘No NFC while locked’ option.
Innovation: Apple Pay has features like Global NFC. iPhone and Apple Watch are the only smart devices that come with FeliCa built in as standard to use in Hong Kong or Japan, while Android limits functionality by market region. It’s astounding that Android, not even Google Pixel Android, has matched this basic functionality yet. We’re seeing more innovation as Ultra Wide Band (UWB) extends Wallet functionality to include ‘Touchless’ car keys and eventually, UWB enhanced automatic card selection as you approach the reader; more helpful than you might think.
And the lesson? Apple Pay changed everything in the Japanese payments market, a catalyst that opened up competition and payment choices, for everybody. All boats rose together. It’s one of the most vibrant payment markets that Apple Pay operates in.
Japan is key to understanding what’s really going on in the Apple Pay monopoly debate. Japan was the first market with an established mobile payment platform in place, long before mobile EMV contactless payments took off in Europe. iPhone also has a much larger marketshare in Japan than it does in Europe. It’s a shame people pass up the opportunity to learn from the successes and failures here.
So what’s the EU Committee vision for ‘open NFC’? I think it’s a rehash of the secure element wars when carriers locked mobile payment services to SIM contracts. In 2013 Google incorporated SimplyTapp HCE (Host Card Emulation ‘secure element in the cloud’) technology as a NFC ‘workaround’ to ‘free’ NFC from the evil clutches of mobile carriers. Sound familiar? Android NFC has never been right since.
How little things change, swap ‘evil mobile carriers’ for ‘evil Apple’ and you have the same self serving ‘open’ vs ‘closed’ NFC chip nonsense that people are debating today. FeliCa Dude, the ultimate industry insider who has experienced it all, said it best: ‘It’s all eSE or nothing now.’
And yet we now have Île-de-France Mobilités (IDFM) turning back the clock, circumventing the eSE on NFC equipped Android devices and going all in with HCE for IDFM’s Smart Navigo service for Android. To me this says all you need to know what European priorities are regarding the ‘open NFC’ model: eliminate eSE gatekeepers by forcing the less secure network dependent HCE as a required option. Good luck with that. From a transit perspective, based on Mobile Suica user experiences, I don’t think HCE Smart Navigo will be a smooth ride.
The EU Committee ‘open NFC’ vision might look ideal…to Apple Pay competitors. Regular users however, will have to deal with the ugly reality of multiple NFC apps, multiple NFC secure element modes and clashing updates that cancel out NFC services. Apple Silicon eSE space is limited to 16 cards. If that sounds like a lot now, wait until you have credit cards, transit cards, home, car and office keys and ID installed along with ‘open’ NFC apps wanting their own eSE space too. Services will be squeezed out forcing the user to intervene. If the EU Committee thinks this environment fosters competition and innovation while growing mobile payment use, dream on.
Japanese tech journalist Junya Suzuki has covered NFC mobile payment developments in Europe, America and Japan for over 2 decades. He doesn’t think the EU is playing an even hand here, in his opinion Samsung and Huawei would never face the scrutiny that Apple now faces. In typical European cultural fashion, EU motives pay lip service to fair open markets while playing an underhanded game of chess to make Apple do what EU banking interests want Apple to do. In other words, a double standard.
What does Apple need to do? I’ve always said that Apple needs to make the Secure Element Pass application process as transparent as possible. Keeping the blackbox NDA process as it is now makes Apple Pay a target, increasingly difficult to defend the status quo. Secure Element access on the level of Core NFC is a long shot, the very definition of a secure element means there has to be a developer certification process similar to EMVCo, FeliCa Networks, MIFARE, Calypso Networks Association, etc., that protects the privacy and business interests of all parties. But it would be great if there is a middle way where Apple can securely open things up for iPhone as a digital wallet, and iPhone as a payment terminal. We’ll see if Apple has anything to say about the subject at WWDC22.
Recommended reading: Ruimin Yang’s wonderful overview, “Apple Pay monopoly, are we really comparing ‘Apples’ with ‘Apples?” examines the Apple Pay system architecture, how it compares to other digital wallet platforms, (Google Pay, Samsung Pay) and what ‘open vs closed’ means in the ‘Apple Pay is a monopoly’ debate.
A Japanese friend once told me that when Suica first came out, young people in Tokyo sent Suica cards to hometown families to use for coming to Tokyo. But parents and grandparents sent them back saying, “we can’t use them,” even when they could use them in their local area.
What they were really saying was, ‘Suica doesn’t get us the same transit perks we do using local paper tickets or mag stripe cards.’ There has long been a huge gap between transit services available in major cities which ‘don’t work’ in one way or another for those in outlying areas.
That’s the challenge facing the Japanese transit IC card system. Being able to use a Suica or ICOCA transit card in the sticks isn’t enough, local region services must be attached to make it worthwhile for people living outside major city areas. Transit IC has to evolve if it is going to be useful in the mobile era with proliferating smartphone payment apps vying for a piece of the national transit pie.
Now that we have a clearer vision of how Suica 2 in 1 Region Affiliate cards address this problem and how they are central to JR East’s MaaS strategy, it’s time to look at evolving JR East cloud services and how they fit into that strategy. There are a number of new cloud service parts that have come on line over the past year, or are coming soon…some visible, some not.
Taken together they comprise what I call ‘Super Suica Cloud’ following my earlier definition of Super Suica: a collection of mobile focused transit and payment infrastructure services that can be shared with or incorporate other company services, or be hosted by JR East for other companies. MaaS is an elastic term that holds a lot of flashy concepts, but I think JR East is aiming for something more low-key but practical, a Japanese Multimodal MaaS if you will.
The immediate concrete end-goals are service expansion with cost reduction; elimination of duplicate or proprietary dedicated infrastructure in favor of open internet cloud technology. With that in place the next goal is tight integration of transit payment services that work everywhere but also deliver tailored services for local regions. Let’s examine the parts.
Mobile Suica People assume that Mobile Suica does everything mobile, but basically it’s a station kiosk in the sky. Put money in for a transit card, put money in for a recharge, or a commuter pass, a day pass, and so on. Issuing, recharging and managing Suica cards on mobile devices is what Mobile Suica was built for.
As the world’s first mobile transit card service, Mobile Suica has made a lot of progress over the years expanding support to include Android, Apple Pay and wearables, but the work isn’t done until any mobile device from anywhere can add Suica. And since Mobile Suica hosts Mobile PASMO (launched in 2021) and almost certainly the forthcoming Mobile ICOCA (coming early 2023), getting those on an equally wide digital wallet footing is just as important.
As the face of all things Suica on mobile devices, the smartphone app could have many more things plugging into it, like Hong Kong’s Octopus App. So far however, JR East has chosen, wisely in my opinion, to keep it limited to basic housekeeping, breaking out ticketing and MaaS functions to separate apps.
Suica Fare Processing • JESCA Cloud This is the traditional Suica network system centerpiece that locally processes touch transit stored fare on station gates and touch e-Money payments in stores. The station gate fare side is getting a major new expansion on May 27, 2023 with a simplified cloud based Suica transit fare network rolling out to 44 Tohoku area JR East stations. This new Cloud Suica area closely aligns with recently launched Suica 2 in 1 Region Affiliate cards.
Cloud Suica 2023 additions (Orange) and Suica 2 in 1 cards below
The store payment side also has a simplified cloud based FeliCa payment network and a name: JESCA-Cloud. System details are vague but Cloud Suica transit fare and JESCA Cloud store payments appear to do the same thing: move transaction processing off local hardware and onto the cloud. Fast processing time is very important at transit gates, Suica tap times are the fastest out there. Those familiar with the Suica system say Cloud Suica will spilt it 50% local processing / 50% cloud processing. Dumber terminals, smarter cloud that still offers great Suica service…we hope.
One difference Cloud Suica has from a similar effort by JR West for ICOCA, is that Cloud Suica supports all the standard Suica features like commuter passes that cloud ICOCA does not. An interesting side note is that JR East hosts the processing for JR Central’s TOICA transit card network, they can certainly put the new Cloud Suica backend to good use expanding TOICA coverage in rural lines like the Minobu line.
ID Port Comb through recent JR East press releases and you’ll find 3 service announcements built around ID PORT, a “cloud based ID verification solution” from JREM (JR EAST MECHATRONICS CO., LTD), the company that builds Suica infrastructure.
Maebashi City TOPIC MaaS service (November 2020): Local MaaS discount services provided by TOPIC that use Suica with My Number card address and age to verify eligibility:
Mamorail (March 2020): a notification service for parents or caregivers, the first service based on ID-PORT. A registered Suica or PASMO (child) triggers a email notification when tapped at the transit gate with station and time info emailed to the parent’s/caregiver’s device.
All of the announcements have 3 components: a transit card (Suica), ID-PORT, 3rd party services attached to Suica (or PASMO) using ID-PORT as the system glue. Most of these are either in testing or ‘coming soon’. What is ID-PORT?
ID-PORT is explained on the JREM site, but the first public mention in an NTT Data PDF document from November 2020 is more revealing: “The Open MaaS Platform and supporting Multimodal MaaS”. The JR East Suica MaaS strategy is outlined with various scenarios that indicate ID-PORT is the JREM side with MaaS services on the NTT Data side. In other words a co-venture.
The job of ID-PORT is that it acts as the middle man ID verification glue linking a registered Suica (or similar Transit IC card) with various 3rd party services such as special ticketing, access and discounts.
The interesting thing about the ID-PORT and NTT Data MaaS platform reveal is that the timing coincides with Sony’s release of FeliCa Standard SD2, the next generation FeliCa architecture used for Suica 2 in 1 cards. One of the little discussed new SD2 features is ‘FeliCa Secure ID’. Here is Sony’s diagram of how it works.
Look familiar? Yep, ID-PORT sure looks like FeliCa Secure ID in action. The JREM ID-PORT page is more rounded out, incorporating non-FeliCa ID verification methods like QR and bio-authentication and many different services. ID-PORT has already been added to JESCA-Cloud and CardNet so that linked services are widely available on store payment terminals, not just Suica transit gates. In sum it represents MaaS and Account Based Ticketing in action with ID-PORT at the center.
MaaS and Account Based Ticketing in action MaaS and Account Based Ticketing are the new hotness now that people realize open-loop doesn’t solve everything as banks and card companies want us to believe. Fare Payments Platform provider Masabi explains it this way:
Account Based Ticketing (ABT) shifts the fare collection system from being ‘card centric’, meaning the ticket holds the journey information and right to travel, and moves this to the back office. Moving the ticket information to the back office holds a number of benefits. It means passengers no longer need to buy a ticket or understand fares to travel and instead they use a secure token, typically either a contactless bank card, mobile phone or smartcard.
In this scenario FeliCa Secure ID is a secure token, ID-PORT is the secure token platform using the secure token to link ticketing and services together. That sounds nice but when will we see it in action? I think we already are.
Eki-Net Account Based Ticketing As explained above, ABT attaches tickets from the cloud to a secure token, in this case Suica. By this definition Eki-Net Shinkansen eTickets represent JR East’s first step into ABT ticketing. Eki-Net uses registered accounts and credit cards purchase and attach eTickets to Suica. These eTickets do not use Suica prepaid stored fare nor is any eTicket information written to the Suica card, the eTicket system uses Suica as a secure token. JR Central smart EX is a similar ABT service and let’s not forget the web-only multi-lingual JR-East Train Reservation service that provides some ABT ticketing for inbound visitors.
Will JR East ABT implement the ‘no longer need to buy a ticket’ part of the Masabi ABT vision? I doubt it. Shinkansen eTickets are much lower ABT hurdle: lower passenger volume on far fewer transit gates than regular Suica gates. The complexity of interlocking non-Shinkansen Japanese transit systems and the vast array of fare schedules, such as higher paper fares vs cheaper IC fares, don’t easily straitjacket into an open-loop or ABT fare box, and it doesn’t fit the JR East business model.
Suica 2 in 1 region extras There are services besides ticketing attached to a ‘secure token’ Suica. One of the important things easy to miss in the Suica 2 in 1 rollout are extra region features not available in regular Suica. Disability Suica cards for example. These are finally due to launch on Suica and PASMO cards in October 2022, but disability Suica 2 in 1 cards are already available in region affiliates.
There are also region affiliate transit points, one of the services that ID-PORT is advertising for JR East MaaS. Transit points all ‘just work’ automatically the same way. Points are earned from recharge and transit use and automatically used as transit fare. The user doesn’t do anything except tap the bus card reader. No registration, no setup. I wish JRE POINT had an option to work this way.
Transit points mimic the scheme of old regional transit mag strip card like Nishitetsu that gave ¥1,100 with a ¥1,000 recharge. Those features were popular (automatic simplicity in action again). PayPay used a similar strategy to quickly build a large customer base but pissed everybody off later as they got big and started changing bonus rate returns like used underwear. That won’t happen with Suica 2 in 1 cards as region transit points are locked in by local government subsidies to the region affiliates.
AOPASS transit points, different regions have different point returns but they all work the same way.
Streamlined simplicity, integration, regionality Despite the la-la-land promise of MaaS and Account Based Ticketing, the ‘just works’ angle is crucial for people to actually use it. One of the current problems with Mobile Suica, Eki-Net, JRE POINT and the MaaS services JR East advertises is that is each service is a separate app + registration + attach cards process. This needs to be streamlined into a single simple JR East sign-on service option like Sign in with Apple that works across multiple services. I suspect ID-PORT is the glue between Mobile Suica and JRE POINT that keeps those registered services automatically linked even if the Suica ID number changes. A good sign because the JR East cloud needs a lot dynamic linking.
There is also the larger problem of integration outside of JR East, such as the current state of multiple online ticketing services; Eki-Net for JR East, EX for JR Central, Odekake-net for JR West, and so on. It would bet great to have a common app that plugs into every online ticketing service. At the very least JR Group companies need to integrate eTicketing the same way they have always integrated paper ticketing for one stop service in their own apps.
The bigger question is do Super Suica Cloud parts (ID-PORT / Mobile Suica / Cloud Suica) scale beyond JR East to include other JR Group companies (JR West, JR Central, etc.) and potential region affiliates nationwide? If increased services with reduced costs is their MaaS goal, JR East needs to step up to the plate and share. Infrastructure sharing with backend integration is the only way forward for all. Japanese transit has always excelled at physical interconnection, the cloud service side needs the same level of interconnectedness.
There are cultural angles too. Japanese have a passion for hunting down local perks, bargains and discounts. People complain about Eki-Net (deservedly) but they sure scramble and swamp the system getting those time limited discount eTickets like crazy pre-COVID era Black Friday midnight Christmas shopper crowds rushing into the store.
There is also the traditional cultural value of promoting local economies. As the saying goes, cities are only healthy in the long term when local economies are healthy too. If JR East is really serious about promoting regional MaaS, they’ve got to aggressively offer linked services that clearly promote regions. There are many region programs that visitors are simply not aware of. JR East can do a lot simply linking them to discount coupons, limited offer eTickets and such that appeal to the bargain hunter Japanese mind. The key is being creative and nimble like QR payment players.
The JR East MaaS region affiliate strategy was conceived long before the COVID crisis, yet COVID also presents a golden opportunity to invest in regions and promote working remotely. The world has changed and transit has to change too, the biggest risk is doing nothing, staying with the status quo. The emerging Japanese MaaS vision is unique in that Japan has a golden opportunity of leveraging the national Transit IC card standard into something new, taking it into the next era…if old rivalries and sectarian interests don’t get in the way and blow it, that is. Either way the next few years will be a very interesting time for Japanese transit.
Don’t you love how big organizations play fast and loose with big concepts like Host Card Emulation? HCE was SimplyTapp created technology that Google incorporated into Android Pay in 2013 sowing endless nonsense and confused debate about ‘open’ vs ‘closed’ NFC, aka the secure element wars. Back then industry pundits said:
The significance of HCE is that it frees NFC from dependence on the secure element, which has largely been controlled by mobile carriers. Banks, merchants, and wallet developers must pay fees for access to that chip. Yeager is counting on HCE to scare up interest among issuers and kickstart NFC, which has been stuck in neutral for years.
SimplyTapp, the Power Behind Google’s NFC Workaround, Aims at Mobile Banking
HCE was created when the cloud was seen as an answer for every problem. All it did for ‘freeing’ NFC from dependence on the secure element on a device was make it dependent on a network connection to connect with a ‘secure element in the cloud’. But this was overlooked in the rush to ‘free NFC’ from the evil grasp of mobile carriers.
How little things change, swap ‘evil mobile carriers’ for ‘evil Apple’ and you have exactly the same self serving ‘open’ vs ‘closed’ NFC chip nonsense that people are debating in Europe and Australia today. FeliCa Dude, the ultimate industry insider who has experienced it all, said it best: ‘It’s all eSE or nothing now.’
Let’s make this simple as possible and list the industry forces in the NFC secure element wars:
SIM Secure Element (SE) used by the mobile carriers for carrier locked NFC payments
Embedded Secure Element (eSE) used by smartphone manufacturer digital wallet platforms (Apple Pay, Samsung Pay, Huawei Pay that use customized eSE and truly control it, off the shelf all-in-one NFC chipset users like Pixel and Xiaomi not so much)
Host Card Emulation (HCE) is a secure element in the cloud strategy used by banks and card issuers on network connected Android devices using their own apps that bypass #1 and #2.
Carriers, smartphone manufacturers, banks•card issuers. Carriers lost out long ago. A classic case would be NTT docomo who built the worlds first major digital wallet platform, Osaifu Keitai, using Sony Mobile FeliCa technology back in 2004. Osaifu Keitai eventually made it to the other major Japanese carriers (KDDI au and SoftBank) but the carriers made the mistake of locking and limiting Osaifu Keitai service to SIM contracts and their own branded handsets.
More than anything else, carriers milking Osaifu Keitai as an expensive exclusive SIM contract option instead of making it a SIM free standard for everybody, was the reason why Osaifu Keitai growth stalled. The 2016 launch of Apple Pay in Japan circumvented the entire SIM SE mess with its own eSE, and gave Mobile FeliCa the second chance it’s enjoying now.
Smart Navigo power play Smart Navigo is the Île-de-France Mobilités (IDFM) Paris region transit card for mobile on Galaxy devices, and Android smartphones with Orange SIM cards. France was an early innovator of NFC on mobile phones but it did not lead to early mobile transit adoption: Smart Navigo launched in September 2019.
What LeParisien was reporting was that IDFM suddenly ended their partnership with Orange: “As long as you do not change your SIM card, the service is operational: you can continue to buy tickets and validate them with your phone,” If customers change their Orange SIM card, Smart Navigo no longer works. IDEM is freeing Smart Navigo from the evil grasp of a mobile carriers.
A new solution is scheduled for deployment in mid-2022. It will be open to all Android smartphones, without operator constraints, thanks to HCE (Host Card Emulation) technology that emulates cards in a mobile application, allowing it to free itself from NFC constraints. HCE was also partly used for the SIM card developed by the start-up Wizway on behalf of Orange.
It’s 2021, the secure element wars ended years ago. Perhaps IDFM didn’t get the message. Or maybe they want to turn back the clock and fight the battle again. IDFM has spent a lot of time and expense working with Calypso Networks Association, the transaction tech used for Navigo, to develop the less secure network dependent Calypso HCE ‘cloud’ secure element approach. It flies in the face of where payment transaction technology has been going with eSE as standard hardware on all modern NFC devices.
It’s important to remember that one problem with the term HCE is that people and companies use it very loosely. All secure element methods have to load payment credentials from the cloud at some point. The big difference is that eSE and SIM SE have secure physical areas to store those payment credentials on the device, HCE does not. Far too many people assume that any kind of loading from the cloud = HCE, it does not. HCE = storing on the cloud.
With HCE, critical payment credentials are stored in a secure shared repository (the issuer data center or private cloud) rather than on the phone. Limited use credentials are delivered to the phone in advance to enable contactless transactions to take place.
This approach eliminates the need for Trusted Service Managers (TSMs) and shifts control back to the banks. However, it brings with it a different set of security and risk challenges…
A centralized service to store many millions of payment credentials or create one-time use credentials on demand creates an obvious point of attack. Although banks have issued cards for years, those systems have largely been offline and have not requiring round-the-cloud interaction with the payment token (in this case a plastic card). HCE requires these services to be online and accessible in real-time as part of individual payment transactions. Failure to protect these service platforms places the issuer at considerable risk of fraud…
All mobile payments schemes are more complex than traditional card payments, yet smart phone user expectations are extremely high:
•Poor mobile network coverage can make HCE services inaccessible. •Complex authentication schemes lead to errors. •Software or hardware incompatibility can stop transactions.
What is Host Card Emulation (HCE)?
The two key takeaways are: 1) HCE shifts control back to banks and card issuers away from carriers and Android smartphone manufacturers, 2) No network connection = no HCE. Think of HCE as the NCF equivalent of QR Code payment services like AliPay and PayPay that also send payment credentials to the app, just in a different format.
Apple Pay has succeeded because it delivers on those high smartphone user expectations better than any other digital wallet out there. That’s why JR East needed to get Suica on Apple Pay to take Mobile Suica to the next level combining ease of use with growth, which is exactly what happened.
IDFM unceremoniously dumping Orange and going all in with HCE is all about IDFM wanting full control and nothing to do with carriers (SIM SE), Android smartphone manufactures (eSE). Realistically it has to be HCE for Android because Android manufactures would never update older device eSE to support Calypso. We won’t know the full story until the HCE Android service starts sometime in 2022, presumably after pay-as-you-go functionality is fully operational and ready on all exit gates.
Meanwhile, IDFM has been in talks with Apple ever since Smart Navigo was first announced in 2017. At that time they said:
“Unfortunately, it won’t be possible for iPhone owners to use the service since Apple does not yet allow third parties to access the NFC secure element in their phones. However, we are happy to explore the possibilities with Apple to offer the same service to all Paris public transport users.
One last thing: smart wearables won’t work with a HCE only Smart Navigo strategy. This is the lesson that Fitbit and Garmin have learned well from Apple Watch for deploying Mobile Suica on their devices: keep things simple and on the device for local processing without a network connection. This is what makes the Suica support coming to WearOS so interesting, it might succeed in beating Android as the first non-Apple global NFC device.
As for Smart Navigo, indeed a step forward, a step back. The IDFM journey to mobile ticketing for everybody is not a long quiet river.
This concludes the final installment Contactless Payment Turf Wars. It has been an unexpectedly longer series than planned. I hope people enjoyed reading them as much as I enjoyed writing them. Thanks always and happy transits!
Have you ever noticed that ramen shops in Japan kinda stick together? If there is one, there is another one close by, maybe two or three. And not just ramen shops, it can be Japanese sweets, eateries, anything. This might seem strange at first but there is a well known traditional Japanese business sense behind it. Two is better than one because more choices drives more foot traffic and interest. ‘Hey lets go to the local ramen shop district and get something to eat.’ The common interest is why store rivals tolerate each other because the increased customer interest and traffic drives business for everybody. All boats rise together.
I was reminded of this when a Japanese friend scolded me for constantly putting down code payments like PayPay when the speed and ease of Suica is so superior. “Why is it westerners always see things as black and white? Lots of choices drives interest right?” He was right of course. Coming from a western mindset it’s too easy to fall into the same old double standard of saying more choice is better on one hand, while on the other insisting that we should only use one thing. The old one size fits all, my choices are the best for everyone.
I also think there’s another, much larger and unacknowledged cultural difference regarding the concept of service: the Japanese mind tends to think of good service as being offered many options, while the western mind tends to think of good service as fulfilling one’s personal needs and wants of the moment. It may seem like a small difference but it’s a completely different way of seeing things. It’s also a good reminder that what’s convenient to our person is not necessarily convenient to other people.
One size doesn’t fit all. What’s the point of having all that different hardware when everybody’s forced to use the same software? Lots of choices for lots of people works better in the end…it drives interest in mobile payments when there are still a lot of people in Japan who have yes to use anything but plastic or cash. Variety invites and lifts all boats.
You must be logged in to post a comment.