The holidays are well and truly over, time to get serious - now is the perfect time to read specifications! If you are planning to read the WebAuthn specification, you can ease into the terminology in a simple way - take a cruise through the W3C Credential Management (aka CredMan) specification first. CredMan sets up the object model for the Credential object model that WebAuthn's PublicKeyCredential extends. This post will be an overview of the CredMan spec, geared for folks who want to call the API as clients, not for those few and proud who are tasked with implementation of the API within a user agent.
CredMan Base Definitions
The CredMan API defines three actions (and an object constructor):
In addition to the task-specific actions and data dictionaries noted above, one data dictionary is defined that can be optionally added to any of the other dictionaries:
CredMan defines an action as user mediated if the action “takes place after gaining a user’s explicit consent”. Choosing an account from a credential chooser during a get() or confirming storage of a credential both count as user-mediated actions.
Origin-bound credentials require user mediation by default, meaning that user agents must interact with the user in some decision-oriented way before taking actions like storing or retrieving credentials – however in the interests of creating a user experience that is contextually intelligent, options exist to change the circumstances where user mediation takes place:
Types of Credential
CredMan extends the credential base class for two uses: Passwords and Federation discovery information. The W3C WebAuthn spec adds a third extension for cryptographic public keys.
When a relying party invokes the interface, the user agent engages to create, retrieve, or change a shared secret stored in a credential store such as a password manager. The credential store might be built into the user agent or might just be facilitated by the user agent. Note that the relying party does not need to know anything about how the credential store works, or even which user agent has been invoked. That is the beauty of standards!
There are a ton of great examples in the spec, take a look through the link above. Here is a quick summary of how PasswordCredential modifies the Credential base class:
PasswordCredentials are origin bound - the user agent stores a different shared secret per web origin, and takes on the responsibility to ensure that the secret-origin relationship is enforced.
Interacting with federated credentials also involves talking to a credential store, but instead of managing a shared secret, the user agent stores and retrieves the metadata necessary to initiate a federated authentication request to a remote identity provider. Whenever the user agent can supply a FederatedCredential to a requesting relying party, the relying party can bypass Identity Provider discovery prompts such as NASCAR interfaces and immediately initiate federation. This can represent a significant improvement in end user experience.
FederatedCredential details of note:
FederatedCredential is also origin-bound.
Stay Tuned for PublicKeyCredential
Now that you see how PasswordCredental and FederatedCredential work, imagine the same paradigm applying to a cryptographic key, where a client can request a user agent to create or retrieve a public key from a user-controlled cryptographic platform or device. W3C WebAuthn takes on this challenge. Stay tuned for the next blog entry, where we will describe how WebAuthn extends the Credman API, and how a very small number of options and methods can grant relying parties access to a vast and growing set of highly secure user authentication options.
Edge browser doesn’t support either PasswordCredential or FederatedCredential but both Firefox and Google have support, you could try this demo app. Google has useful sample code here and Mozilla’s API documentation is here.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.