Leveraging the payment networks for immunity passports

COVID-19

As if lockdown were not bad enough, many of us are now faced with spending the next year with children unable to spend their Gap Year travelling the more exotic parts of the world. The traditional jobs within the entertainment and leisure sectors that could keep them busy, and paid for their travel, are no longer available. The opportunity to spend time with elderly relatives depends on the results of their last COVID-19 test.

I recognize that we are a lucky family to have such ‘problems’. However, they are representative of the issues we all face as we work hard to bring our families, companies and organizations out of lockdown. When can we open up our facilities to our employees, customers and visitors? What protection should we offer those employees that must or choose to work away from home? What is the impact of the CEO travelling abroad to meet new employees or customers, sign that large deal or deliver the keynote at that trade fair in Las Vegas?

It is no longer unusual for a company in the City to regularly test its employees before allowing them to work in their offices and support the additional costs of their commute avoiding public transport.

Billions are being invested in vaccine research and tests to confirm that we have the antibodies to protect us and those with whom we interact. But will that be sufficient? Will it allow you to visit your relatives in the care home, sit inside your favorite restaurant, work in close proximity to your colleagues and/or travel without the need to quarantine for 14 days when you arrive and/or return?

Experience would suggest that over the next year or so a variety of vaccinations and tests will be released, which will work to a greater or lesser extent. The question will be: ‘is the vaccination, or test, recognized by the venue (and their insurers), or country, which you are trying to enter?’

For some organizations, the fact that the COVID-19 tracing application on your phone turns green, will be sufficient. Others will only recognize specific vaccinations and tests and will want to check that the immunizations are still valid. Both will be concerned by the availability of fake immunity certificates. Thus, in parallel with the medical developments, we have to implement a robust and efficient method of sharing and remotely validating the immunity certificates or passports that they will deliver.

Those of us who regularly travel in North Africa and South America are used to handing over our yellow International Certificate of Vaccination or Prophylaxis (ICVP), with our passport, to prove that we had yellow fever vaccine. This program, which is governed by International Health Regulations, could provide the governance framework for the operation of the COVID-19 immunity passports.

Over the last few months, Consult Hyperion has proven that the contactless payment networks, which allow you to use your credit or debit card anywhere in the world, can also be used to share and remotely validate your COVID-19 immunity passport.

Our idea is that anywhere you can use your payment card you can also validate that you have the required immunity to enter the building or country. As with your payment transaction, an organization can choose whether or not to accept your immunity passport based on the:

  • Issuer of the immunity passport
  • Vaccinations and/or tests administered
  • Date when the vaccinations and/or tests were administered
  • Potential that the passport is a fake or you are not the genuine passport holder

If required, the organization can also revert to the issuer of the immunity passport to check there and then that your passport is still valid.

The consumer experience delivered by the immunity passport is similar to that of a contactless, Apple Pay or Google Pay transaction. The immunity passport is stored in a secure application in your smartphone or biometric smartcard. When asked to prove your Immunity Status you use your fingerprint to authenticate yourself to your phone/card and then touch your phone/card to a contactless reader. An application on the reader validates your immunity passport and passes only the required information to the restaurateur, owner of the care home or office or border control officer.

From the international community’s perspective, the payment infrastructure over which the immunity passports are shared and remotely validated is in place, proven and robust. It is supported by a raft of rules administered by PCI, which protect the security of personal information, at rest and in flight, within the system. There is an active marketplace for cheap, certified readers, operating secure protocols, which offer Contact Free validation of the immunity passport away from the classical point of sale locations. These include mPOS and SoftPOS solutions which allow a standard mobile phone to be used as a contactless payment terminal, and ruggedized terminals used to validate tickets in high traffic areas, such as the entrance to sports arenas and concert venues.

While the world waits to see if the science supports the ability to establish immunity to COVID-19, and society works through the implications of immune people being able to avoid restrictions which apply to others, we technologists need to prepare the infrastructure that will allow people to share and validate immunity passports.

One of the things I love about working at Consult Hyperion is that we regularly come up with, and deliver, ideas that significantly impact people’s lives – contact and contactless payment cards (worldwide), M-PESA (Kenya), Open Loop Transit Ticketing (London) and more recently SoftPOS (London), just to mention a few. Something tells me that immunity passports will be the next. If you are interested and would like to help deliver the network that will allow life to return to something close to ‘old normal’, please let me know.

