Identity-Bound Non-Person Entities

In my writings on non-person entities (NPEs), I have mentally assumed that NPEs go their own way and do their own thing, separate from people. So while I (John Bredehoft) have one set of permissions, the bot N. P. E. Bredemarket has “his” own set of permissions.

Not necessarily.

Anonybit and SmartUp have challenged my assumption, saying that AI agents could be bound to human identities.

“Anonybit…announced the first-ever live implementation of agentic commerce secured by decentralized biometrics, marking a significant milestone in the evolution of enterprise AI.

“Through a strategic partnership with SmartUp, a no-code platform for deploying enterprise AI agents, Anonybit is powering authenticated, identity-bound agents in real-world order, payment, and supply chain workflows….

“Anonybit’s identity token management system enables agents to operate on behalf of users with precise, auditable authorization across any workflow—online, in-person, or automated.”

So—if you want to—all your bot buddies can be linked to you, and you bear the responsibility for their actions. Are you ready?

(Imagen 4)

What is the Form I-9?

I am clearly not the Form I-9 expert—see Janice Kephart and her company ZipID for the full understanding. But this introduces why we have the U.S. Form I-9, how it keeps employers and employees within the law, and what it can do to stop North Koreans from robbing companies blind.

Why

Someone can’t just waltz into a U.S. employer and start working. Legally, anyway.

While there are numerous requirements that you have to meet before starting a job, the one that concerns us here is that only certain people are legally authorized to work.

To check this is a two part process:

  • To check the identity of the person.
  • To check the employment authorization of the person.

Both are necessary. It does no good to determine that Sam Smith is authorized if Sam Smith is really Kim Jong Spy.

Now you don’t have to be a U.S. citizen to work here. I’ve worked with a number of green card holders from France and other countries. I’ve worked with a number of temporary visa holders in which the visa permits the person to work for pay.

But student visa holders usually can’t work.

And people who are just visiting the country usually can’t work.

And finally, people who slip across the border can’t work.

How

So how do we make sure that people who work here are identified and authorized?

Via the completion of the U.S. Citizenship and Immigration Services Form I-9.

“Use Form I-9, Employment Eligibility Verification, to verify the identity and employment authorization of individuals hired for employment in the United States. All U.S. employers must properly complete Form I-9 for every individual they hire for employment in the United States. This includes citizens and aliens. Both employees and employers (or authorized representatives of the employer) must complete the form.”

The employee starts the ball rolling by proving that they are who they say they are, and that they are authorized to work here. To do this, they provide information and documents, including at least some of the following:

  • Full name
  • Address
  • Date of birth
  • Social Security Number (not a Taxpayer Identification Number)
  • U. S. citizenship or immigration status (there are multiple options here, ranging from U.S. citizen to “alien authorized to work”)
  • Other numbers as necessary, such as a USCIS number
  • One or more of “List A,” “List B,” and/or “List C” documents

The most powerful of the acceptable documents are List A documents, which prove both identity and employment authorization. A U.S. Passport or a Permanent Resident Card are the most common documents here, but if you have a passport from the Federated States of Micronesia you may still be good to go.

Passport, Federated States of Micronesia.
Blagomeni • CC BY-SA 3.0. Source.

If you don’t have a List A document, then you need one List B (identity) and one List C (authorization) document.

  • List B includes driver’s licenses (REAL ID or no, even Canadian), school ID cards, voter IDs, tribal documents, and others that establish identity in some way.
  • List C includes Social Security cards, birth certificates, and other authorization documents.

After the employee provides all this and completes Section 1 of Form I-9, the employer checks it and completes Section 2 of the form. The documentation must “reasonably” appear to be genuine. 

What

But…if this whole system relies on the employer saying “looks good to me,” how does this keep Kim Jong Spy from illegally working at Palantir and stealing state secrets and American technology?

One, the information and the document checks are worth something. While an employer is unable to truly verify that a driver’s license or a passport is not fraudulent—especially if the remote employee never visits the employer in person—you can bet that USCIS checks all those numbers, and if 10 people use the same Social Security Number they will be flagged.

