Credential Management, also referred to as a Credential Management System (CMS), is an established form of software that is used for issuing and managing credentials as part of public key infrastructure (PKI).
CMS software is used by governments and enterprises issuing strong two-factor authentication (2FA) to employees and citizens. The CMS integrates with the components of PKI to provide one joined-up solution for IT departments to issue and manage credentials to a wide selection of devices, including smart cards, USB keys, smartphones, laptops and desktop computers.[1]
Credential Management is also a proposed application programming interface (API) under development by the World Wide Web Consortium for standardizing aspects of how password managers used by web user agents (web browsers and other applications) create, store, use, and modify username and password combinations for logins, in addition to the management of "federated" credentials (such as single sign-on tokens) by user agents. The API is being developed by the W3C's Web Application Security Working Group, and has been in Working Draft status since April 2016. It is a Recommendation-track proposal, expected to become an accepted standard, but may undergo significant changes before that occurs.[2][3] The Credential Management API has already been extended by the WebAuthn (Web Authentication) proposal, which reached Candidate Recommendation status in April 2018 and adds the ability to handle public-key authentication.[4]
It is common for modern web browsers to be able store and automatically enter usernames and passwords for website logins, though they have often used suboptimal heuristics for guessing which form fields and data are supposed to be filled/stored, resulting in inconsistent and sometimes faulty behavior. Browsers can also have trouble filling in login forms for federated identities, such as when a user connecting to a website uses an account for a third-party web service (like Facebook, Google, or Twitter) to authenticate and provide identity information. The Credential Management specification also aims to streamline the process of changing passwords so that the locally stored password on the client can be updated at the same time it is modified on the server.
Google Chrome has included some support for Credential Management since version 51,[5] released in May 2016,[6] and Opera has included support since version 44,[5] released in April 2017.[7] Mozilla Firefox includes a subset of the API to support WebAuthn since version 60, released in May 2018.[8]
API
editAs of the August 2017 working draft,[9] user agents supporting the Credential Management API must implement a "credential store" for persistent storage of credential objects, and should also include a "credential chooser" to allow users to interact with the objects and allow or deny their use for logins. Credentials will ideally have a name and favicon associated with them, perhaps along with other related information, to help distinguish which website or service they are used for, as well as the ability to differentiate credentials for multiple accounts on the same site.
The API defines four main JavaScript methods, which expose the CredentialsContainer interface: navigator.credentials.create(), navigator.credentials.store(), navigator.credentials.get(), and navigator.credentials.preventSilentAccess(). It also specifies the top-level Credential interface object, with descendant PasswordCredential and FederatedCredential object types. (WebAuthn also defines a PublicKeyCredential interface object.) The API is only available when a user agent is connected to a secure (HTTPS) website. Browsers can still implement auto-filling of login information on non-secure sites, but must not allow such sites to benefit from the automation that the API provides, since it could lead to accidental exposure of passwords or other credentials. In addition, API access is only allowed in top-level windows, and not within <iframe> elements or other nested browsing contexts.
The navigator.credentials.create() method is used for constructing credential objects in memory, and store() triggers writing an object to the credential store following a successful login. get() requests potentially relevant credentials from storage, which may be presented to the user in a credential chooser. When retrieval requests are made, user agents are required to prompt the user for authorization by default, though the user interface can allow a flag to be set that allows "silent" authorization without presenting a prompt. A website can reset that flag with the preventSilentAccess() method, recommended for use when logging out.
See also
editReferences
edit- ^ "Credential Management System - MyID CMS". Intercede. Retrieved 2019-07-31.
- ^ West, Mike, ed. (2017-08-04). "Credential Management Level 1". W3C. Retrieved 2018-05-12.
- ^ "W3C Web Application Security Working Group". Retrieved 2018-05-12.
- ^ Balfanz; et al. (2018-03-20). "Web Authentication: An API for accessing Public Key Credentials Level 1". W3C. Retrieved 2018-05-12.
- ^ a b "Credential Management API". MDN Web Docs. Mozilla. 2018-02-20. Retrieved 2018-05-13.
- ^ "Stable Channel Update". Chrome Releases. 2016-05-25. Retrieved 2018-05-13.
- ^ Mielczarczyk, Kornelia (2017-04-05). "Opera 44.0.2510.1159 Stable update". Opera Blogs. Retrieved 2018-05-13.
- ^ "Firefox — Notes (60.0) — Mozilla". Mozilla. 2018-05-09. Retrieved 2018-05-13.
- ^ West, Mike, ed. (2017-08-04). "Credential Management Level 1, W3C Working Draft, 4 August 2017". Retrieved 2018-05-12.