Identity – Customer Centric Design

The team put on an excellent webinar this Thursday (May 21st, 2020) in the Tomorrow’s Transactions series. The focus was on Trust over IP, although digital identity and privacy were covered in the round.

The panellists were Joni Brennan of the DIACC (Digital ID & Authentication Council of Canada—full disclosure: a valued customer), long-time collaborator Andy Tobin of Evernym and our own Steve Pannifer and Justin Gage. Each of the panellists is steeped in expertise on the subject, gained from hard-won experience.

Joni and Andy presented, respectively, the DIACC and ToIP layered architectural models (largely congruent) for implementing digital identification services. The panellists agreed that no service could work without fully defined technical, business and governance structures. Another key point was that the problems of identification and privacy merge into one another. People need to make themselves known, but are reserved about making available a slew of personal information to organisations with whom they may seek no persistent relationship or do not fully trust.

At one point, it was mentioned that practical progress has been slow, even though the basic problem (to put one aspect crudely, why do I need so many passwords?) of establishing trust over digital networks has been defined for 20 years at least. It could be argued that Consult Hyperion has earned its living by designing, developing and deploying point solutions to the problem. I began to wonder why a general solution has been slow to arise, and speculated (to myself) that it was because the end-user has been ill-served. In particular, the user sign-up and sign-in experiences are inconsistent and usually horrible.

Therefore, I posed the question “What is the panel’s vision for how people will gain access to personalised digital services in 2030?” The responses were interesting (after momentary intakes of breath!) but time was short and no conclusions were reached.

I slept on the problem and came up with some tentative ideas. Firstly, when we are transacting with an organisation (from getting past a registration barrier to download some info, through buying things, to filing tax returns), everything on our screens is about the organisation (much of it irrelevant for our purposes) and nothing is about us. Why can’t our platforms present a prominent avatar representing us, clickable to view and edit information we’ve recorded, and dragable onto register, sign-in or authorise fields in apps or browsers?

Now, there could be infinite variations of ‘me’ depending on how much personal information I want to give away; and the degree of assurance the organisation needs to conduct business with me (of course, it’s entirely possible there could be no overlap). I reckon I could get by with three variations, represented by three personas:

  • A pseudonym (I get tired of typing flintstone@bedrock.com just to access a café’s wifi; there are some guilty parties registering for our webinars too!)
  • Basic personal information (name, age, sex, address) for organisations I trust, with a need-to-know
  • All of the above, maybe more, but (at least, partly) attested by some trusted third party.

Obsessives could be given the ability to define as many options, with as many nuances, as they like; but complexity should be easily ignorable to avoid clutter for the average user.

I think it’s the major operating system providers that need to make this happen: essentially, Apple, Android and Microsoft, preferably in a standard and portable way. For each we would set up an ordered list of our preferred authentication methods (PIN, facial recognition, etc) and organisations would declare what is acceptable to them. The system would work out what works for both of us. If the organisation wants anything extra, say some kind of challenge/response, that would be up to them. Hopefully, that would be rare.

The Apple Pay and Google Pay wallets are some way to providing a solution. But sitting above the payment cards and boarding passes there needs to be the concept of persona. At the moment, Apple and Google may be too invested in promulgating their own single customer views to see the need to take this extra step.

I sensed frustration from the panellists that everything was solvable, certainly technically. Governance (e.g. who is liable for what when it all goes wrong?) was taken to be a sticking point. True, but I think we need to put the average user front and centre. Focus groups with mocked-up user experiences would be a good start; we’d be happy to help with that!

Would you use the NHSX app?

I listened with interest to yesterday’s parliamentary committee on the proposed NHSX contact tracing app, which is being trialled on the Isle of Wight from today. You can see the recording here.

Much of the discussion concerned the decision to follow a centralised approach, in contrast to several other countries such as Germany, Switzerland and Ireland. Two key concerns were raised:

1. Can a centralised system be privacy respecting?
Of course the answer to this question is yes, but it depends on how data is collected and stored. Cryptographic techniques such as differential privacy are designed to allow data to be de-indentified so that is can be analysed anonymously (e.g. for medical research) for example, although there was no suggestion that NHSX is actually doing this.