Two, employers that repeatedly flaunt U.S. employment law can get in trouble. As I detailed in a LinkedIn post, this could include five years of prison time.

So that’s a powerful disincentive for unintentionally or intentionally hiring Kim Jong Spy.

And if the Form I-9 seems like a lot of work, and you wish you could automate it…see ZipID. In addition to everything else, it can compare a live face with the submitted photo ID…because.

Driver’s License Data and Third Party Risk Management

It gets real tomorrow, with the enforcement date (sort of) for REAL ID at federal installations and airports. But what about the privacy of the data behind REAL IDs?

Bela Kumar of Jumio Corporation was recently interviewed by CNBC for an article about REAL ID and the data sharing behind it.

As can be expected, some people are very concerned about what this means.

“[C]oncerns persist among privacy professionals that the next step will be a federal database of driver’s license information, which is bad from a privacy and cybersecurity standpoint, said Jay Stanley, a senior policy analyst with the American Civil Liberties Union.

“‘The more information the government has, the more the government might use that information,’ said Jodi Daniels, founder and chief executive of Red Clover Advisors, a privacy consulting company. ‘But that’s not what’s happening now,’ she added.”

Kumar addressed what IS happening now, and whether our personally identifiable information (PII) is protected.

“States have been issuing driver’s licenses for many years, and personal information is already being stored. The expectation is that the same controls apply to Real ID, said Bala Kumar, chief product and technology officer at Jumio, an online mobile payment and identity verification company. ‘States have already been managing this for many years,’ Kumar said.”

If you continue to read the article, you’ll also see a statement from the American Association of Motor Vehicle Administrators that echoes what Jumio said.

But as a former IDEMIA employee, my curiosity was piqued.

Has anyone ever gained unauthorized access to a state driver’s license database?

So I checked, and could not find an example of unauthorized access to a state driver’s license database.

But I DID find an example of unauthorized access to driver’s license DATA that was processed by a third party. The State of Louisiana issued a notice that included the following:

“On May 31, 2023, Progress Software Corporation, which developed and supports the MOVEIt managed file transfer platform, notified all customers across the globe, including [Louisiana Office of Motor Vehicles], of a zero-day vulnerability that an unauthorized party leveraged to access and acquire data without authorization. Upon learning of the incident, immediate measures were taken to secure the MOVEIt environment utilized to transfer files. A thorough investigation was conducted, and it was determined that there was unauthorized acquisition of and access to OMV files in the MOVEIt environment….

“The information varied by individual but included name and one or more of the following: address, date of birth, Social Security number, driver’s license, learner’s permit, or identification card number, height, eye color, vehicle registration information, and handicap placard information.”

Well, at least the hacked data didn’t include weight. Or claimed weight.

Cybersecurity professionals know that you cannot completely prevent these hacks. Which explains the “risk” in third party risk management. Progress Software has been around for a long time; I worked with Progress Software BEFORE I began my biometric career. But these hacks (in this case, CVE-2023-34362 as documented by CISA) can happen to anyone.

Be cautious, and remember that others with good intentions might not be cautious enough.

Saving Money When Filling Prescriptions: Not You, The Companies

Healthcare is complicated. When most of us receive prescriptions from our doctor, either the doctor gives us a physical slip of paper with the prescription, or the doctor electronically sends the prescription to your pharmacy of choice. After that, you deal with the pharmacy yourself. Normally it goes smoothly. Sometimes it doesn’t.

  • Maybe the patient’s insurance company doesn’t cover the prescription, or charges an exorbitant price for it.
  • Maybe the patient never picks the prescription up. (The industry term is “adherence.”)

There are a lot of companies that want to help drug companies, physicians, and others make this process more seamless and less costly (for example, by maximizing gross-to-net, or GTN).

How many companies want to help? One afternoon I estimated that 30 companies are in this market. Based upon past experience in the identity verification industry (namely, all those battlecards my team created), this means that there are probably really more than 100 companies in the market.

