Note the “deprecated” and “legacy” data types. In 1993, Type 4 was the gold standard for fingerprint images; now it’s just “legacy.” And forget about binary representations or anything less than 500 ppi.
Time marches on.
But some people have been around for much of the ride. I scanned the lists of working group members and found Kenneth Blue, Tom Buss, Roland Fournier, Patrick Grother, Mike McCabe, John Splain, Mark Walch, and many others who remember Type 4 and 250 ppi binary images.
And the canvassees included government and industry representatives from within and outside of the United States, including Canada, Germany, Japan, Latvia, Slovakia, Switzerland, other countries I probably mnissed, and INTERPOL.
If Europe or other countries do break away from NIST standards, it will be a rupturing break.
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.
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.
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.
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.
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.
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.
I’m sure that many people imagine that standards are developed by a group of reasonable people, sitting in a room, who are pursuing things for the good of the world.
You can stop laughing now.
I wrote this in the context of the then-emerging compression format WebP (we’ll return to WebP itself later). The point that I was making was that something becomes a “standard” by brute force. If a lot of people like something, it’s a standard.
The issue with standards is that they can take years to develop, so standards are adopted after the fact.
Now let’s look at “health passports.” As you may have guessed, these “passports” can be used to enter a country, or a state, or an office building, and are specifically devoted to certifying the health of the passport bearer. If the person meets the health criteria, they can enter the country/state/building. If not, they are prohibited from entry.
In a sense, the concept of a health passport is nothing new. Before entering a country, you are often required to satisfy various health conditions, such as being free of tuberculosis.
The current impetus for health passports, of course, is COVID. When COVID spread across the world a year ago, and governments began shutting down borders between countries, a lot of people at a lot of government agencies and a lot of companies began asking two basic questions:
When reliable COVID tests are developed, how will we know whether someone has successfully passed a COVID test?
When reliable COVID vaccines are developed, how will we know whether someone has successfully been vaccinated against COVID?
These questions, especially the second one, were mostly theoretical a year ago, but the government agencies and the companies needed answers to them as soon as possible. And the governments and the companies weren’t going to wait for the entire world to agree on a plan; they wanted to move ahead THAT DAY.
It’s a year later, and COVID tests are readily available, and COVID vaccines have been developed and approved in various countries. And we’ve made a lot of progress.
Or have we?
As Jim Nash notes in a Biometric Update article, there are several different solutions to the “health passport” issue. Nash lists two of them:
The state of Hawaii is working with Clear, United Airlines, and Delta Airlines on a solution. Initially this only documents testing, but it could be expanded to vaccine documentation.
The Malaysia Aviation Group is working with “local authorities” on its own solution.
Now the wealth of health passport solutions isn’t much of a problem for most consumers, since we’ll probably need one or two health passports at most as this market matures. Maybe a US person might need one or two health passports for domestic travel, and maybe one to get into the office. In extreme conditions, maybe they’ll be required to enter grocery stores, but this is doubtful considering the resistance of American personalities to governments telling us what to do.
But the wealth of health passports IS a problem if you’re a business. Imagine being at an airport gate and asking a traveler for a Clear Health Pass, and getting an angry reply from the traveler that he already has a VeriFLY pass and that the airline is infringing upon the traveler’s First and Second Amendment rights by demanding some other pass.
Eventually there will be enough of a brouhaha over the multitude of incompatible passes. At that time, several efforts will be made to establish THE standard for health passports, or at least for health passport interoperability.
Yes, “several efforts” will be made. Because each vendor will unsurprisingly advance its own passport as the best one for the standard, or perhaps will form alliances with selected other vendors.
Bredemarket 