The precise details of the NHSX app are not clear at this stage but it seems that the approach will involve identifiers being shared between mobile devices when they come into close proximity. These identifiers will then be uploaded to a central service to support studying the epidemiology of COVID-19 and to facilitate notifying people who may be at risk, having been in close proximity to an infected person. Whilst the stated intention is for those identifiers to be anonymous, the parliamentary debate clearly showed there a number of ways that the identifiers could become more identifiable over time. Because the identifiers are persistent they are likely to only be pseudonymous at best.

By way of contrast, a large team of academics has developed an approach called DP-3T, which apparently has influenced designs in Germany and elsewhere. It uses ephemeral (short-lived) identifiers. The approach is not fully decentralised however. When a user reports that they have COVID-19 symptoms, the list of ephemeral identifiers that user’s device has received, when coming into close proximity to other devices, is shared via a centralised service. In fact, they are broadcast to every device in the system so that risk decisioning is made at the edges not in the middle. This means that no central database of identifiers is needed (but presumably there will be database of registered devices).

It also means there will be less scope for epidemiological research.

All of this is way beyond the understanding of most people, including those tasked with providing parliamentary scrutiny. So how can the average person on the street or the average peer in Westminster be confident in the NHSX app? Well apparently the NHSX app is going to be open sourced and that probably is going to be our greatest protection. That will mean you won’t need to rely on what NHSX says but inevitably there will be universities, hackers, enthusiasts and others lining up to pick it apart.

2. Can a centralised system interoperate with the decentralised systems in other countries to allow cross border contact tracing?
It seems to us that whether a system is centralised or not is a gross simplification of the potential interoperability issues. True, the primary issue does seem to be the way that identifiers are generated, shared and used in risk decisioning. For cross border contact tracing to be possible there will need to be alignment on a whole range of other things including technical standards, legal requirements and perhaps even, dare I say it, liability. Of course, if the DP-3T model is adopted by many countries then it could become the de facto standard, in which case that could leave the NHSX app isolated.

Will the NHSX app be an effective tool to help us get back to normal? This will depend entirely on how widely it is adopted, which in turn will require people to see that the benefits outweigh the costs. That’s a value exchange calculation that most people will not be able to make. How can they make a value judgment on the potential risks to their civil liberties of such a system? The average user is probably more likely to notice the impact on their phone’s battery life or when their Bluetooth headphones stop working.

There’s a lot more that could be said and I’ll be discussing the topic further with Edgar WhitleyNicky Hickman and Justin Gage on Thursday during our weekly webinar.

Counterintuitive Cryptography

There was a post on Twitter in the midst of the coronavirus COV-19 pandemic news this week, that caught my eye. It quoted an emergency room doctor in Los Angeles asking for help from the technology community, saying “we need a platform for frontline doctors to share information quickly and anonymously”. It went on to state the obvious requirement that “I need a platform where doctors can join, have their credentials validated and then ask questions of other frontline doctors”.

This is an interesting requirement that tell us something about the kind of digital identity that we should be building for the modern world instead of trying to find ways to copy passport data around the web. The requirement, to know what someone is without knowing who they are, is fundamental to the operation of a digital identity infrastructure in the kind of open democracy that we (ie, the West) espouse. The information sharing platform needs to know that the person answering a question has relevant qualifications and experience. Who that person is, is not important.

Now, in the physical world this is an extremely difficult problem to solve. Suppose there was a meeting of frontline doctors to discuss different approaches and treatments but the doctors wanted to remain anonymous for whatever reason (for example, they may not want to compromise the identity of their patients). I suppose the doctors could all dress up as ghosts, cover themselves in bedsheet and enter the room by presenting their hospital identity cards (through a slit in the sheet) with their names covered up by black pen. But then how would you know that the identity card belongs to the “doctor” presenting it? After all the picture on every identity card will be the same (someone dressed as a ghost) and you have no way of knowing whether it was their ID cards or whether they were agents of foreign powers, infiltrators hellbent on spreading false information to ensure the maximum number of deaths. The real-world problem of demonstrating that you have some particular credential or that you are the “owner” of a reputation without disclosing personal information is a very difficult problem indeed.

(It also illustrates the difficulty of trying to create large-scale identity infrastructure by using identification methods rather than authenticating to a digital identity infrastructure. Consider the example of James Bond, one of my favourite case studies. James Bond is masquerading as a COV-19 treatment physician in order to obtain the very latest knowledge on the topic. He walks up to the door of the hospital where the meeting is being held and puts his finger on the fingerprint scanner at the door… at which point the door loudly says “hello Mr Bond welcome back to the infectious diseases unit”. Oooops.)