While the companies obviously have to please the patients who need the prescriptions, they’re not critically important because the patients (usually) don’t pay the companies for the improved service.

So the companies have to sell others on their services.

Alto Technologies: “Alto Technologies’ configurable platform integrates hub and dispensing capabilities into an automated and seamless single service provider solution that improves patient experience and reduces administrative burden.”

Medisafe: “Patient support begins with onboarding and continues throughout treatment, with intuitive guidance throughout every encounter. From initial prescription to benefits investigation and authorization to shipment tracking, patients receive streamlined support with educational information and real-time updates.”

Phil: “Streamline medication access for your patients and providers. Our digital hub platform empowers retail and specialty-lite manufacturers with an alternative channel solution…”

Truepill: “Whether you’re an established brand looking to reach your patients directly, or an emerging company planning your go-to-market strategy, Virtual Pharmacy is the digital pharmacy solution built to scale.”

Of course, there are many more.

And they all need to tell their stories…

On Attribute-Based Access Control

In this post I’m going to delve more into attribute-based access control (ABAC), comparing it to role-based access control (RBAC, or what Printrak BIS used), and directing you to a separate source that examines ABAC’s implementation.

(Delve. Yes, I said it. I told you I was temperamental. I may say more about the “d” word in a subsequent post.)

But first I’m going to back up a bit.

Role-based access control

As I noted in a LinkedIn post yesterday:

Back when I managed the Omnitrak and Printrak BIS products (now part of IDEMIA‘s MBIS), the cool kids used role-based access control.

My product management responsibilities included the data and application tours, so user permissions fell upon me. Printrak BIS included hundreds of specific permissions that governed its use by latent, tenprint, IT, and other staff. But when a government law enforcement agency onboarded a new employee, it would take forever to assign the hundreds of necessary permissions to the new hire.

Enter roles, as a part of role-based access control (RBAC).

If we know, for example, that the person is a latent trainee, we can assign the necessary permissions to a “latent trainee” role.

  • The latent trainee would have permission to view records and perform primary latent verification.
  • The latent trainee would NOT have permission to delete records or perform secondary latent verification.

As the trainee advanced, their role could change from “latent trainee” to “latent examiner” and perhaps to “latent supervisor” some day. One simple change, and all the proper permissions are assigned.

But what of the tenprint examiner who expresses a desire to do latent work? That person can have two roles: “tenprint examiner” and “latent trainee.”

Role-based access control certainly eased the management process for Printrak BIS’ government customers.

But something new was brewing…

Attribute-based access control

As I noted in my LinkedIn post, the National Institute of Standards and Technology released guidance in 2014 (since revised). The document is NIST Special Publication 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, and is available at https://doi.org/10.6028/NIST.SP.800-162.

Compared to role-based access control, attribute-based access control is a teeny bit more granular.

Attributes are characteristics of the subject, object, or environment conditions. Attributes contain information given by a name-value pair.

A subject is a human user or NPE, such as a device that issues access requests to perform operations on objects. Subjects are assigned one or more attributes. For the purpose of this document, assume that subject and user are synonymous.

An object is a system resource for which access is managed by the ABAC system, such as devices, files, records, tables, processes, programs, networks, or domains containing or receiving information. It can be the resource or requested entity, as well as anything upon which an operation may be performed by a subject including data, applications, services, devices, and networks.

An operation is the execution of a function at the request of a subject upon an object. Operations include read, write, edit, delete, copy, execute, and modify.

Policy is the representation of rules or relationships that makes it possible to determine if a requested access should be allowed, given the values of the attributes of the subject, object, and possibly environment conditions.

So before you can even start to use ABAC, you need to define your subjects and objects and everything else.

Frontegg provides some excellent examples of how ABAC is used in practical terms. Here’s a government example:

For example, a military officer may access classified documents only if they possess the necessary clearance, are currently assigned to a relevant project, and are accessing the information from a secure location.

Madame Minna Craucher (right), a Finnish socialite and spy, with her chauffeur Boris Wolkowski (left) in 1930s. By Anonymous – Iso-Markku & Kähkönen: Valoa ja varjoa: 90 kuvaa Suomesta, s. 32. (Helsinki 2007.), Public Domain, https://commons.wikimedia.org/w/index.php?curid=47587700.

