Difference between revisions of "Authenticator"

Revision as of 20:00, 13 February 2021

Full Title or Meme

Authenticators are devices in the user's possession that can generate believable claims that information has been contemporaneously generated by the device.

Context

• Authenticators may be independent hardware devices, or may be software running on a User Device that contains a Trusted Execution Environment to hold user Credentials that are used to create claims for the user.
• The Authenticator Assurance Level has been defined in NIST SP 800-63-3B to communicate the level of assurance.

Problem

Give users a hand-held device that can generate secured claims for access to secure accounts.

Solution

• The page One-Time Password Authenticator has a description of one type of Authenticator.
• Web Authentication Authenticator. A cryptographic entity, existing in hardware or software, that can register a user with a given Relying Party and later assert possession of the registered public key credential, and optionally verify the user, when requested by the Relying Party. Authenticators can report information regarding their type and security characteristics via attestation during registration. A WebAuthn Authenticator could be a roaming Authenticator, a dedicated hardware subsystem integrated into the client device, or a software component of the client or client device.
• Authentication Assertion = The cryptographically signed AuthenticatorAssertionResponse object returned by an Authenticator as the result of an authenticatorGetAssertion operation.
• Authentication Ceremony = The ceremony where a user, and the user’s client (in conjunction with at least one Authenticator) works in concert to cryptographically prove to a Relying Party that the user controls the credential private key associated with a previously-registered public key credential (see Registration). Note that this includes a test of user Presence or user verification.

Table of Authenticators

References

Health Care Solutions

• HIPAA
• TEFCA technically applies only to members of a "Qualified Health Information Network" (QHIN) to require AAL2 assurance, but since many of the organizations that host the QHIN will fill other roles, the requirement could apply to a large number of health providers.

Other Material

• Trusted Exchange Framework and Common Agreement (TEFCA) Draft 2 (2019-04-19)

  6.2.5 User Authentication. Each QHIN shall adhere to the user authentication functional requirements as described in the QHIN Technical Framework where applicable. Additionally, each QHIN shall require that any staff or users at the QHIN, Participants, or Individual Users who request EHI or request to send EHI shall be authenticated at a minimum of AAL2 and, if not an Individual User, also provide support for at least FAL2. Each QHIN shall also require each of its Participants to authenticate any Participant Members or Individuals Users that request EHI or request to send EHI at a minimum of AAL2 and, if not an Individual User, also provide support for at least FAL2.

• A User’s Guide to Understanding to TEFCA Draft 2 A slide deck that introduces some erroneous simplifications. (like credential)