Authenticator

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

Vendor	Technology	Android	Apple	Microsoft
Push Notifications	QR aka.ms/mfasetup	-	-	Azure AD ONLY
FIDO 2 Keys	On or Off Line	phone	iPhone	eindows
Windows Hello	App Store	phone	iPhone	store
Microsoft Authenticator	Single ID ONLY -- PoP by multiple choice	Notification push	Notification push	n/a
Google	database	kavi.com		member db is distinct
Auth0	SMS or email -- Online OH:Y	Android	iPhone
IDEFREGISTRY.ORG	word press	Early Adopter		separate trust zone
Showing currently known information

References

Health Care Solutions

• HIPAA, he Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy Rule’s right of access provisions require that individuals or their personal representatives have timely access to their health information (within 30 days, with the possibility of one 30-day extension) and for a reasonable, cost-based fee.
• 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)