While (in my completely biased opinion) Printrak BIS was the greatest automated fingerprint identification system of its era, it couldn’t do anything like THAT. A Printrak BIS user could have a “clearance” role, but Printrak BIS had no way of knowing whether a person is assigned to an appropriate project or case, and Printrak BIS’ location capabilities were rudimentary at best. (If I recall correctly, we had some capability to restrict operations to particular computer terminals.)

As you can see, ABAC goes far beyond whether a PERSON is allowed to do things. It recognizes that people may be allowed to do things, but only under certain circumstances.

Implementing attribute-based access control

As I noted, it takes a lot of front-end work to define an ABAC implementation. I’m not going to delve into that complexity, but Gabriel L. Manor did, touching upon topics such as:

  • Policy as Code
  • Unstructured vs. Structured Rules
  • Policy configuration using the Open Policy Administration Layer (OPAL)

You can read Manor’s thoughts here (“How to Implement Attribute-Based Access Control (ABAC) Authorization?“).

And there are probably ways to simplify some of this.

Biometric Product Marketers, BIPA Remains Unaltered

(Part of the biometric product marketing expert series)

You may remember the May hoopla regarding amendments to Illinois’ Biometric Information Privacy Act (BIPA). These amendments do not eliminate the long-standing law, but lessen its damage to offending companies.

Back on May 29, Fox Rothschild explained the timeline:

The General Assembly is expected to send the bill to Illinois Governor JB Pritzker within 30 days. Gov. Pritzker will then have 60 days to sign it into law. It will be immediately effective.

According to the Illinois General Assembly website, the Senate sent the bill to the Governor on June 14.

While the BIPA amendment has passed the Illinois House and Senate and was sent to the Governor, there is no indication that he has signed the bill into law within the 60-day timeframe.

So BIPA 1.0 is still in effect.

As Photomyne found out:

A proposed class action claims Photomyne, the developer of several photo-editing apps, has violated an Illinois privacy law by collecting, storing and using residents’ facial scans without authorization….

The lawsuit contends that the app developer has breached the BIPA’s clear requirements by failing to notify Illinois users of its biometric data collection practices and inform them how long and for what purpose the information will be stored and used.

In addition, the suit claims the company has unlawfully failed to establish public guidelines that detail its data retention and destruction policies.

From https://www.instagram.com/p/C7ZWA9NxUur/.

A Few Thoughts on FedRAMP

The 438 U.S. federal agencies (as of today) probably have over 439 different security requirements. When you add state and local agencies to the list, security compliance becomes a mind-numbing exercise.

  • For example, the U.S. Federal Bureau of Investigation has its Criminal Justice Information Systems Security Policy (version 5.9 is here). This not only applies to the FBI, but to any government agency or private organization that interfaces to the relevant FBI systems.
  • Similarly, the U.S. Department of Health and Human Services has its Health Insurance Portability and Accountability Act (HIPAA) Security Rule. Again, this also applies to private organizations.

But I don’t care about those. (Actually I do, but for the next few minutes I don’t.) Instead, let’s talk FedRAMP.

Why do we have FedRAMP?

The two standards that I mentioned above apply to particular government agencies. Sometimes, however, the federal government attempts to create a standard that applies to ALL federal agencies (and other relevant bodies). You can say that Login.gov is an example of this, although a certain company (I won’t name the company, but it likes to ID me) repeatedly emphasizes that Login.gov is not IAL2 compliant.

But forget about that. Let’s concentrate on FedRAMP.

Why do we have FedRAMP?

The Federal Risk and Authorization Management Program (FedRAMP®) was established in 2011 to provide a cost-effective, risk-based approach for the adoption and use of cloud services by the federal government. FedRAMP empowers agencies to use modern cloud technologies, with an emphasis on security and protection of federal information. In December 2022, the FedRAMP Authorization Act was signed as part of the FY23 National Defense Authorization Act (NDAA). The Act codifies the FedRAMP program as the authoritative standardized approach to security assessment and authorization for cloud computing products and services that process unclassified federal information.

