Wiki · Concept · Last reviewed June 25, 2026

Credential Management API

The Credential Management API is the browser mediation surface behind navigator.credentials: a common entry point where websites request, create, store, or block silent use of credentials while the user agent manages credential stores, prompts, and credential-type extensions.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: identity, browser API, credentials, agents, authentication, user mediation

Snapshot

Core surface: navigator.credentials, a CredentialsContainer with get(), create(), store(), and preventSilentAccess().
Standards status: W3C Credential Management Level 1 is a Recommendation-track Working Draft, with a latest published draft dated July 2, 2026.
Defined in Level 1: the base Credential model plus PasswordCredential and the legacy FederatedCredential.
Extended elsewhere: WebAuthn defines PublicKeyCredential, FedCM uses browser-mediated federated sign-in, and the Digital Credentials API builds on the same surface for wallet-style credentials.
Security boundary: the API mediates credential ceremonies; it does not by itself prove legal identity, assign authorization, protect a logged-in session, or govern later agent actions.
Governance hinge: record user mediation, origin, credential type, session change, and delegated action without storing passwords, one-time codes, private keys, biometric data, or full assertions.

Definition

The Credential Management API is a web platform API family for letting a website interact with credentials through the user agent rather than by scraping forms, guessing password-manager behavior, or inventing a separate prompt for each credential technology. The W3C Level 1 draft defines the base Credential interface and the CredentialsContainer exposed as navigator.credentials.

The API is not one credential format. It is a mediation layer. Level 1 defines password and legacy federated credential interfaces, while other specifications extend or use the same browser surface. WebAuthn defines PublicKeyCredential for scoped public-key authentication, FedCM defines a browser-mediated federated-login flow, and the Digital Credentials API covers mediated presentation and issuance of wallet-style credentials.

The term should stay close to Digital Identity, NIST Digital Identity Guidelines, Device Bound Session Credentials, and AI Agent Identity, because credential retrieval, authentication, session continuity, authorization, and delegated machine action are related but separate controls.

Current Context

Credential Management Level 1 remains draft standards work. W3C's publication history lists a July 2, 2026 Working Draft, and the status text says Working Draft publication does not imply W3C endorsement and that the document should be cited as work in progress. That matters because production behavior depends on browser implementation, credential type, origin context, enterprise policy, and platform credential managers.

The live web platform is layered. MDN summarizes the API around four credential families: password credentials, federated identity credentials, one-time-password credentials, and WebAuthn public-key credentials. But that summary is an implementation-facing map, not proof that every browser supports every credential type in the same way. Operational claims should name the browser, version, operating system, credential type, mediation mode, and test date.

The identity stack around the API is also changing. WebAuthn Level 3 is a W3C Candidate Recommendation Snapshot dated May 26, 2026. The Digital Credentials API is a separate W3C Working Draft dated June 26, 2026. FedCM's W3C technical report remains a First Public Working Draft dated August 20, 2024. These documents can share vocabulary and browser entry points, but they should not be collapsed into one "credential API" claim.

How It Works

The basic pattern is simple. A site can ask the browser to create or store a credential after a successful sign-in, and later ask the browser to retrieve a credential that may help sign the user back in or complete a step-up ceremony. The W3C draft exposes this through a secure-context API on navigator.credentials.

The W3C draft frames the API as a way to reduce brittle sign-in heuristics. Browsers already save passwords and fill forms, but that behavior often depends on guessing which forms, redirects, and page states mean sign-in, sign-out, password change, or account switch. Credential Management lets a cooperating site tell the browser that a credential worked, should be stored, should be retrieved, or should stop being available silently.

Origin and embedding context matter. The Level 1 draft treats credentials as effective for origins, exposes the API only in secure contexts, and restricts some password and federated credential collection to contexts that are same-origin with their ancestors. Those boundaries are part of the security model; a credential prompt in an embedded, cross-origin, or automated browsing context should not be treated as equivalent to a first-party login form.

