Identity/biometrics/technology marketing and writing services
I thought I knew the difference between persons and non-person entities (NPEs), and then the Innu Nation does this:
With its thunderous rapids carving through a wild boreal forest in Quebec’s Côte-Nord region, the Magpie River is well known to white water rafters from around the globe. What these travelers may not know is that the Magpie recently became the first river in Canada to be granted legal personhood.
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.
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.
I’ve talked ad nauseam about the five factors of identity verification and authentication. In case you’ve forgotten, these factors 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.
But what happens when the entity you want to identify is not a person? I’ll give two examples:
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.
Those three were easy. Now it gets harder.
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.
You know that I like the “why” question, and some time ago I tried to apply it to identity.
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?
I’m not sure.
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.
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.
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…
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.
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.
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:
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.
(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).
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.
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.
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.
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).
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?
If some or all of these are true, then a high authenticator assurance level is VERY beneficial.
Bredemarket