From https://www.fedramp.gov/program-basics/.

Note the critical word “unclassified.” So FedRAMP doesn’t cover EVERYTHING. But it does cover enough to allow federal agencies to move away from huge on-premise server rooms and enjoy the same SaaS advantages that private entities enjoy.

Today, government agencies can now consult a FedRAMP Marketplace that lists FedRAMP offerings the agencies can use for their cloud implementations.

A FedRAMP authorized product example

When I helped MorphoTrak propose its first cloud-based automated biometric identification solutions, our first customers were state and local agencies. To propose those first solutions, MorphoTrak partnered with Microsoft and used its Azure Government cloud. While those first implementations were not federal and did not require FedRAMP authorization, MorphoTrak’s successor IDEMIA clearly has an interest in providing federal non-classified cloud solutions.

When IDEMIA proposes federal solutions that require cloud storage, it can choose to use Microsoft Azure Government, which is now FedRAMP authorized.

It turns out that a number of other FedRAMP-authorized products are partially dependent upon Microsoft Azure Government’s FedRAMP authorization, so continued maintenance of this authorization is essential to Microsoft, a number of other vendors, and all the agencies that require secure cloud solutions.

They can only hope that the GSA Inspector General doesn’t find fault with THEM.

Is FedRAMP compliance worth it?

But assuming that doesn’t happen, is it worthwhile for vendors to pursue FedRAMP compliance?

If you are a company with a cloud service, there are likely quite a few questions you are asking yourself about your pursuits in the Federal market. When will the upward trajectory of cloud adoption begin? What agency will be the next to migrate to the cloud? What technologies will be migrated? As you move forward with your business development strategy you will also question whether FedRAMP compliance is something you should pursue?

The answer to the last question is simple: Yes. If you want the Federal Government to purchase your cloud service offering you will, sooner or later, have to successfully navigate the FedRAMP process.

From https://www.mindpointgroup.com/blog/fedramp-compliance-is-it-worth-it.

And a lot of companies are doing just that. But with less than 400 FedRAMP authorized services, there’s obviously room for growth.

Bredemarket’s Name for the Sixth Factor of Authentication

Depending upon whom you ask, there are either three or five factors of authentication.

Unless you ask me.

I say that there are six.

Let me explain.

First I’ll discuss what factors of authentication are, then I’ll talk about the three factor and five factor school, then I’ll briefly review my thoughts on the sixth factor—now that I know what I’ll call it.

What are factors of authentication?

Before proceeding to factors of authentication, let’s review TechTarget’s definition of authentication.

Authentication is the process of determining whether someone or something is, in fact, who or what it says it is.

From https://www.techtarget.com/searchsecurity/definition/authentication

For purposes of this post I’m going to stay away from the “something” part and concentrate on the “someone” part.

For example, if Warren Buffett has a bank account, and I claim that I am Warren Buffett and am entitled to take money from that bank account, I must complete an authentication process to determine whether I am entitled to Warren Buffett’s money. (Spoiler alert: I’m not.)

So how do I authenticate? There are many different ways to authenticate, which can be grouped into several authentication factors. Here’s how Sumo Logic defines “authentication factor.”

An authentication factor is a special category of security credential that is used to verify the identity and authorization of a user attempting to gain access, send communications, or request data from a secured network, system or application….Each authentication factor represents a category of security controls of the same type. 

From https://www.sumologic.com/glossary/authentication-factor/

When considering authentication factors, the whole group/category/type definition is important. For example, while a certain system may require both a 12-character password and a 4-digit personal identification number (PIN), these are pretty much the same type of authentication. It’s just that the password is longer than the PIN. From a security perspective, you don’t gain a lot by requiring both a password and a PIN. You would gain more by choosing a type of authentication that is substantially different from passwords and PIN.

How many factors of authentication are there?

So how do we define the factors of authentication? Different people have different definitions.

Three factors of authentication