In the virtual world this is quite a straightforward problem to solve. Let’s imagine I go to the doctors information sharing platform and attempt to login. The system will demand to see some form of credential proving that I am a doctor. So I take my digital hospital identity card out from my digital wallet (this is a thought experiment remember, none of the things actually exist yet) and send the relevant credential to the platform.

The credential is an attribute (in this case, IS_A_DOCTOR) together with an identifier for the holder (in this case, a public key) together with the digital signature of someone who can attest to the credential (in thsi case, the hospital the employs the doctor). Now, the information sharing platform can easily check the digital signature of the credential, because they have the public keys of all of the hospital and can extract the relevant attribute.

But how do they know that this IS_A_DOCTOR attribute applies to me and that I haven’t copied it from somebody else’s mobile phone? That’s also easy to determine in the virtual world with the public key of the associated digital identity. The platform can simply encrypt some data (anything will do) using this public key and send it to me. Since the only person in the entire world who can decrypt this message is the person with the corresponding private key, which is in my mobile phone’s secure tamper resistant memory (eg, the SIM or the Secure Enclave or Secure Element), I must be the person associated with the attribute. The phone will not allow the private key to be used to decrypt this message without strong authentication (in this case, let’s say it’s a fingerprint or a facial biometric) so the whole process works smoothly and almost invisibly: the doctor runs the information sharing platform app, the app invisibly talks to the digital wallet app in order to get the credential, the digital wallet app asks for the fingerprint, the doctor puts his or her finger on the phone and away we go.

Now the platform knows that I am a doctor but does not have any personally identifiable information about me and has no idea who I am. It does however have the public key and since the hospital has signed a digital certificate that contains this public key, if I should subsequently turn out to be engaged in dangerous behaviour, giving out information that I know to be incorrect, or whatever else doctors can do to get themselves disbarred from being doctors, then a court order against the hospital will result in them disclosing who I am. I can’t do bad stuff.

This is a good example of how cryptography can deliver some amazing but counterintuitive solutions to serious real-world problems. I know from my personal experience, and the experiences of colleagues at Consult Hyperion, that it can sometimes be difficult to communicate just what can be done in the world of digital identity by using what you might call counterintuitive cryptography, but it’s what we will need to make a digital identity infrastructure that works for everybody in the future. And, crucially, all of the technology exists and is tried and tested so if you really want to solve problems like this one, we can help right away.

The “isRecovered?” attribute

So far the tech giants seem to be the coronavirus winners, with a massive surge in digital communications and online orders. The impact on lift sharing companies is less clear.

The guidance from both Uber and Lyft says that if they are notified (by a public health authority) that a driver has COVID-19 they may temporarily suspend the driver’s account. It is not exactly clear how this would work.

That got us wondering whether digital identity systems, that we spend so much time talking about, could help. It seems to me there are two potential identity questions here:

1.       Is the driver who Uber or Lyft thinks it is?

2.       Does the driver have coronavirus?

The first question should be important to Uber and Lyft at any time. Ok, for the moment they want to be sure that they know who is driving to give them a better chance of knowing if the driver has the disease. But there are all sorts of other reasons why they might want to be sure that the driver is who they think it is – can the person legally drive for one.

The second question is harder. Just because the driver doesn’t have the virus today, doesn’t mean he or she won’t have it tomorrow. Maybe, perhaps the ability to share an isRecovered? attribute that says “I’ve recovered from the illness” would be useful when we start to see the light at the end of this tunnel we are entering. And the ability to share that anonymously might be helpful too – providing assurance to both driver and passenger.

All this to one side, the guidance from both Uber and Lyft outlines financial measures they are putting in place to provide security to drivers that self-isolate. That is a great example of responsibility providing the incentive and support required to allow their drivers to do the right thing.

KYC at a distance

We live in interesting times. Whatever you think about the Coronavirus situation, social distancing will test our ability to rely on digital services. And one place where digital services continue to struggle is onboarding – establishing who your customer is in the first place.  

One of the main reasons for this, is that regulated industries such as financial services are required to perform strict “know your customer” checks when onboarding customers and risk substantial fines in the event of compliance failings. Understandably then, financial service providers need to be cautious in adopting new technology, especially where the risks are not well understood or where regulators are yet to give clear guidance.

Fortunately, a lot of work is being done. This includes the development of new identification solutions and an increasing recognition that this is a problem that needs to be solved.