Credential Boundaries

Password credentials: can help coordinate password-manager storage and retrieval, but they are still passwords. They need transport security, phishing-resistant alternatives, leak monitoring, strong recovery, and protections against script and extension compromise.
Federated credentials: Level 1 includes FederatedCredential, while modern browser-mediated federation is handled through FedCM and IdentityCredential. Claims about one should not be used as evidence about the other.
One-time passwords: OTP retrieval can improve user experience, but a one-time code is not equivalent to phishing-resistant authentication and does not settle account recovery or fraud risk.
Public-key credentials: WebAuthn credentials are created and used through navigator.credentials.create() and navigator.credentials.get(), but the WebAuthn specification defines the relying-party, authenticator, challenge, attestation, and origin rules.
Digital credentials: wallet-style credential presentation and issuance are Digital Credentials API work, not Credential Management Level 1 itself. A browser-mediated request can improve ceremony visibility without proving verifier authority or issuer trust.

User Mediation

User mediation is the core governance concept. A credential request can be silent, optional, conditional, or required depending on credential type and browser support. Silent access may support seamless return visits, but it also changes the privacy and accountability meaning of a page load because a session may be restored before the user has made a fresh choice.

The preventSilentAccess() method matters because it lets a site tell the browser that automatic sign-in should stop for an origin, such as after sign-out. The draft warns that a careless or malicious site could neglect this call, so users still need browser controls to require mediation and remove stored credentials.

For high-impact flows, mediation should be treated as an evidence event rather than a UI detail. The record should distinguish whether the browser showed a chooser, whether the request was silent, whether the user selected an account or authenticator, whether the site was switching users, and whether the session gained new authority after the ceremony.

Agent Context

For browser agents, credential mediation is a boundary between authentication and delegation. A credential proves or helps establish who the user is to a site. It does not prove that an agent should be allowed to read every account page, submit every form, buy goods, change settings, or share identity attributes.

An agent should not scrape, store, replay, or infer credentials from page content. It should treat browser credential prompts as privileged ceremonies that require user intent. If an agent sees a sign-in surface, password manager prompt, passkey prompt, FedCM prompt, or digital-credential prompt, the governance record should distinguish the user's authentication act from any later agent action.

The safest pattern is explicit delegation after authentication. A user may sign in with a password, passkey, OTP, federated account, or digital credential, but the agent still needs scoped authority, a task purpose, time limits, approvals for high-impact actions, and revocation. A borrowed human browser session is not an agent identity model.

Governance Use

A useful implementation keeps credential mediation visible in AI Audit Trails and security logs without exposing secrets. It records when a credential request was initiated, which origin requested it, which credential type was involved, whether a user-facing chooser or prompt appeared, whether silent access was blocked or permitted, and what authority became available after sign-in.

This is especially important for AI browsers and computer use. Automated browsing can make login feel like an implementation detail, but login changes the legal, financial, and privacy context of every later action. Credential Management should be treated as a control surface, not a convenience hook.

NIST SP 800-63-4 is useful context because it separates authentication, federation, assurance levels, session management, and wallets. Credential Management can participate in a sign-in ceremony, but governance still has to answer which assurance level is needed, what session was created, which party is relying on the credential, and which later actions require step-up authentication or human confirmation.

Limits

The API does not replace strong authentication, authorization, fraud controls, session security, account recovery, or step-up confirmation. A password credential remains a password credential. A public-key credential inherits WebAuthn's stronger phishing resistance, but the Credential Management surface itself does not decide what a post-login agent may do.

It also does not make scripts, extensions, iframes, or automated browsers trustworthy. Password credentials can still be exposed to JavaScript when returned to the site, sessions can still be abused after sign-in, and a compromised browser environment can still act with the user's authority. Treat the API as a mediation surface, not a complete security boundary.

Implementation is browser-dependent. The W3C draft describes the intended model; MDN and browser documentation should be checked for current support and behavior. Operational claims should name the browser, credential type, mediation setting, origin, embedding context, and date tested.

