npe – Page 6 – Bredemarket

Dr. Jones MD, NPE

I have a telehealth appointment next week with a medical professional whom I have previously met. And I assume she will participate in the telehealth appointment.

In the future, of course, she may not.

Way back in April 2013, I wrote a tymshft piece entitled “You will still take a cab to the doctor’s office. For a while.” It speculated about a future 2023 medical appointment in which the patient took a driverless cab to a medical facility. In the office, the patient was examined by remote staff…or so she thought.

“Well, I’m glad you’ve gotten used to the procedure,” replied the friendly voice. “I hope you like me!”

“I do,” said Edith. “You’ve been very helpful. But I’ve always wondered exactly WHERE you were. If you were in Los Angeles, or in Mississippi, or perhaps in India or China, or perhaps even in one of the low-cost places such as Chad. If you don’t mind my asking, exactly where ARE you?”

“I don’t mind answering the question,” replied the friendly voice, “and I hope you don’t take my response the wrong way, but I’m not really a person as you understand the term. I’m actually an application within the software package that runs the medical center. But my programmers want me to tell you that they’re really happy to serve you, and that Stanford sucks.” The voice paused for a moment. “I’m sorry, Edith. You have to forgive the programmers – they’re Berkeley grads.”

“Oh,” said Edith after a moment. “This is something new. I’m used to it in banking, but I didn’t realize that a computer program could run an entire medical center. Well…who picks up the trash?”

“That’s an extra question! Just kidding,” replied the friendly voice. “Much of the trash pickup is automated, but we do have a person to supervise the operation. Ron Hussein. You actually know him – he was your cab driver in 2018 when you came here.”

Re-reading this 2013 piece, I was amused at three things I got wrong.

First, Google, Facebook, and Apple did NOT merge to form Gaceapple, “the important merger that saved the tech industry in the United States from extinction.” American tech firms are still powerful…for now.
Second, my assumption of cab companies adopting driverless cars assumed the continued existence of cab companies. Ride share services have reduced the presence of traditional companies dramatically.
Third, my assumption that medical firms would sink untold sums of money into centralized automated medical examination rooms could be questioned…especially for routine appointments like Edith’s. Why not just let Edith’s smartphone—perhaps with a single attachment—gather the data?

Of course, there are medical ethics questions that underlie this entire discussion of remote telehealth and the use of non-person entities (NPEs). And we are struggling with those right now.

Image of Dr. Jones MD, NPE from Google Gemini.

Do All 5 Identity Factors Apply to Non-Human Identities?

I’ve talked ad nauseam about the five factors of identity verification and authentication. In case you’ve forgotten, these factors are:

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

I’ll leave “somewhat you why” out of the discussion for now, but perhaps I’ll bring it back later.

These five (or six) factors are traditionally used to identify people.

Identifying “Non-Person Entities”

But what happens when the entity you want to identify is not a person? I’ll give two examples:

Kwebbelkop AI? https://www.youtube.com/watch?v=3l4KCbTyXQ4.

Kwebbelkop AI, discussed in “Human Cloning Via Artificial Intelligence: It’s Starting,” is not a human. But is there a way to identify the “real” Kwebbelkop AI from a “fake” one?
In “On Attribute-Based Access Control,” I noted that NIST defined a subject as “a human user or NPE (Non-Person Entity), such as a device that issues access requests to perform operations on objects.” Again, there’s a need to determine that the NPE has the right attributes, and is not a fake, deep or shallow.

There’s clearly a need to identify non-person entities. If I work for IBM and have a computer issued by IBM, the internal network needs to know that this is my computer, and not the computer of a North Korean hacker.

But I was curious. Can the five (or six) factors identify non-person entities?

Let’s consider factor applicability, going from the easiest to the hardest.

The easy factors

Somewhere you are. Not only is this extremely applicable to non-person entities, but in truth this factor doesn’t identify persons, but non-person entities. Think about it: a standard geolocation application doesn’t identify where YOU are. It identities where YOUR SMARTPHONE is. Unless you have a chip implant, there is nothing on your body that can identify your location. So obviously “somewhere you are” applies to NPEs.
Something you have. Another no brainer. If a person has “something,” that something is by definition an NPE. So “something you have” applies to NPEs.
Something you do. NPEs can do things. My favorite example is Kraftwerk’s pocket calculator. You will recall that “by pressing down this special key it plays a little melody.” I actually had a Casio pocket calculator that did exactly that, playing a tune that is associated with Casio. Later, Brian Eno composed a startup sound for Windows 95. So “something you do” applies to NPEs. (Although I’m forced to admit that an illegal clone computer and operating system could reproduce the Eno sound.)

Something you do, 1980s version. Advance to 1:49 to hear the little melody. https://www.youtube.com/watch?v=6ozWOe9WEU8.

Something you do, 1990s version. https://www.youtube.com/watch?v=miZHa7ZC6Z0.

Those three were easy. Now it gets harder.

The hard factors