The Paypers has recently published its “Digital Onboarding and KYC Report 2020”. It is packed full of insights into developments in this space, features several Consult Hyperion friends and is well worth a look.

You can download the report here: https://thepaypers.com/reports/digital-onboarding-and-kyc-report-2020

Technology and Trust @ Money2020

Online trust is a pretty serious issue, but it’s not alway easy to quantify. We all understand that it is important, but what exactly is the value in pounds, shillings and pence (or whatever we will be using after Brexit) and how can we use that value to develop some business cases? It’s one thing to say (as you will often hear at conferences) that some technology or other can increase trust, but how do we know whether that means it is worth spending the money on it? At Consult Hyperion we have a very well-developed methodology, known as Structured Risk Analysis (SRA), for managing risk and directing countermeasure expenditures, but we need reasonable, informed estimates to make it work.

The specific case of online reviews might be one area where trust technologies can be assessed in a practical way. In the UK, the Competition and Markets Authority (CMA) estimates that a staggering £23bn a year of UK consumer spending is now influenced by online customer reviews and the consumer organisation Which has begun a campaign to stop fake reviews from misdirecting this spending. According to their press office, with “https://press.which.co.uk/whichpressreleases/revealed-amazon-plagued-with-thousands-of-fake-five-star-reviews/“, fake reviews are a very serious problem.

Unscrupulous businesses undoubtedly find fake reviews an incredibly useful tool. There are millions of examples we could use to illustrate this, but here is just one.”Asad Malik, 38, used fake reviews and photographs of secure car parks hundreds of miles away to trick customers into leaving their vehicles with him when they flew from Gatwick [Airport parking boss jailed for dumping cars in muddy fields].

So how can we use technology to make a difference here? When you read a review of an airport parking service, or a restaurant or a Bluetooth speaker, how can you even be sure (to choose the simplest example) that the reviewer purchased the product? Well, one possibility might be to co-opt the payment system: and this can be done in a privacy-enhancing way. Suppose when you pay the bill at a restaurant, and you have told your credit card provider that you are happy to be a reviewer, your credit card company sends you an unforgeable cryptographic token that proves you ate at the restaurant. Then, when you go to Tripadvisor or wherever, if you want to post a review of the restaurant, you have to provide such a token. The token would be cryptographically-blinded so that the restaurant and review-readers would not know who you are, so you could be honest, but they could be sure that you’ve eaten there.

Such “review tokens” are an obvious thing to store in digital wallets. You could easily imagine Calibra, to choose an obvious case study, storing these tokens and automatically presenting them when you log in to review sites. This would be a simple first step toward a reputation economy that would benefit consumers and honest service providers alike.

This is one of the cross-overs between payments and identity that we expect to be much discussed at Money20/20 in Las Vegas this week. I’ll be there with the rest of the Consult Hyperion team, so do come along to the great, great Digital Trust Track on Tuesday 29th and join in the discussions.

4 Essential Trends in Money for your Business

By Sanjib Kalita, Editor-in-Chief, Money20/20

This article was originally published on Money20/20.

We are in the midst of seismic societal changes of how people interact and transact.  Across societies, geographies and segments, digital is the new norm. Change has accelerated, placing greater value upon flexibility and speed. Historically, money and finance have been among the more conservative and slower changing parts of society, but this has changed dramatically over the past decade by viewing money as an instigator of change rather than a lagging indicator.

Whether you are a marketer in shining armor conquering new territory, a financial wizard casting spells upon the balance sheet, or the queen or king guiding the whole enterprise, here are 4 trends about money that you should keep in mind for your business.

Platforms are the new kingdoms

Platforms are the base upon which other structures can be built.  For example, App stores from Apple and Google provide the infrastructure for consumers to complete commercial transactions and manage finances through their mobile phones.  While these companies develop their own digital wallets, they also enable similar services from banks, retailers and other companies.  Building and maintaining the platform enables services that they would not have created on their own, like Uber or Lyft, which in turn, have created their own platforms.

Marketers trying to address customers’ needs can plug into platforms to broaden offerings or deepen engagement with target markets. Platform-based thinking implies that product and service design is ongoing and doesn’t stop with a product launch.  Jack Dorsey didn’t stop when he built the Square credit card reader.  The team went into lending with Square Capital.  They got into consumer P2P payments with Square Cash.  Their ecosystem has grown through partnerships with other companies as well as in-house development.

