Introducing AffirmId, an Authenticator App
Proof Of Concept for Android version 6 or later is available for test and evaluation. Navigate to this page using your phone’s browser and tap here to download the ZIP file. Unzip the AffirmId apk file tapping it to install.
Detailed installation instructions are provided here.
A high level non-technical introduction to AffirmId explains the basics of AffirmId from an enterprise security perspective. Click here to view and/or download this introductory document.
From the above you learn AffirmId delivers authenticator functionality equaling and exceeding, from a security point of view, present day 2FA authenticators of the OTP verity. This deep dive document takes you beyond present day authentication and into the future of passwordless authentication. Click here to begin a journey into the authenticators of AffirmId.
At this point you have a basic understanding of the authenticators of AffirmId. And, while AffirmId’s implementation is unique in many respects, in the end it is just another ho-hum authenticator with built in bridging to the future. Now let’s explore what sets AffirmId apart from all the others, that key unique feature every authenticator should have but only AffirmId does have, built in personal identifier. Click here for an introduction to Personal Identification.
Secure authentication is best done using three factors: something you know; something you have; and something you are. The players that take part in three-factor authentication include:
- “Relying Party” provides access to secure resources or facilities to those seeking access after establishing the requestors identity and rights. Doing so may be handled directly by the RP or the task may be handed off to another principal such as a Security Token Service or an OpenID service.
- “Security Token Service” if called upon authenticates the client a part of a Single Sign-On process. The STS verifies the requesting client identity and issues a token containing claims about the clients identity.
- “Client” is a device or application acting as an intermediary, such as a browser for example, between the user and a secure resource or facility managed by the RP. It interacts directly with the user and in multi-factor authentications with a device the user must have in their possession.
- “Authenticator” is something you have at the time of authentication. This may take the form of a mobile device App or self-contained token device. Regardless of which, affirmation of user presence in the authentication process is its primary responsibility.
- “First User” is the person in possession of and assignee of an Authenticator. Authenticator possession infers assumed possession by First User. Affirmed possession by First User assures Authenticator possession status.
Registration and Authentication in a Multi-Factor Model:
The multi-factor model requires Registration process before there can be Authentications. And, there is the Multi-Factor Authentication process by which a First User seeking access affirms to the Relying Party they are who they claim to be.
Registration is a process the user performs to register their AffirmId mobile device and authenticator with a Relying Party. It begins with a user request to the RP who then then initiates a series of exchanges with the user and their device, collecting user identification information and:
- if registering an OTP account then configuring TruUAtuh with account secrets and identifiers provided by the RP, often delivered by use of a QR code, is all that’s required; or
- if registering a U2F or FIDO2 account, there will be exchanges between the RP and yourself as well as with your AffirmId authenticators during which you will have to demonstrate intent by tapping the Yellow authenticator button.
Authentication is required to access secured resources or facilities. It begins with an indication to the RP of your intent:
- if its a 2FA account then authentication normally includes providing your username, a password, and a 6 digit OTP code produced by AffirmId 2FA authenticator to the RP; or
- if its a U2F or FIDO2 account then authentication begins by providing your username and password followed by, when requested, tapping the Yellow authenticator button; or
- in some FIDO2 implementations there is no password so authentication begins with the username and, when prompted to do so, tapping the Yellow authenticator button.
Copyright © 2020, Rick Hallock