For the most part, I believe that everyone agrees on at least three factors of authentication. As I noted in a prior post on factors of authentication, NIST defines the following three factors:

Factors include: (i) something you know (e.g. password/personal identification number (PIN)); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric).

From https://csrc.nist.gov/glossary/term/Multi_Factor_Authentication, cited in https://bredemarket.com/2022/03/19/remember-the-newer-factors-of-authentication/

Note that NIST’s three factors are very different from one another. Knowing something (such as a password or a PIN) differs from having something (such as a driver’s license) or being something (a fingerprint or a face).

But some people believe that there are more than three factors of authentication.

Five factors of authentication

Let’s add two factors to the definition trumpeted by NIST. People such as The Cybersecurity Man have included all five in their definition.

  • Something you know.
  • Something you have.
  • Something you are.
  • Something you do.
  • Somewhere you are.

For more information, see my March 2021 post on the five factors of authentication.

But are there only five?

Six factors of authentication

In April 2022, I began wondering if there is a sixth authentication factor. While I struggled to put it into the “some xxx you xxx” format, I was able to encapsulate what this sixth factor was.

What about the authentication factor “why”?

This proposed factor, separate from the other factors, applies a test of intent or reasonableness to any identification request.

From https://bredemarket.com/2022/04/12/the-sixth-factor-of-multi-factor-authentication-you-heard-it-here-first/
Why is this man smoking a cigarette outdoors? By Marek Slusarczyk, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=108924712

Over the months, I struggled through some examples of the “why” factor.

  • Why is a person using a credit card at a McDonald’s in Atlantic City? (Link) Or, was the credit card stolen, or was it being used legitimately?
  • Why is a person boarding a bus? (Link) Or, was the bus pass stolen, or was it being used legitimately?
  • Why is a person standing outside a corporate office with a laptop and monitor? (Link) Or, is there a legitimate reason for an ex-employee to gain access to the corporate office?

As I refined my thinking, I came to the conclusion that “why” is a reasonable factor of authentication, and that this was separate from the other authentication factors (such as “something you do”).

And the sixth factor of authentication is called…

You’ll recall that I wanted to cast this sixth authentication factor into the “some xxx you xxx” format.

So, as of today, here is the official Bredemarket list of the six factors of authentication:

  • Something you know.
  • Something you have.
  • Something you are.
  • Something you do.
  • Somewhere you are.

(Drumroll…)

  • Somewhat you why.

Yes, the name of this factor stands out from the others like a sore thumb (probably a loop).

However, the performance of this factor stands out from the others. If we can develop algorithms that accurately measure the “why” reasonableness of something as a way to authenticate identity, then our authentication capabilities will become much more powerful.

The sixth factor of multi factor authentication (you heard it here first!)

As many of my readers know, there are a variety of ways for people to individually identify themselves.

The National Institute of Standards and Technology recognizes three of these authentication factors:

  • The most commonly known authentication factor is “something you know.” This includes such items as passwords, personal identification numbers (PINs), and the name of your childhood pet. This authentication factor is very common and very controversial, to the point where some want to eliminate it altogether. (I don’t.)
  • Another authentication factor that I know very well is “something you are.” Biometrics such as fingerprint identification and facial recognition falls into this category, as well as gait recognition, “behavioral biometrics,” and other biometric identifiers.
  • The third authentication factor that NIST recognizes is “something you have.” This could be a driver’s license, a passport, a key fob, a smartphone, or perhaps a digital identity application.

But those aren’t the only authentication factors. Two others have been identified, as I have previously noted.

  • “Something you do” differs from both gait recognition and behavioral biometrics, because this is not an inherent property of your being, but is a deliberate set of actions on your part. For example, you could gain access to a nuclear facility by putting your left foot in, putting your left foot out, putting your left foot, in and shaking it all about. Note, however, that this particular “something you do” is as common as the password “12345” and should be avoided.
  • And the fifth factor is “somewhere you are.” For example, if I am buying something at a a store in Virginia, but I am physically in California, something appears to be wrong.