Digital Identities open the gates

How do your customers interact with you?  Do they need to create a username and password, or can they use a 3rd party system like Google or Facebook?  Are security services like two-factor authentication or biometrics used to protect credentials?  Is your company protecting customer identities adequately?  The importance of all of these questions is increasing and often the difference between being forced into early retirement by a massive data breach or surviving to continue to grow your business.

While identity management and digital security might not be top of mind for most marketers, they are table stakes for even the most basic future business.  History is full of tales of rulers successfully fighting off armies laying sieges on castles and fortresses, only to fail when another army gets access to a key for the back door.

Context rules the experience

Credit card transactions moved from predominantly being in-store, to e-commerce sites accessed from desktop computers, and now to mobile phones.  As the point-of-purchase expanded, so did the consumer use cases and thought processes. In tandem, mobile screens presents less information than desktop computer screens, which in turn presents less information than associates in a brick-and-mortar environment.  Companies best able to understand context and deliver the right user experience within these constraints will build loyal customer relationships.

Apps or services created for a different use cases on the same platform, such as Facebook and Messenger apps, can help achieve this. Banks and have different apps for managing accounts or for completing transactions or payments. On a desktop, you can access these services through a single interface but on the mobile, forcing users to select their use case helps present a streamlined experience on the smaller, more time-constrained mobile screen.  The use of additional data such as location, device, etc. can further streamline the experience. Marketers that don’t think about the context will lose the battle before it even begins.

Data is gold

While a marketer’s goal is to generate sales, data has become a value driver.  In the financial world, data about payments, assets and liabilities has become critical in how products and services are delivered.  PayPal, a fintech that began even before the word ‘fintech’, has recently been using payments data from their platform to help build a lending business for their customers.  Similarly, an SME lender named Kabbage has grown to unicorn status by using data from other sources to make smarter lending and pricing decisions.  In the payments industry, Stripe distilled a previously complex technology integration into a minimal data set, accessed via API, to easily build payments into new digital products and services.

Those that are able to harness the power of data will be able to predict what customers want and more effectively address their needs.  In some cases, it might be using data from within your enterprise or from other platforms for targeting, pricing or servicing decisions. In other cases, it might be using data to reimagine what your product or service is.

Looking for more insights on key trends in money? Hear from 400+ industry leaders at Money20/20 USA. Money20/20 USA will be held on October 27-30, 2019 at The Venetian Las Vegas. To learn more and attend visit us.money2020.com.

This article was originally published on www.money2020.com.

IdentityNORTH 2019

We recently attended IdentityNORTH in Toronto and as usual it was a great event to connect with colleagues and hear about what’s going in with digital identity initiatives in Canada. Aran, Krista and the entire IdentityNORTH team always put on an organized, well-run event with lots of great speakers and interesting sessions.

The spirit of collaboration around digital identity in Canada is one of the strongest we’ve seen, especially in North America. Both the public and private sectors have a genuine interest in working together, and this is seen primarily through the great work being done at the Digital ID and Authentication Council of Canada (DIACC) to bring together a wide variety of stakeholders, industries and even different levels of government (e.g. federal, provincial, municipal) to work together towards a common goal. Work has been ongoing for a few years now to build a Pan-Canadian Trust Framework (PCTF) that will enable businesses, citizens and governments alike to have a common understanding of what it means to be part of a digital identity ecosystem and what is considered the standard in Canada of a well-designed, secure and privacy-respecting identity system. DIACC has released an initial version of the PCTF and is soliciting public feedback. They also announced a timeline for ongoing public releases of more detailed components of the framework taking place throughout the rest of 2019 and into next year. We are encouraged to see this progress and look forward to seeing this framework evolve over the coming year.