Minimum Evidence Record

For agent-mediated login or high-impact browser automation, preserve enough evidence for security review, incident response, and user contestability without turning credentials into logs.

Request: origin, embedded origin if relevant, relying party or identity provider, credential type, method called, mediation mode, user activation, and secure-context status.
Ceremony: prompt or chooser outcome, account-switch event, sign-in or sign-out event, preventSilentAccess() use, and whether automatic sign-in was attempted or blocked.
Session: session created, assurance level if used, step-up event, post-login scopes, recovery path, and revocation path.
Agent trace: agent task identifier, human approval, tool or browser action following authentication, blocked actions, and high-impact changes made inside the authenticated session.
Redaction rule: do not log passwords, OTP values, private keys, biometric data, raw WebAuthn assertions, raw identity tokens, full digital credentials, or user identifiers beyond what the audit purpose requires.

Defense Pattern

Separate retrieval from authorization. A credential that signs a user in should not automatically authorize every later action by a user, agent, or automation.
Prefer phishing-resistant credentials where risk warrants it. Use WebAuthn or other phishing-resistant authentication for sensitive actions rather than treating saved passwords and OTPs as equivalent.
Use explicit mediation for sensitive moments. Account switching, payment, export, administrator changes, credential presentation, and destructive actions should require fresh user-visible confirmation.
Stop silent access on sign-out. Call preventSilentAccess() and test that the browser actually stops automatic reauthentication for the relevant origin and credential type.
Constrain agents after login. Use scoped delegation, sandboxing, action approvals, audit trails, and revocation rather than letting an agent inherit an entire browser session.
Test browser differences. Verify behavior across supported browsers, private modes, enterprise policies, iframe contexts, password managers, passkey providers, and platform credential managers.

Source Discipline

Use the W3C Credential Management draft and publication history for the core API and standards status; WebAuthn for public-key credential claims; FedCM for browser-mediated federated sign-in claims; Digital Credentials for wallet-style presentation and issuance claims; NIST SP 800-63-4 for authentication, federation, session, and assurance framing; and MDN or browser documentation for implementation-facing interface summaries. Do not collapse those layers into one identity system.

When writing implementation claims, say exactly which browser, version, operating system, credential type, method, mediation mode, origin relationship, and date were tested. "Supports Credential Management" is too broad to be useful unless the credential type and ceremony are named.

Spiralist Reading

Spiralism reads Credential Management as a struggle over who stages identity. A website wants seamless return. A browser wants a trustworthy ceremony. A user wants convenience without surrendering all future context. An agent wants the task to continue.

The humane design is not silent magic. It is legible mediation: this origin is asking, this credential type is involved, this user chose, and this later action is separate from the act of signing in.

Open Questions

Which credential ceremonies should browser agents be allowed to observe, summarize, or click?
How should audit logs prove that a prompt appeared without retaining the credential or turning sign-in into surveillance?
When should silent reauthentication be disabled by policy even if a browser and site can perform it?
How should websites distinguish human authentication, agent delegation, account switching, and post-login automation in user-facing records?
Can browser credential mediation preserve accessibility and recovery without making identity prompts too easy to ignore?

Sources

W3C Web Application Security Working Group, Credential Management Level 1, Working Draft, July 2, 2026.
W3C, Credential Management Level 1 publication history.
MDN Web Docs, Credential Management API.
MDN Web Docs, CredentialsContainer: get() method.
W3C Web Authentication Working Group, Web Authentication: An API for accessing Public Key Credentials Level 3, Candidate Recommendation Snapshot, May 26, 2026.
W3C Federated Identity Working Group, Federated Credential Management API, First Public Working Draft, August 20, 2024.
W3C Federated Identity Working Group, Digital Credentials, Working Draft, June 26, 2026.
NIST, SP 800-63-4 Digital Identity Guidelines, final Revision 4 suite, July 2025.

Return to Wiki