GPS network illustration
By Éric Chassaing – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=8876959

OK, that’s it. End of post. Those are the five authentication factors. There aren’t any more, and there never will be any more. Oh sure, you could come up with a sixth authentication factor, but chances are that it would map into one of the five existing authentication factors.

Or maybe not.

Why?

I’d like to propose a sixth authentication factor.

What about the authentication factor “why”?

This proposed factor, separate from the other factors, applies a test of intent or reasonableness to any identification request.

Man smoking a cigarette and stacking hats on a fire hydrant
Why is this man smoking a cigarette outdoors? By Marek Slusarczyk, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=108924712

Let me give you an example. Assume for the moment that I am at a McDonald’s in Atlantic City and want to use my brand new credit card to buy some healthy Irish cuisine.

McDonald's food
Not in Atlantic City. By TeaLaiumens – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=37026979

You could, of course, apply the existing authentication factors to this transaction:

  • I physically have the credit card.
  • I know the PIN that is associated with the credit card.
  • My face matches the face of the person who owns the credit card.
  • I am physically at the McDonald’s where the food is for sale, and I physically have a hotel key associated with a nearby hotel, and I physically have a badge associated with a trade show in the city. (The latter two facts are actually a combination of “something you have” and “somewhere you are,” but I threw them here for the fun of it.)
  • If my credit card company has implemented it, I can perform the super secret finger pattern (or hokey pokey dance) associated with this account.

But even if all of these factors are authenticated, or even if some of them are not, does it make sense that I would be purchasing a meal at a McDonald’s in Atlantic City?

  • Did I recently book a flight and fly from my California home to Atlantic City? This could explain “why” I was there.
  • Is it lunchtime? This could explain “why” I was making this transaction.
  • Is my stomach growling? This could indicate that I am hungry, and could explain “why” I was at such a fine food establishment.

Admittedly, employing data warehousing and artificial intelligence to use the “why” factor to authenticate a small fast food purchase is overkill, just like it’s overkill to require three biometric identifiers and a passport to open a physical mailbox.

But perhaps use of such an authentication factor would be appropriate at a critical infrastructure facility such as a nuclear power plant.

nuclear power plant
By Avda – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=26894741

Assume for the moment that I am a double agent, employed the the U.S. Department of Energy but secretly a spy for an enemy country. All of the five authentication factors check out, and I am the person who is authorized to visit a particular nuclear power plant.

But why am I there?

Am I there for some regular U.S. Department of Energy business that is totally above board?

Or am I there for some other unknown reason, such as theft of secrets or even sabotage?

How to implement the “why?” authentication factor

I believe that a “why?” authentication factor could be very powerful, but it would take some effort to implement it.

First, the authentication system would have to access all the relevant data. In the McDonald’s example above, that includes (a) my flight data, (b) the time of day, and (c) my health data (“biometrics” in the broader sense). In the nuclear power plant example, the authentication system would have to know things such as nuclear power plant inspection schedules, trip authorizations from my supervisor, and other data that would indicate a reason for me to be at the plant. That’s a lot of data.

Neural network
By en:User:Cburnett – This W3C-unspecified vector image was created with Inkscape ., CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1496812

Second, the authentication system would have to process all the relevant data to glean knowledge from it. By itself, the data points “United Flight 123 from Ontario to Atlantic City yesterday,” “1:30 pm,” and “haven’t eaten in six hours” do not allow the system to make an authentication decision.

Third, the authentication system would have to collect and protect that mass of data in a way that protects my privacy and the privacy of others. In the United States at present, this is where the whole system would probably fall apart. While a whole bunch of data is collected about us and placed in silos (the TSA-airline silo, for example), putting it all together could be pretty scary to some. Although certain lawyers in Illinois would love the moneymaking opportunities that such a system could provide via Illinois Biometric Information Privacy Act lawsuits.

So a complete implementation of the “why” authentication factor is probably impossible for now, due to both technical and societal constraints.

But is it possible to implement a subset of the “why” authentication factor? For example, since a company presumably has access to employee corporate travel schedules, could the company use the knowledge of an employee’s flight from Chicago to Los Angeles on Sunday to provide the employee with physical access to the firm’s Southern California office on Monday?