Something you know. This one is a conceptual challenge. What does an NPE “know”? For artificial intelligence creations such as Kwebbelkop AI, you can look at the training data used to create it and maintain it. For a German musician’s (or an Oregon college student’s) pocket calculator, you can look at the code used in the device, from the little melody itself to the action to take when the user enters a 1, a plus sign, and another 1. But is this knowledge? I lean toward saying yes—I can teach a bot my mother’s maiden name just as easily as I can teach myself my maiden name. But perhaps some would disagree.

Something you are. For simplicity’s sake, I’ll stick to physical objects here, ranging from pocket calculators to hand-made ceramic plates. The major reason that we like to use “something you are” as a factor is the promise of uniqueness. We believe that fingerprints are unique (well, most of us), and that irises are unique, and that DNA is unique except for identical twins. But is a pocket calculator truly unique, given that the same assembly line manufactures many pocket calculators? Perhaps ceramic plates exhibit uniqueness, perhaps not.

That’s all five factors, right?

Well, let’s look at the sixth one.

Somewhat you why

You know that I like the “why” question, and some time ago I tried to apply it to identity.

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?

The first example is fundamental from an identity standpoint. It’s taken from real life, because I had never used any credit card in Atlantic City before. However, there was data that indicated that someone with my name (but not my REAL ID; they didn’t exist yet) flew to Atlantic City, so a reasonable person (or identity verification system) could conclude that I might want to eat while I was there.

But can you measure intent for an NPE?

Does Kwebbelkop AI have a reason to perform a particular activity?
Does my pocket calculator have a reason to tell me that 1 plus 1 equals 3?
Does my ceramic plate have a reason to stay intact when I drop it ten meters?

I’m not sure.

By Bundesarchiv, Bild 102-13018 / CC-BY-SA 3.0, CC BY-SA 3.0 de, https://commons.wikimedia.org/w/index.php?curid=5480820.

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.

Public Domain, https://commons.wikimedia.org/w/index.php?curid=6907222.

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.

By Love Makes A Way – https://www.flickr.com/photos/lovemakesaway/15802177909/, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=101171928.

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.

Figure 2 from 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.

Authenticator Assurance Levels (AALs) and Digital Identity

(Part of the biometric product marketing expert series)

Back in December 2020, I dove into identity assurance levels (IALs) and digital identity, subsequently specifying the difference between identity assurance levels 2 and 3. These IALs are defined in section 4 of NIST Special Publication 800-63A, Digital Identity Guidelines, Enrollment and Identity Proofing Requirements.

It’s past time for me to move ahead to authenticator assurance levels (AALs).

Where are authenticator assurance levels defined?

Authenticator assurance levels are defined in section 4 of NIST Special Publication 800-63B, Digital Identity Guidelines, Authentication and Lifecycle Management. As with IALs, the AALs progress to higher levels of assurance.

AAL1 (some confidence). AAL1, in the words of NIST, “provides some assurance.” Single-factor authentication is OK, but multi-factor authentication can be used also. All sorts of authentication methods, including knowledge-based authentication, satisfy the requirements of AAL1. In short, AAL1 isn’t exactly a “nothingburger” as I characterized IAL1, but AAL1 doesn’t provide a ton of assurance.
AAL2 (high confidence). AAL2 increases the assurance by requiring “two distinct authentication factors,” not just one. There are specific requirements regarding the authentication factors you can use. And the security must conform to the “moderate” security level, such as the moderate security level in FedRAMP. So AAL2 is satisfactory for a lot of organizations…but not all of them.
AAL3 (very high confidence). AAL3 is the highest authenticator assurance level. It “is based on proof of possession of a key through a cryptographic protocol.” Of course, two distinct authentication factors are required, including “a hardware-based authenticator and an authenticator that provides verifier impersonation resistance — the same device MAY fulfill both these requirements.”

This is of course a very high overview, and there are a lot of…um…minutiae that go into each of these definitions. If you’re interested in that further detail, please read section 4 of NIST Special Publication 800-63B for yourself.

Which authenticator assurance level should you use?

NIST has provided a handy dandy AAL decision flowchart in section 6.2 of NIST Special Publication 800-63-3, similar to the IAL decision flowchart in section 6.1 that I reproduced earlier. If you go through the flowchart, you can decide whether you need AAL1, AAL2, or the very high AAL3.

The AAL CYOA from https://pages.nist.gov/800-63-3/sp800-63-3.html#63Sec6-Figure2.

One of the key questions is the question flagged as 2, “Are you making personal data accessible?” The answer to this question in the flowchart moves you between AAL2 (if personal data is made accessible) and AAL1 (if it isn’t).

So what?

Do the different authenticator assurance levels provide any true benefits, or are they just items in a government agency’s technical check-off list?

Perhaps the better question to ask is this: what happens if the WRONG person obtains access to the data?

Could the fraudster cause financial loss to a government agency?
Threaten personal safety?
Commit civil or criminal violations?
Or, most frightening to agency heads who could be fired at any time, could the fraudster damage an agency’s reputation?

If some or all of these are true, then a high authenticator assurance level is VERY beneficial.