Mic Drop — Announcing the New Special Publication 800-63 Suite!

Goodbye LOA…Hello IAL, AAL, and FAL (collectively called “xALs”)

More than a year in the making, after a large, cross-industry effort, we are proud to announce that the new Special Publication (SP) 800-63 IS. NOW. FINAL. With your help, Electronic Authentication Guidelines has evolved into Digital Identity Guidelines—a suite of documents covering digital identity from initial risk assessment to deployment of federated identity solutions. Check it out now at https://pages.nist.gov/800-63-3/ or as a PDF at https://doi.org/10.6028/NIST.SP.800-63-3.

There is no way a document this comprehensive could have evolved without the direct input of stakeholders, who contributed consistently throughout the drafting process. This revision to SP 800-63 was our first foray into using GitHub to collaborate with stakeholders for a major document, and it was a great success. The community interacted with us—and each other—throughout the course of the year to develop a better final product.

The community participation resulted in a tremendous response: contributors submitted 1,400+ comments for review, and the web version of the publication drew 74,000+ unique visitors between May 2016 and May 2017.

What’s changed, you ask?

Digital identity in both agencies and the market have changed dramatically since the last revision of this document in 2013.

Gone are the days of levels of assurance (LOAs), replaced by ordinals for individual parts of the digital identity flow, enabling implementers more flexibility in their design and operations:

  • Identity Assurance Level (IAL): the identity proofing process and the binding between one or more authenticators and the records pertaining to a specific subscriber
  • Authenticator Assurance Level (AAL):  the authentication process, including how additional factors and authentication mechanisms can impact risk mitigation
  • Federation Assurance Level (FAL): the assertion used in a federated environment to communicate authentication and attribute information to a relying party (RP)

The suite that is now SP 800-63 has four parts—and could have more in the future as digital identity evolves. SP 800-63 is the mothership—your starting point for all things digital identity and risk—with SP 800-63A, 800-63B, and 800-63C covering the various components of a digital identity system:

  • SP 800-63-3 (Digital Identity Guidelines) incorporates risk language that agencies have been following from OMB M-04-04 and updates SP 800-63-2, sections 1-4 (see below for more on that)
  • SP 800-63A (Enrollment & Identity Proofing) updates SP 800-63-2, section 5
  • SP 800-63B (Authentication & Lifecycle Management) updates SP 800-63-2, sections 6-8
  • SP 800-63C (Federation & Assertions) updates SP 800-63-2, section 9

More specifics about each volume:

SP 800-63-3 provides identity-specific input that agencies should consider when taking their system through security assessment and authorization. It provides an overview of general identity frameworks; using authenticators, credentials, and assertions together in a digital system; as well as handy “choose your own adventure” (sorry, we’re old) flowcharts to enhance the process of selecting an xAL. In those flowcharts, organizations can perform a risk assessment, answer a set of functional questions, and, based on their responses, be guided to the most appropriate xAL for their system and users.

We understand some of you may read 800-63-3 and wonder if it conflicts with OMB M04-04. We don’t speak for OMB, but we’ve been working with them and understand that they have been working on a consolidated overarching digital identity policy as part of their effort to simplify existing policy guidance, and that this draft will be out for public comment in the near future.

The inclusion of risk assessment language from 04-04 into 800-63 removes one additional place where agencies need to look for requirements and ensures that the assessment of risk and the available processes and technologies to mitigate that risk are well aligned.

These changes simplify and clarify guidance, better align with commercial markets, promote international interoperability, and focus on outcomes (where possible) to promote innovation and deployment flexibility. Furthermore, removing LOAs and differentiating identity proofing from authentication from federation gives RPs latitude in designing, building, consuming, and procuring identity technology.

Identity proofing

SP 800-63A focuses on arguably the most difficult part of digital identity: strengthening identity proofing while expanding options for remote and in-person proofing. The new guidelines clarify methods for resolving an identity to a single person and enables RPs to evaluate and determine the strength of identity evidence. No longer will agencies be required to ask for “one government-issued ID and a financial account.” The proofing guidance moves away from a static list of acceptable documents and instead describes “characteristics” for the evidence necessary to achieve each IAL. Agencies can now pick the evidence that works best for their stakeholders. In fact, the document no longer differentiates between physical evidence (like a driver’s license) and digital evidence (perhaps a mobile driver’s license or an assertion from another identity provider). You should no longer think “plastic is good” and “digital is bad” for presented evidence; what matters is the process behind the presentation.

SP 800-63A opens the door for a diverse array of proofing options, including virtual in-person (aka “supervised remote”) and trusted referees (e.g., notaries), and offers clearer guidelines on document checking and address confirmation.

Authentication

 

On the authentication side, some big changes include:

No more…

    • “what is your mother’s maiden name” to authenticate or to recover a lost, stolen, or forgotten credential
      • email as a place to send one-time-passwords (OTPs)
      • plain old SMS to send OTPs, although SMS is allowable with some risk-based and security measures
      • “token” talk – it’s now “authenticator” … we overload terms in identity all the time, so this was an opportunity to change (plus, “token” has other meanings in cybersecurity that have nothing to do with the device used to log in)
    • more options (to include more usable ones) at higher assurance levels
    • closing the holes of account recovery; if you lost your authenticator and have no backups, you’ll need to get reproofed…the risk otherwise is just too high

The new guidelines also enable server-side biometric matching and include a comprehensive set of biometric performance and security requirements. Biometric sensors are common in the devices that so many of us carry with us every day, so we felt we needed to provide guidelines that can prevent unreliable or weak biometric approaches from sneaking their way into federal digital services, while allowing these powerful tools to play a large role in doing digital identity right.

Federation

Federation is when the RP and IdP are not a single entity or not under common administration. Federation enables an IdP to proof and authenticate an individual and provide identity assertions that RPs can accept and trust.

We love federation. In fact, we think you should leverage federated services whenever you can. As such, SP 800-63C lays out the details of identity federation and identity assertions to keep implementation of federation on the level. This section expands federation guidelines from previous versions of 800-63, provides greater detail on how assertions should be used, and includes a host of privacy-enhancing requirements that can make federation appealing to users.

What’s next?

But wait, there’s more!

We know the security and privacy requirements of this revision have changed substantially from past versions, but keep in mind we do not intend to drop this document and walk away. While the guidelines themselves are final, we strongly believe that work on this document isn’t truly complete until, like open standards, it has been implemented to tease out bugs and complexities.

To that end, we hope this revision can set us on a new path to continually improve digital identity. Rather than waiting until agency and market needs have shifted enough to warrant a revision in any of the volumes—then waiting more than a year to complete a revision—we plan to continue engaging with implementers so we can compile, and share, lessons learned and implementation guidance throughout the life of the current revision.

Our ability to predict and respond to changes in the market and technology needs to match the speed of innovation, as well as threats. We look forward to working with agencies and the private sector to improve these guidelines based on real implementation of digital identity services. Over time, we want them to become even more outcome-based and reliant on proven performance metrics, as well as adaptive to innovations in the market so anyone, public or private, can better serve their users.

For us, the immediate next step is preparing implementation guidance to help agencies deploy solutions that meet SP 800-63’s requirements. The first set will focus on identity proofing, and we will release further guidance over the course of the year.

We’re also drafting SP 800-63D, a relatively simple additional volume detailing efforts to align with international technical specifications for interoperable identity in federations—including SAML profiles and an iGov OpenID Connect/OAuth profile developed in partnership with industry and other governments.

Please stay tuned for the implementation guidance and 800-63D, and we look forward to further collaboration!

This entry was posted in Uncategorized and tagged , , , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*