Difference between revisions of "Authenticator"

From MgmtWiki
Jump to: navigation, search
(References)
(Other Material)
Line 22: Line 22:
  
 
===Other Material===
 
===Other Material===
*[https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf Trusted Exchange Framework and Common Agreement (TEFCA) Draft 2] (2019-04-19)
+
*[https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf Trusted Exchange Framework and Common Agreement (TEFCA) Draft 2] (2019-04-19)<blockquote>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. 6.2.6 Transport Security. Each QHIN’s security policy shall include written policies<blockquote>
 
*[https://www.healthit.gov/sites/default/files/page/2019-04/TEFCADraft2UsersGuide.pdf A User’s Guide to Understanding to TEFCA Draft 2] A slide deck that introduces some erroneous simplifications. (like credential)
 
*[https://www.healthit.gov/sites/default/files/page/2019-04/TEFCADraft2UsersGuide.pdf A User’s Guide to Understanding to TEFCA Draft 2] A slide deck that introduces some erroneous simplifications. (like credential)
  

Revision as of 13:56, 21 October 2019

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

Problem

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

Solution

  • The Authenticator Assurance Level has been defined in NIST SP 800-63-3B to communicate the level of assurance.
  • 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.

References

Health Care Solutions

  • HIPAA
  • TEFCA

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. 6.2.6 Transport Security. Each QHIN’s security policy shall include written policies
  • A User’s Guide to Understanding to TEFCA Draft 2 A slide deck that introduces some erroneous simplifications. (like credential)