Something to think about.

Maybe I should speak to a patent attorney.

Update on Covishield and the EUDCC, as long as you can prove you were born

It’s been a while since I looked at issues regarding the European Union Digital COVID Certificate (EUDCC).

And there are a ton of ramifications and unintended consequences.

Covishield and the EUDCC

When I last looked at the EUDCC, I examined its effect on travel from people outside of the European Union. The question at the time was what would happen to people who were vaccinated with something other than the European Medicines Agency-approved vaccines, thus rendering them ineligible for the EUDCC.

In particular, people who were vaccinated with the Covishield vaccine were not eligible for the EUDCC. Depending upon whom you asked, Covishield is either just the same as the EMA-approved AstraZeneca vaccine (now referred to as “Vaxzervria” in EU-speak), or it has a radically different manufacturing process that disqualifies it from automatic acceptance.

This non-recognition of Covishield has a great impact on African nations, because that vaccine is popular there. However, EUDCC disapproval has been offset by the actions of several individual countries to recognize Covishield as a vaccine. For example, Greece recognizes ten vaccines (including Covishield) as opposed to the EU’s four. Of course, you have to go through additional paperwork to get authorization to enter a specific country.

But Joseph Atick notes that there’s another issue that adversely impacts the ability of Africans to enter Europe.

Linking a vaccination to a person

Assume for the moment that you have received an EU-authorized vaccine. This is only part of the battle, because the act of vaccination has to be tied to you as a person.

Dr. Joseph Atick of ID4Africa. From https://id4africa.com/the-general-secretariat/

And Atick notes one complicating factor in making that link:

One of the biggest barriers to setting up these systems—and one that could greatly complicate digital health certificates – involves traceability, which for an official digital ID means documenting one’s birth event.

In Africa, not everyone has a birth certificate, and many struggle to trace their identity to the birth event.

If you cannot prove to the satisfaction of the European Union (or whoever) that you were the actual person who received a vaccine, then you may face barriers to entering Europe (or wherever).

And what are the ramifications of this?

A digital health certificate has appeal as an efficient and effective way to manage COVID-19 risks. But if we don’t pause now to consider the implications of getting it wrong and look for ways to get it right, these marvellous digital innovations could also be supremely effective at creating a binary world of those who can prove their COVID-19 risk status and those who cannot.

The requirement for a digital identity

Oh, and there’s another issue that Atick didn’t address, but which bears noting.

All of the health vaccination solutions listed above assume as a given that people will be the owners of a unique, government-authorized digital identity.

As I’ve noted elsewhere, there are people who are fervently opposed to this.

In my country, both some people on the left and some people on the right believe that “governmental digital identity” naturally equates to “governmental digital surveillance,” and that governments shouldn’t be abusing the data that they can obtain from all the vaccinations you get, all the places you travel, all the things you buy, and all the other things that you do.

(Well, except for voting. Some on the right fervently believe that government identities are essential to voting, even if they’re not essential to any other activity.)

But are people truly banned from travel?

So where does this leave the people who cannot prove that they were vaccinated with an authorized vaccine, or perhaps were never vaccinated at all?

In many cases travel for the unvaccinated is not banned, but they have to go through additional hoops to travel. Using one example, unvaccinated U.S. citizens can travel to Austria if they “have recovered from COVID-19 in the past 180 days; or present a negative COVID-19 PCR or antigen test result procured within 72 or 48 hours of travel.” For more country-by-country specifics as of August 13, click here.

But how will the unvaccinated get to Europe, or anywhere else?

But on the other hand, a vaccination in and of itself is not a guarantee that you can travel. Norway has a long list of requirements that an incoming person must satisfy, vaccination or not. This isn’t the time for an American to go on a sightseeing tour to Oslo.

Or Pyongyang.

So a binary division into the “travels” and “travel nots” may not become a reality. Instead, it will be a gradation of travel allowances and non-allowances, based upon a variety of factors.