View source for NIST SP 800-63-3

==Full Title==
Digital Identity Guidelines
* Date released: 2017-06-22
* This spec is due to be replaced by [[NIST SP 800-63-4]] in 2023 or perhaps 2024

==Context==
*Specifically applies to federal agencies implementing digital identity services but is widely used internationally.
*This third version makes substantial changes to the second version, specifically the single list of the levels of authentication has been separated into three distinct lists, one for each of the documents as described below.

==[https://doi.org/10.6028/NIST.SP.800-63-3 Summary Document of Digital Identity Guidelines]==
==[https://doi.org/10.6028/NIST.SP.800-63a Enrollment and Identity Proofing (800-63-3A)]==
*Contains IAL levels = [[Identity]] Assurance Level  (Level 2 is required by Healthcare)
#There is no requirement to link the applicant to a specific real-life identity. Any attributes provided in conjunction with the subject’s activities are self-asserted or should be treated as self-asserted (including attributes a CSP asserts to an RP). Self-asserted attributes are neither validated nor verified.
#Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL2 introduces the need for either remote or physically-present identity proofing. Attributes could be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes. A CSP that supports IAL2 can support IAL1 transactions if the user consents.
#Physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained CSP representative. As with IAL2, attributes could be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes. A CSP that supports IAL3 can support IAL1 and IAL2 identity attributes if the user consents.

==[https://doi.org/10.6028/NIST.SP.800-63b Authentication and Lifecycle Management (800-63-3B)]==
*Contains AAL levels = [[Authentication]] Assurance Level (Level 2 is required for Healthcare)
#AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.
#AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.
#AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication requires a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device may fulfill both these requirements. In order to authenticate at AAL3, claimants are required to prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.
===Supplement 1===
Coins a new buzz word [[Syncable Authenticator]] is added to try to comprehend the move to the [[Authentication]] process being split between the source and destination process in [[Multi-factor Authentication]].
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63Bsup1.pdf NIST SP 800-63Bsup1 Incorporating Syncable Authenticators Into NIST SP 800-63B] 2024-04-22 Certain equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately.

==[https://doi.org/10.6028/NIST.SP.800-63c Federation and Assertions (800-63-3C)]==
*Contains FAL levels = [[Federation]] Assurance Level (There seems to be little reason for any level other than level 3 as everything is automatic)
#Bearer assertion, signed by IdP. (for example OpenID Connect Basic Client Profile)
#Bearer assertion, signed by IdP and encrypted to RP. (Assertion is encrypted by a public key of the RP for example on off-line presentation of proof)
#Holder of key assertion, signed by IdP and encrypted to RP. (RP must provide proof of possession for example signing a nonce)
* Some commentary on [[NIST SP 800-63-3C]] rev 1.

==References==
https://pages.nist.gov/800-63-3/

[[Category:Glossary]]
[[Category:Standard]]