Assurance

Full Title or Meme

The level of trust that can be afforded a claim of an Identifier or Attribute.

Context

• Some means for assuring the Web Site Security is required. See that page for details.
• The rest of this page is about establishing a level of assurance for User Information about a User also known as a Subject.
• Previous version of SP 800-63-2 described level of Assurance or LOA that are still part of ISO standards. NIST has published a FAQ to describe the reasons for the upgrade.
• New version of SP 800-63-3 with Assurance separated out from the other Authentication Attributes.
• Provenance is a term that is sometimes used for the level of Assurance that a Data Controller has in the origin and reliability of User Attributes, especially health care data

For a User that wants some Assurance about a Web Site see Trusted Third Party.

Problems

• In contexts where names are not validated (of low Assurance) the problem arises that trolls many adopt the name of some well-known person to be able to make statements that falsely appear to be from the real person.
• See discussion on the pages for Ephemeral and Persistent.
• Most of the existing protocols, like OpenID Connect and SAML 2.0 support the older NIST SP 800-63-2 level of assurance ratings. These are also baked into RFC 6711 "An IANA Registry for Level of Assurance (LoA) Profiles" and ISO/IEC 291151.

Solutions

A rather facile mapping of the NIST 800-63-3 levels of Assurance to the processes known today is:

• LOA1, IAL1 ==> password
• LOA2, IAL2 ==> 2FA
• LOA3, IAL3 ==> U2F

The best source of Truth about an Identity is obtained by documentation of the Identity Proofing process. That is something that can be audited to measure reality against expectations.

A summary of the 3 categories now in NIST 800-63-3

A summary of each of the identity, authenticator, and federation assurance levels is provided below.

Identity Assurance Level

1. At IAL1, attributes, if any, are self-asserted or should be treated as self-asserted.
2. At IAL2, either remote or in-person identity proofing is required. IAL2 requires identifying attributes to have been verified in person or remotely using, at a minimum, the procedures given in SP 800-63A.
3. At IAL3, in-person identity proofing is required. Identifying attributes must be verified by an authorized CSP representative through examination of physical documentation as described in SP 800-63A.

Authenticator Assurance Level

1. AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful a AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator(s) through a secure authentication protocol.
2. AAL2 provides high confidence that the claimant controls authenticator(s) registered to the subscriber. Proof of possession and control of two different authentication factors is required through a secure authentication protocol. Approved cryptographic techniques are required at AAL2 and above.
3. AAL3 provides very high confidence that the claimant controls authenticator(s) registered to the subscriber. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 is like AAL2 but also requires a “hard” cryptographic authenticator that provides verifier impersonation resistance.

Federation Assurance Level

1. FAL1 permits the RP to receive a bearer assertion from an identity provider (IdP). The IdP must sign the assertion using approved cryptography.
2. FAL2 adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it.
3. FAL3 requires the subscriber to present proof of possession of a cryptographic key reference to in the assertion and the assertion artifact itself. The assertion must be signed using approved cryptography and encrypted to the RP using approved cryptography.

When described generically or bundled, NIST guidelines refers to IAL, AAL, and FAL as xAL.

References

External References

1. Synonyms include: Validated which typically is used with Assurance of claims, or Attested which typically is used with Assurance of User Devices.