The other major highlight from the event was to see a variety of live demos and nearly market ready solutions from various organizations. In past events, we’ve seen a lot “coming soon” presentations, wireframes or mockups. But this year, there was a decidedly heavier live demo presence and quite a few solutions that have either launched or are launching soon. Some of the solutions presented included:

  • Verified.Me by SecureKey, a mobile identity service used to verify and share personal information online, in person and on the phone. It was developed in cooperation with major Canadian financial institutions who act as “Service Hosts” to verify and authenticate End Users. End Users can also connect with other identity and data providers who generate or hold information about them (e.g. MNOs and credit bureaus), and safely and securely share certain information with service providers and relying parties (e.g. online merchants, insurance brokers, or other providers conducting account opening or confirming service eligibility).
  • 2Keys and Interac presented a live demo of a digital wallet proof of concept sponsored by the Ontario Centres Of Excellence which demonstrated age verification for buying cannabis or liquor online.
  • Niagara Health Navigator by Identos for the Niagara Health regional authority, a digital health ecosystem designed to protect patient privacy and security while connecting patients to their health data, care providers and innovators.
  • eID-Me by Bluink, a mobile identity verification and digital identity wallet with demonstrated use cases in healthcare (fast check-in and electronic medical record integration) and car sharing (owner registration and vehicle unlocking).
  • BC Government demonstrated enabling a Mobile BC Services Card via remote video chat, through a mobile app. The app allows a citizen to identify themselves over video and means they don’t need to visit a location in person to apply for services. An initial trial was launched last year to make it easier for students to apply for aid with the mobile BC Services Card.

With all these new solutions and service offerings, interoperability seems to be one of the new buzz words. As more products are introduced to the market, there will be a need for broader industry cooperation across sectors, and likely across international borders. As mentioned in our previous post on digital identity technical and assurance standards, it will be important to watch these developments as they continue to evolve.

Lastly, it wasn’t all work with no fun as we even got in a visit to Jurassic Park, the Toronto Raptors fan zone during the NBA Finals. It was a bit wet and rainy but that didn’t stop the crowd from being quite enthusiastic!

SCA: the end of merchant liability, and other authentication factors

The EBA’s recent Opinion on the elements of strong customer authentication under PSD2 was, apart from moving the goalposts on when SCA will be enforced, full of interesting information about what constitutes a valid SCA element. It closes some doors, opens others and ends any notion that merchants can take liability and not do SCA themselves.

Taking the final point first, there’s been a view that Article 74(2) of PSD2 permits merchants to carry on without implementing SCA as long as they take liability. We at Consult Hyperion have long argued that that is an optimistic and overly legalistic reading of the regulations and this has now been confirmed. The EBA states:


In addition, even if there were a liability shift to the payee or the payee’s PSP for failing to accept SCA, as articulated in Article74(2) of PSD2, this could not be considered an alleviation of PSPs’ obligation to apply SCA in accordance with and as specified in Article 97 of PSD2.

Basically, Article 97 takes precedence – PSPs (aka Issuers) must apply SCA so if the merchant chooses not to then rather than end up with a payment for which they’re liable they’ll end up with no payment at all. Which, you’d imagine, would rather miss the point of being a merchant.

Beyond this point the Opinion has lots of interest to say about inherence, possession and knowledge elements.

On inherence two points stand out. Firstly the Opinion unambiguously states that behavioural biometrics can be a valid factor: this opens up a world of possible low friction SCA, and we expect to see lots of innovation in this area. Secondly it states that 3DS-2 does not support inherence as none of the data points being gathered relate to biological or behavioural biometrics but – and we view this as important – 3DS-2 is a valid means of supporting SCA.

This is critical because the dynamic linking process behind 3DS-2 is not straightforward and there have been differences of opinion over whether this is compliant. Given that 3DS-2 appears to be the only game in town for CNP transactions having a statement that it’s OK is mighty important.

On possession, the EBA clarifies that OTP SMS is valid and also that mobile app based approaches can be – but only if the app is linked to the device. We’ve been arguing that this is obviously the case for a while, so it’s good to see this confirmed: although there are going to be a few app developers out there that need to revise their approaches pdq (we can help, of course!).

Also on possession the EBA has stated something that really should have been obvious to anyone taking more than a moderate interest in the topic – printed card details such as PAN and CVV or user ids and email addresses are not valid possession or knowledge elements. As a number of prominent industry players have been taking the opposite approach this could lead to some interesting developments in the coming weeks, particularly as the Opinion states that if the CVV is not printed on the card and is instead sent on a separate channel, then it is a valid knowledge element.

Overall, the analysis and discussion in the Opinion on valid SCA elements is welcome, if a trifle tardy. To be fair to the EBA, we don’t see anything in their analysis that a proper reading of the RTS wouldn’t have produced. However, it’s been clear for some time that many industry players have been making a highly liberal interpretation of the requirements usually based on a legal opinion. But PSD2 and the RTS are about principles, not rules: if you need advice on this you need to talk to the people who understand this stuff. Which, by the way, is us, not law firms.