Difference between revisions of "Authenticator"
From MgmtWiki
(→Solution) |
(→Table of Authenticators) |
||
| (40 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | [[Authenticator]]s are devices in the user possession that can generate | + | [[Authenticator]]s are devices in the user's possession that can generate believable claims that information has been contemporaneously generated by the device. |
==Context== | ==Context== | ||
*[[Authenticator]]s may be independent hardware devices, or may be software running on a [[User Device]] that contains a [[Trusted Execution Environment]] to hold user [[Credential]]s that are used to create claims for the user. | *[[Authenticator]]s may be independent hardware devices, or may be software running on a [[User Device]] that contains a [[Trusted Execution Environment]] to hold user [[Credential]]s that are used to create claims for the user. | ||
| + | * The [[Assurance#Authenticator_Assurance_Level|Authenticator Assurance Level]] has been defined in NIST SP 800-63-3B to communicate the level of assurance. | ||
==Problem== | ==Problem== | ||
| Line 9: | Line 10: | ||
==Solution== | ==Solution== | ||
| + | |||
* The page [[One-Time Password Authenticator]] has a description of one type of [[Authenticator]]. | * The page [[One-Time Password Authenticator]] has a description of one type of [[Authenticator]]. | ||
| + | * [https://w3c.github.io/webauthn/#authentication-assertion 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. [[Authenticator]]s 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=== | ||
| + | |||
| + | {| border="1" padding="2" width="600px" | ||
| + | |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 | ||
| + | |- | ||
| + | |[https://techcommunity.microsoft.com/t5/azure-active-directory-identity/new-microsoft-authenticator-security-features-are-now-available/ba-p/2464386 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 | ||
| + | |- | ||
| + | |colspan=6|Showing currently known information | ||
| + | |} | ||
| + | |||
| + | ==References== | ||
| + | <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=== | ||
| + | *[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.<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) | ||
[[Category:Glossary]] | [[Category:Glossary]] | ||
[[Category:Authentication]] | [[Category:Authentication]] | ||
| + | [[Category:Trust]] | ||
Latest revision as of 11:47, 26 November 2021
Contents
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 | |
| 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
- 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)
