Digital Credentials

W3C Editor's Draft

More details about this document
This version:
https://w3c-fedid.github.io/digital-credentials/
Latest published version:
https://www.w3.org/TR/digital-credentials/
Latest editor's draft:
https://w3c-fedid.github.io/digital-credentials/
History:
https://www.w3.org/standards/history/digital-credentials/
Commit history
Editors:
Marcos Caceres ( Apple Inc. )
Tim Cappalli ( Okta )
Mohamed Amir Yosef ( Google Inc. )
Former editor:
Sam Goto ( Google Inc. ) - Until
Feedback:
GitHub w3c-fedid/digital-credentials ( pull requests , new issue , open issues )

Copyright © 2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply.

Abstract

This document specifies an API to enable user agents to mediate presentation and issuance of digital credentials such as a driver's license, government-issued identification card, and/or other types of digital credential . The API builds on Credential Management Level 1 as a means by which to request or issue a digital credential from a user agent or underlying platform.

Status of This Document

This is a preview

Do not attempt to implement this version of the specification. Do not reference this version as authoritative in any way. Instead, see https://w3c-fedid.github.io/digital-credentials/ for the Editor's draft.

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index .

This document was published by the Federated Identity Working Group as an Editor's Draft.

Publication as an Editor's Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.

This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .

This document is governed by the 18 August 2025 W3C Process Document .

1. Introduction

This section is non-normative.

This document defines an API enabling a website to request presentation and issuance of a digital credential .

The API design is agnostic to credential formats and includes support for multiple presentation protocols and issuance protocols . See 5. Protocols .

The API is designed to support the following goals:

Digital credentials of many types can be presented and issued using this API. Examples of these types include:

2. Examples of usage

This section is non-normative.

The following examples illustrate how the Digital Credentials API can be used to request and issue digital credentials.

2.1 Feature Detection

Before using the Digital Credentials API, it's important to check if the user agent supports the necessary features. This can be done using the following code:

Example 1 : Checking for API support 
if (typeof DigitalCredential !== "undefined") {
  // Digital Credentials API is supported
} else {
  // Digital Credentials API is not supported
}

2.2 Checking if protocol is allowed

The userAgentAllowsProtocol () static method can be used to check if the user agent allows a specific protocol for digital credential issuance or presentation. This is useful for checking which protocols are allowed by the user's browsers prior to making an API call.

Example 2 : Using the userAgentAllowsProtocol() static method 
if (DigitalCredential.userAgentAllowsProtocol("example-protocol")) {
  // DC API supported. Proceed with issuance or presentation.
} else {
  // DC API not supported. Fall back to, for example,
  // a traditional HTML form-based approach.
  showHTMLForm();
}

Alternatively, one can check for support of multiple protocols, filtering out those that are not supported:

Example 3 : Checking multiple protocols with userAgentAllowsProtocol() 
const protocols = [
  "example-issuance-protocol",
  "another-issuance-protocol"
];
const supportedProtocols = protocols.filter(DigitalCredential.userAgentAllowsProtocol);
if (supportedProtocols.length > 0) {
  // At least one protocol is supported. Proceed with issuance.
} else {
  // No protocols are supported. Fall back to a different issuance method.
}

2.3 Requesting a digital credential

The following example shows how to request a digital credential using the Digital Credentials API. The entry point for the API is the navigator.credentials. get () method, which is used to request a digital credential from the user agent. If the user agent supports presentation , it allows the user to select a digital credential through a credential chooser :

Example 4 : Requesting a digital credential 
<button>Verify Identity</button>
<script>
  const button = document.querySelector("button");
  button.addEventListener("click", async () => {
    const protocol = "example-request-protocol";
    // Check for DC API and protocol support
    if (!DigitalCredential.userAgentAllowsProtocol(protocol)) {
      // The browser doesn't allow the use of this protocol.
      // Fall back to a different verification method.
      showTraditionalVerificationForm();
      return;
    }
    try {
      const credential = await navigator.credentials.get({
        digital: {
          requests: [{
            protocol,
            data: { /* request data */ }
          }]
        }
      });
      // Post it back to the verifier server for decryption and verification
      const response = await fetch("/verify-credential", {
        method: "POST",
        headers: {
          "Content-Type": "application/json"
        },
        body: JSON.stringify(credential)
      });
      // Check response
      if (!response.ok) {
        throw new Error("Failed to verify credential");
      }
      // Render the verification result
      displayVerificationResult(await response.json());
    } catch (error) {
      console.error("Error requesting digital credential:", error);
    }
  });


</

script

>

Similarly, when a site needs to issue a digital credential, the Digital Credentials API mediates the issuance of a digital credential between the site, the user agent, and the holder .

2.4 Issuing a digital credential

The following example shows how to request the issuance of a digital credential using the Digital Credentials API. To issue a digital credential, a site calls the navigator.credentials. create () method, which, if the user agent supports issuance, would initiate the issuance flow:

Example 5 : Requesting issuance of a digital credential 
<button>Request Digital Credential Issuance</button>
<script>
  const button = document.querySelector("button");
  button.addEventListener("click", async () => {
    const protocol = "example-issuance-protocol";
    // Check for DC API and protocol support
    if (!DigitalCredential.userAgentAllowsProtocol(protocol)) {
      // The browser doesn't allow the use of this protocol.
      // Fall back to a different issuance method.
      showTraditionalIssuanceForm();
      return;
    }
    try {
      const credential = await navigator.credentials.create({
        digital: {
          requests: [{
            protocol,
            data: { /* issuance request data */ }
          }]
        }
      });
    } catch (error) {
      console.error("Error issuing digital credential:", error);
    }
  });


</

script

>

2.5 Requesting a digital credential across origins

The specification allows usage of the API for presenting credentials from a remote/third-party origin via the "digital-credentials-get" Permissions Policy. This is useful for scenarios where a website wants to request digital credentials from a verification service that is hosted on a different origin. The Permissions Policy can be set on an iframe that embeds the website that wants to use the API. Here is an example of how the Permissions Policy can be set on an iframe:

Example 6 : Requesting a digital credential across origins 
<iframe src="https://wallet-provider.example.com"
        allow="digital-credentials-get">

</

iframe

>

2.6 Issuing a digital credential across origins

Similarly, the specification allows usage of the API for issuing credentials from a remote/third-party origin via the "digital-credentials-create" Permissions Policy. This is useful for scenarios where a website wants to request issuance of a digital credential using an issuance service on a different origin. The Permissions Policy can be set on an iframe embedding the issuer's interface. Here is an example:

Example 7 : Issuing a digital credential across origins 
<iframe src="https://issuer.example.com"
        allow="digital-credentials-create">

</

iframe

>

3. Scope

This section is non-normative.

The following items are within the scope of this specification:

The following items are out of scope:

4. Model

Note : Definitions under discussion

The goal of the definitions in this section is to reuse or establish terminology that is common across a variety of digital credential formats and protocols. Discussions surrounding these definitions are active and the definitions are likely to change over the next several months.

Credential request
A presentation request or an issuance request .
Credential response
A presentation response or an issuance response .
Digital credential
A cryptographically signed digital document containing one or more claims made by an issuer about one or more subjects .
Note : Focus on digital credentials about people

This specification is currently focused on digital credentials pertaining to people.

Issuance protocol
A standardized protocol used for communication between an issuer and a holder during the issuance of a digital credential . The issuance protocol is identified by a protocol identifier . See 5. Protocols .
Issuance request
An issuance request is a request to issue a digital credential composed of some issuance request data and an issuance protocol .
Issuance request data
A data structure that an issuer or a user agent , via an issuance protocol , to request the issuance of a digital credential by an issuer .
Issuance response
A format that holder uses, via an issuance protocol , to respond to an issuance request by an issuer .
Presentation protocol
A standardized protocol used for presenting a digital credential between a holder and a verifier . A protocol is identified by a protocol identifier . See 5. Protocols .
Presentation request
A presentation request is a request for a digital credential composed of request data and a presentation protocol .
Presentation response
A format that a holder's software, such as a digital wallet, uses, via an presentation protocol , to respond to a presentation request by a verifier .
Protocol identifier
A string composed of one or more ASCII lower alpha code points , zero or more U+002D HYPHEN-MINUS code points , and zero or more ASCII digit code points (in any order). For example, "123a-protocol", "abc", or simply "a".
Request coordinator
See credential request coordinator .
Request data
A format that verifier software or a user agent uses, via an presentation protocol , to request a digital credential from a holder .

5. Protocols

Use of the following presentation protocols is defined by this specification.

A user agent MUST implement at least one of the presentation protocols — and it is RECOMMENDED that they implement all presentation and issuance protocols — listed in the table of supported presentation and issuance protocols .

Issue 439 Note : What Checking which protocols should a user agent implement? allows
In #401 , I suggested we add
Table of supported presentation and issuance protocols protocols
Identifier Presentation protocols Specification
Presentation protocols
openid4vp-v1-unsigned OpenID for Verifiable Presentations 1.0 OpenID for Verifiable Presentations 1.0 A.3.1. Unsigned Request § A.3.1. Unsigned Request
openid4vp-v1-signed OpenID for Verifiable Presentations 1.0 OpenID for Verifiable Presentations 1.0 A.3.2. Signed Request § A.3.2. Signed Request
openid4vp-v1-multisigned OpenID for Verifiable Presentations 1.0 OpenID for Verifiable Presentations 1.0 A.3.2.2. JWS JSON Serialization § A.3.2.2. JWS JSON Serialization (Multi-signed requests)
org-iso-mdoc ISO/IEC 18013-7:2025 ISO-compliant driving licence, Part 7: Mobile driving licence (mDL) add-on functions ISO/IEC 18013-7:2025 ISO-compliant driving licence, Part 7: Mobile driving licence (mDL) add-on functions Issuance protocols § Annex C
Issuance protocols
openid4vci-v1 OpenID for Verifiable Credential Issuance 1.0 OpenID for Verifiable Credential Issuance 1.0 § Coming Soon
Issue : API Integration : API Integration

6. 6. Credential Request Coordinator

credential request coordinator digital credential top-level traversable top-level traversable child navigables interaction states credential request coordinator active promise

The credential request coordinator is a user-agent-defined component that mediates digital credential interactions through the top-level traversable . Each top-level traversable has exactly one associated coordinator. The coordinator ensures that at most one interaction is active across all child navigables , orchestrates the end-to-end flow of presentation or issuance, and manages transitions between interaction states .

The credential request coordinator maintains an active promise , which the user agent initializes as null . Through this Promise , the coordinator credential request reflects the state of the asynchronous credential request workflow to script and either resolves credential response with a credential response when the interaction completes successfully, or rejects when processing fails, when the user cancels the request via the UI, or when script aborts the operation via an AbortSignal credential request coordinator abort signal .

The credential request coordinator maintains an abort signal , which the user agent initializes as null credential request coordinator abort algorithm .

The credential request coordinator maintains an abort algorithm , which the user agent initializes as null credential request coordinator Validates and transforms presentation or issuance inputs and outputs. Requests the platform to display, for user selection, the credentials that are available for the current request and/or the holders that can handle the current request. The availability of credentials and holders is determined by matching the request parameters, user consent, and platform policy. Manages .

The credential request coordinator :

A user agent MAY delegate some or all coordinator responsibilities to external wallet applications, platform components, or other trusted entities according to user or platform policy.

Note

6.1 6.1 Interaction states

credential request coordinator interaction states credential request "

The credential request coordinator has a finite set of interaction states , which are used to manage the lifecycle of a credential request :

" idle ": credential request " ":
No credential request is currently in progress.
" requesting ": credential request " ":
A credential request is in progress and the user interface is presented.
" aborting ": signal abort ":
The active interaction is being canceled due to an error, a user action, or a signal abort ; the coordinator is cleaning up before returning to " ; the coordinator is cleaning up before returning to " idle ". ".

The coordinator is initialized in the idle interaction state interaction state .

6.2 6.2 Prepare credential requests

prepare credential requests

To prepare credential requests given a Document document , a sequence of DigitalCredentialGetRequest or DigitalCredentialCreateRequest requests , a Promise promise , and an optional AbortSignal signal :

  1. Issue
    Pull request #420

6.3 6.3 Abort the credential request

To be written.

6.4 6.4 Complete credential request with error

complete credential request with error

To complete credential request with error given a Promise promise and (a JavaScript Value) error :

  1. Assert credential request coordinator : the credential request coordinator 's active promise 's active promise is promise .
  2. Queue a global task DOM manipulation task source Queue a global task on the DOM manipulation task source given promise 's relevant global object If the credential request coordinator 's relevant global object 's active promise to perform the following steps:
    1. If the credential request coordinator 's active promise Let is not promise , then return.
    2. Let signal credential request coordinator be the credential request coordinator 's abort signal Let 's abort signal .
    3. Let abortAlgorithm credential request coordinator be the credential request coordinator 's abort algorithm If 's abort algorithm .
    4. If signal is not null and abortAlgorithm is not null :
      1. Remove abortAlgorithm from signal Set the credential request coordinator .
    5. Set the credential request coordinator 's abort signal 's abort signal to null Set the credential request coordinator .
    6. Set the credential request coordinator 's abort algorithm 's abort algorithm to null .
    7. Reject promise with error Set the credential request coordinator .
    8. Set the credential request coordinator 's active promise 's active promise to null Set the credential request coordinator interaction state to " .
    9. Set the credential request coordinator interaction state to " idle ". ".

6.5 6.5 Present the credential request

To be written.

7. 7. The Digital Credentials API

The Digital Credentials API leverages the Credential Management Level 1 Credential Management Level 1 user agents specification, allowing user agents to mediate the issuance and presentation digital credentials of digital credentials .

The API allows requesting digital credential credential chooser digital credential a digital credential from the user agent, which in turn presents a credential chooser to the user, allowing them to select a digital credential that can fulfill the request. This is done by the website calling the navigator.credentials. get () request a method, which runs the request a Credential algorithm of Credential Management Level 1 Credential Management Level 1 . That algorithm then calls back into this specification's DigitalCredential interface's [[DiscoverFromExternalSource]]( origin , options , sameOriginWithAncestors ) requesting issuance digital credential internal method.

Additionally, the API also allows requesting issuance of a digital credential , which initiates an mediated issuance flow between the user agent and/or a holder . This is done by calling the navigator.credentials. create () create a credential method, which runs the create a credential algorithm of Credential Management Level 1 Credential Management Level 1 . That algorithm then calls back into this specification's DigitalCredential interface's [[Create]]( origin , options , sameOriginWithAncestors ) internal method.

Please see 8. 8. Integration with Credential Management Level 1 Credential Management Level 1 for complete details of how to integrate with the Credential Management Level 1 Credential Management Level 1 specification.

7.1 7.1 Extensions to CredentialRequestOptions dictionary 

WebIDLpartial dictionary CredentialRequestOptions {
  DigitalCredentialRequestOptions digital;
};

7.1.1 7.1.1 The digital member

The digital digital credential member allows for options to configure the request for a digital credential .

7.2 7.2 The DigitalCredentialRequestOptions dictionary 

WebIDLdictionary DigitalCredentialRequestOptions {
  required sequence<DigitalCredentialGetRequest> requests;
};

7.2.1 7.2.1 The requests member

The requests presentation protocol request data specify an presentation protocol and request data , which the user agent MAY match against a holder's software, such as a digital wallet.

7.3 7.3 The DigitalCredentialGetRequest dictionary

The DigitalCredentialGetRequest presentation request presentation protocol request data dictionary represents a presentation request . It is used to specify an presentation protocol and some request data , which the user agent MAY match against software used by a holder, such as a digital wallet. 

WebIDLdictionary DigitalCredentialGetRequest {
  required DOMString protocol;
  required object data;
};

7.3.1 7.3.1 The protocol member

The protocol presentation protocol member denotes the presentation protocol .

The protocol member's value is one of the protocol identifiers defined in DigitalCredentialPresentationProtocol .

7.3.2 7.3.2 The data member

The data request data member is the request data to be handled by the holder's credential provider, such as a digital identity wallet.

7.4 7.4 Extensions to CredentialCreationOptions dictionary 

WebIDLpartial dictionary CredentialCreationOptions {
  DigitalCredentialCreationOptions digital;
};

7.4.1 7.4.1 The digital member

The digital digital credential member allows for options to configure the issuance of a digital credential .

7.5 7.5 The DigitalCredentialCreationOptions dictionary 

WebIDLdictionary DigitalCredentialCreationOptions {
  required sequence<DigitalCredentialCreateRequest> requests;
};

7.5.1 7.5.1 The requests member

The requests issuance protocol request data specify an issuance protocol and request data , which the user agent MAY forward to a holder .

7.6 7.6 The DigitalCredentialCreateRequest dictionary

The DigitalCredentialCreateRequest issuance request issuance protocol request data dictionary represents an issuance request . It is used to specify an issuance protocol and some request data , to communicate the issuance request between the issuer and the holder. 

WebIDLdictionary DigitalCredentialCreateRequest {
  required DOMString protocol;
  required object data;
};

7.6.1 7.6.1 The protocol member

The protocol issuance protocol member denotes the issuance protocol .

The protocol member's value is one of the protocol identifiers defined in DigitalCredentialIssuanceProtocol .

7.6.2 7.6.2 The data member

The data request data member is the request data to be handled by the holder's credential provider, such as a digital identity wallet.

7.7 7.7 The DigitalCredential interface

The DigitalCredential digital credential interface represents a conceptual digital credential .

The DigitalCredential user mediation interface mandates user mediation for all operations to ensure user control and consent.

To simplify the developer experience of get () calls involving a DigitalCredential user agents MUST NOT , user agents MUST NOT throw an error if the mediation member is absent or has a value other than " member is absent or has a value other than " required ". Similarly, in ". Similarly, in create () calls involving a DigitalCredential user agents MUST NOT , user agents MUST NOT throw an error if the mediation member is absent or has a value other than " member is absent or has a value other than " required ". This makes " ". This makes " required " mediation an implicit and non-overridable behavior of the API. " mediation an implicit and non-overridable behavior of the API. 

WebIDLtypedef (DigitalCredentialPresentationProtocol or DigitalCredentialIssuanceProtocol) DigitalCredentialProtocol;
[Exposed=Window, SecureContext]
interface 

interface DigitalCredential : Credential {

  [Default] object toJSON();
  readonly attribute DigitalCredentialProtocol protocol;
  [SameObject] readonly attribute object data;
  static

  static boolean userAgentAllowsProtocol(DOMString protocol);

};

DigitalCredential origin bound instances are origin bound .

7.7.1 7.7.1 The protocol member

The protocol presentation protocol digital credential issuance protocol digital credential member is the presentation protocol that was used to request the digital credential , or the issuance protocol that was used to issue the digital credential .

7.7.2 7.7.2 The data member

The data member is the credential's response data. It contains the subset of JSON-parseable object types.

7.7.3 7.7.3 The userAgentAllowsProtocol() method

The userAgentAllowsProtocol () method allows digital credential verifiers presentation protocols issuance protocols to determine which presentation protocols and issuance protocols the user agent allows.

Note
presentation protocol issuance protocol MUST NOT

This method does not convey presentation protocol or issuance protocol support in the underlying OS/platform.

User agents MUST NOT vary the response value based on any information about availability of hardware, presence or configuration of software, wallets, credential providers, or digital credentials, or user configuration or preferences. If the response value varied, the user agent would introduce risks both of fingerprinting and of silently revealing other details about user behavior or configuration. The response value SHOULD vary only by user agent major version and indicate whether the browser supports distributing requests with that protocol to underlying platform or provider.

When this method is invoked, the user agent MUST If execute the following algorithm:

  1. If protocol enumeration value is not an enumeration value of DigitalCredentialProtocol , return false Return .
  2. Return true if the user agent allows protocol , otherwise return false .

7.8 7.8 Supporting Data Structures

Data structures, such as enumerations, which support DigitalCredential in this specification.

7.8.1 7.8.1 The DigitalCredentialPresentationProtocol enumeration

presentation protocols

This enumeration's values correspond to the supported presentation protocols listed in 5. Protocols { 5. Protocols .

WebIDLenum DigitalCredentialPresentationProtocol {
  "openid4vp-v1-unsigned",
  "openid4vp-v1-signed",
  "openid4vp-v1-multisigned",
  "org-iso-mdoc"
};

7.8.2 7.8.2 The DigitalCredentialIssuanceProtocol enumeration

issuance protocols

This enumeration's values correspond to the supported issuance protocols listed in 5. Protocols { 5. Protocols .

WebIDLenum DigitalCredentialIssuanceProtocol {
  "openid4vci-v1",
};

8. 8. Integration with Credential Management Level 1 Credential Management Level 1

8.1 8.1 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) internal method

[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) presentation requests credential chooser

When invoked, the [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) internal method, if the user agent doesn't support presentation requests ), call the default implementation of (e.g., the platform cannot provide a credential chooser ), call the default implementation of Credential 's 's [[DiscoverFromExternalSource]]( origin , options , sameOriginWithAncestors ) Let internal method with the same arguments. Otherwise:

  1. Let signal be options 's 's signal If , if present.
  2. If signal is aborted a promise rejected with , return a promise rejected with signal 's abort reason Let 's abort reason .
  3. Let global be this 's relevant global object Let 's relevant global object .
  4. Let document be global 's associated 's associated Document If .
  5. If document fully active descendant of a top-level traversable with user attention a promise rejected with a " is not a fully active descendant of a top-level traversable with user attention , return a promise rejected with a " NotAllowedError " " DOMException Let .
  6. Let requests be options 's 's digital 's 's requests If member.
  7. If requests is empty a promise rejected with is empty , return a promise rejected with a TypeError .
  8. For each For each request of requests :
    1. Serialize request 's 's data If serialization results in an to a JSON string.
    2. If serialization results in an exception a promise rejected with , return a promise rejected with that exception If .
  9. If global transient activation a promise rejected with a " does not have transient activation , return a promise rejected with a " NotAllowedError " " DOMException .
  10. Consume user activation Consume user activation of global Let .
  11. Let promise a new promise be a new promise in this 's relevant realm 's relevant realm .
  12. Prepare credential requests Prepare credential requests with document , requests , promise , and signal Return .
  13. Return promise .

8.2 8.2 [[Store]](credential, sameOriginWithAncestors) internal method

[[Store]](credential, sameOriginWithAncestors)

When invoked, the [[Store]](credential, sameOriginWithAncestors) MUST call the default implementation of Credential 's 's [[Store]]( credential , sameOriginWithAncestors ) internal method with the same arguments.

8.3 8.3 [[Create]](origin, options, sameOriginWithAncestors) internal method

[[Create]](origin, options, sameOriginWithAncestors) issuance requests

When invoked, the [[Create]](origin, options, sameOriginWithAncestors) internal method, if the user agent doesn't support issuance requests , call the default implementation of Credential 's 's [[Create]]( origin , options , sameOriginWithAncestors ) Let internal method with the same arguments. Otherwise:

  1. Let signal be options 's 's signal If , if present.
  2. If signal is aborted a promise rejected with , return a promise rejected with signal 's abort reason Let 's abort reason .
  3. Let global be this 's relevant global object Let 's relevant global object .
  4. Let document be global 's associated 's associated Document If .
  5. If document fully active descendant of a top-level traversable with user attention a promise rejected with a " is not a fully active descendant of a top-level traversable with user attention , return a promise rejected with a " NotAllowedError " " DOMException Let .
  6. Let requests be options 's 's digital 's 's requests If member.
  7. If requests is empty a promise rejected with is is empty , return a promise rejected with a TypeError .
  8. For each For each request of requests :
    1. Serialize request 's 's data If serialization results in an to a JSON string.
    2. If serialization results in an exception a promise rejected with , return a promise rejected with that exception If .
  9. If global transient activation a promise rejected with a " does not have transient activation , return a promise rejected with a " NotAllowedError " " DOMException .
  10. Consume user activation Consume user activation of global Let .
  11. Let promise a new promise be a new promise .
  12. Prepare credential requests Prepare credential requests with document , requests , promise , and signal Return .
  13. Return promise .

8.4 8.4 [[type]] internal slot

The DigitalCredential interface object interface object has an internal slot named [[type]] whose value is "digital".

8.5 8.5 [[discovery]] internal slot

The DigitalCredential interface object interface object has an internal slot named [[discovery]] whose value is "remote".

8.6 8.6 User permission

This section is non-normative. This section is non-normative. Digital Credential API powerful feature express permission

The Digital Credential API is a powerful feature that requires express permission from an end-user. This requirement is normatively enforced when calling CredentialsContainer 's 's get () method.

9. 9. Permissions Policy integration

policy-controlled features

This specification defines two policy-controlled features :

"digital-credentials-get" policy-controlled feature
A policy-controlled feature that allows a document to request default allowlists digital credentials. Its default allowlists is 'self' request a . The request a Credential algorithm serves as the policy enforcement point.
"digital-credentials-create" policy-controlled feature
A policy-controlled feature that allows a document to issue default allowlists digital credentials. Its default allowlists is 'self' create a . The create a Credential algorithm serves as the policy enforcement point.

10. 10. Security Considerations

This section is non-normative. This section is non-normative. credential responses

The sections that follow describe the API's security properties, the threats in scope, the assumptions on which security depends, and residual threats that remain after the mitigations are applied. This specification defines requirements for the user agent's behavior only when mediating credential responses .

Note

Other security considerations that depend on protocols, wallet implementations, operating systems, or transport security are described as expectations or preconditions, but these are not normatively required by this specification unless already normatively specified.

10.1 10.1 Threat Model

The threat model for this specification includes threats to this API and to adjacent standards of the ecosystem.

Issue 440 Issue 440 : Publish and link the Threat Model for Digital Credentials API : Publish and link the Threat Model for Digital Credentials API

As As @marcoscaceres suggested CfC has already been done at SING , an issue to remember is to publish the Threat Model and reference it. CfC has already been done at SING . in-scope threats out-of-scope threats

For this specification, threats fall into two categories: in-scope threats and out-of-scope threats .

10.1.1 10.1.1 In-Scope Threats

In-Scope Threats in-scope threats

In-Scope Threats are introduced or addressed by the DC API itself. The following are in-scope threats for this specification:

Coming soon
To be written...

10.1.2 10.1.2 Out of Scope Threats

Out-of-scope threats out-of-scope threats To be written...

Out-of-scope threats are those handled by protocols, wallets, OS platform security, or transport layers. Even if "out of scope", they are relevant because they influence the end-to-end security of credential presentation and issuance. The following defines the out-of-scope threats for this specification:

  • To be written...

10.2 10.2 Mitigations

in-scope threats

The following mitigations address in-scope threats through normative requirements in the specification.

To be written...

11. 11. Privacy Considerations

This section is non-normative. This section is non-normative.

Issue : Privacy Considerations section is a work in progress : Privacy Considerations section is a work in progress

This section is a work in progress as this document evolves.

The Digital Credentials API integrates into a complex ecosystem with multiple technology layers and various participants (including but not limited to verifiers , holders , and issuers ), each of which have to consider different aspects of user privacy. This specification does not attempt to exhaustively list all considerations for the different participants. We would like to refer these parties to a variety of other resources that explore the digital credentials threat model more holistically: ), each of which have to consider different aspects of user privacy. This specification does not attempt to exhaustively list all considerations for the different participants. We would like to refer these parties to a variety of other resources that explore the digital credentials threat model more holistically:

Instead, these considerations focus on the Digital Credentials API itself, and describe how user agents can satisfy their user agent duties in an implementation of the API, taking into account the relevant privacy properties of the ecosystem it interacts with.

The privacy considerations for digital credentials are not static. They will evolve over time as the ecosystem matures, and may be informed by the behavior of other actors in the ecosystem, improvements in other layers of the stack, new threats to user privacy, as well as changing societal norms and regulations.

It is expected that the various groups involved in the design and implementation of the Digital Credentials API actively monitor the evolving privacy landscape and participate in the corresponding evolution of the API.

11.1 11.1 Design Considerations and Alternatives

The Digital Credentials API is designed to mediate requests for digital credentials from websites, being agnostic to the credential format and the information contained in it, as well as the protocol used to exchange it. This and other key design choices are derived from the goal of providing a more secure and private credential exchange experience for users than the existing alternatives (e.g., [

The Digital Credentials API is designed to mediate requests for digital credentials from websites, being agnostic to the credential format and the information contained in it, as well as the protocol used to exchange it. This and other key design choices are derived from the goal of providing a more secure and private credential exchange experience for users than the existing alternatives (e.g., [ custom-schemes ]), that is still compatible with common exchange protocols for ease of adoption. ]), that is still compatible with common exchange protocols for ease of adoption.

The API provides the connection interface between verifiers and holders credential presentation protocol , i.e. the means by which a credential presentation protocol is initiated and the user switches to the holder application to select a credential. Solutions that have been used for this purpose in the past include QR codes and custom URL schemes. As documented in Presenting Credentials on the Web Presenting Credentials on the Web and Concerns with custom schemes for identity presentment Concerns with custom schemes for identity presentment presentation protocols user agent credential chooser , those solutions have security, privacy, and accessibility concerns.

With adoption of digital credential technology being driven by ecosystem demand and regulatory mandates, the Web platform offers an alternative to the aforementioned less-desirable technologies that is easy to use for developers, is compatible with existing credential presentation protocols ) to contextualize requests and prevent immediate exposure to holder applications response encryption and, most importantly, has better user privacy, security, and accessibility properties than these alternatives.

The Digital Credentials API offers the user agent the ability to intermediate on behalf of the user (e.g. in the form of a credential chooser ) to contextualize requests and prevent immediate exposure to holder applications . It also enforces certain minimum requirements on supported protocols, such as response encryption .

Note
purpose limitation user agents

11.2 11.2 Spectrum of Privacy

user agents user agent user agent

The Digital Credentials API serves a variety of use cases with different grades of data disclosure and individual users with different preferences depending on the context that they are in. Notably, the privacy properties of a credential exchange mediated by this API could be mandated by the legal and regulatory environment of an individual user.

This means that some users may not want, or be allowed, to use the most privacy-preserving means of exchanging credential information. Nonetheless, user agents 's responsibility to ensure that every user understands what data they are sharing and who will participate in the exchange of information, before the exchange begins. need to serve users with an experience that is private by default and protect them from harm.

Because of this spectrum of preferences and use cases, it may be difficult for a user agent to discern whether a user means to expose their personal information or is being tricked into doing so. It is thus the user agent 's responsibility to ensure that every user understands what data they are sharing and who will participate in the exchange of information, before the exchange begins.

11.3 11.3 Presentation Protocol and Credential Format

presentation protocol user agent

Because the Digital Credentials API sits at the center of an exchange that involves multiple independent parties, the presentation protocol 's goal of protecting user privacy. and credential format used by these parties for exchanging user information are crucial to the user agent 's goal of protecting user privacy.

11.3.1 11.3.1 Presentation Protocol Considerations for User Privacy

There are two requirements for protocols that I think need further elaboration: MUST have undergone privacy review [...] There are two requirements for protocols that I think need further elaboration:

MUST have undergone privacy review [...]

And MUST have undergone security review [...] Technically, a review saying "this protocol is awful in every way" satisfies these criteria. It would be more useful if there were a set of concrete privacy and security requirements that a protocol needed to satisfy, such a review would be able to say whether a standard was achieved or not. It might be the case that there are subjective elements to a review, but there should also be a minimum bar that each protocol needs to clear. This goes beyond the present set of requirements in the current inclusion criteria phoning home

MUST have undergone security review [...]

Technically, a review saying "this protocol is awful in every way" satisfies these criteria.

It would be more useful if there were a set of concrete privacy and security requirements that a protocol needed to satisfy, such a review would be able to say whether a standard was achieved or not. It might be the case that there are subjective elements to a review, but there should also be a minimum bar that each protocol needs to clear.

This goes beyond the present set of requirements in the current inclusion criteria . I don't have a comprehensive list to hand, but one should be possible to develop. And once developed, that list should be in the spec. For instance, does the protocol depend on phoning home ? Does the protocol (or the formats it conveys) guarantee unlinkability of presentations? Or - given that unlinkability doesn't make sense for some use cases - under what conditions does the API require the protocol provide unlinkability? What sort of transparency affordances does the protocol include? What sorts of covert channels are acceptable? ? Does the protocol (or the formats it conveys) guarantee unlinkability of presentations? Or - given that unlinkability doesn't make sense for some use cases - under what conditions does the API require the protocol provide unlinkability? What sort of transparency affordances does the protocol include? What sorts of covert channels are acceptable?

11.3.1.1 11.3.1.1 Selective disclosure
Selective disclosure data minimization

Selective disclosure is a fundamental technique for data minimization that allows holders to share the minimum required information that is requested by a verifier . Protocols are expected to facilitate selective disclosure by allowing the verifier to specify the exact claims needed.

11.3.1.2 11.3.1.2 Unlinkable presentations

Unlinkability is a property that ensures that, if a user presents attributes from a credential multiple times, verifiers cannot link these separate presentations to conclude they concern the same user (verifier-verifier linkability), or that verifiers cannot collude with issuers to report the exchange of a credential from a digital wallet to the issuer (verifier-issuer linkability). The former is a property that can be maintained by the holder and issuer , e.g. through issuing fresh credentials for individual verifiers Zero-Knowledge Proofs user agent user agent .

While the latter is achievable, e.g. through Zero-Knowledge Proofs , design choices of the API such as encrypted responses make it impossible for a user agent to prove that verifier-issuer unlinkability was achieved in practice. Nonetheless, protocols are requested to limit linkability wherever possible.

Note that unlinkability is exclusively a consideration for attributes that cannot be linked to a specific user identity. Inherently linkable attributes such as names, driver's license numbers or phone numbers do not benefit from unlinkability.

Through the Digital Credentials API, the user agent can help verifiers and digital wallets exchange unlinkable attributes, but, because of response encryption, it cannot guarantee that no linkable information is passed between verifiers user agents and digital wallets. It is recommended that user agents account for this fact in their user permission experience.

Issue 279 Issue 279 : Linkability and issuer involvement as a protocol requirement privacy-tracker

Which level of unlinkability is the goal for this API? Can we normatively enforce support for any particular unlinkability features?

11.3.1.3 11.3.1.3 "Phone home" mechanisms
"Phoning home"

"Phoning home" refers to scenarios where the presentation or verification of a digital credential causes a notification or communication back to the issuer user agents or another central entity, which can lead to tracking and profiling of individuals.

Similar to unlinkability, it is impossible for user agents to ensure that an issuer user agents user agent exposure of a request to the digital wallet application considerations for integrating multiple cooperating user agents ). isn't actively involved in the creation or validation of credential presentations after a user has given permission to proceed with a credential request. From that point on, the digital wallet application owns this decision. While some digital wallets can be considered user agents , it is generally recommended that the user agent implementing the Digital Credentials API designs its permission experience to prevent exposure of a request to the digital wallet application before user confirmation (keeping in mind considerations for integrating multiple cooperating user agents ).

Protocols are required to support mechanisms that allow issuers , digital wallets, and verifiers to avoid or reduce the dependence on "phone home" mechanisms.

Issue 279 Issue 279 : Linkability and issuer involvement as a protocol requirement privacy-tracker

Which level of unlinkability is the goal for this API? To what degree can the spec mandate restrictions to issuer involvement?

11.3.1.4 11.3.1.4 Unlinkable revocation

A common instance of issuer Cryptographic Accumulators involvement in a credential exchange is for credential revocation checks. This is particularly challenging when presentations are intended to be verifier-issuer unlinkable. When credential presentations are made unlinkable through the use of e.g. Zero-Knowledge Proofs, the credential formats used in protocols are expected to support offline revocation methods such as Cryptographic Accumulators . It is further expected that protocol design and specification discourages the involvement of verifiers for the purpose of revocation where possible.

Issue 280 Issue 280 : Can we require protocols to support unlinkable revocation? privacy-tracker registry

We should discuss whether unlinkable revocation techniques are practical enough to be required normatively.

11.3.1.6 11.3.1.6 Support for verifier authorization

Verifier authorization refers to the process by which a verifier proves its identity and demonstrates that it is legitimately entitled to request specific attributes or credentials. This is particularly useful when exchanging sensitive data, such as from government-issued credentials. Verifier authorization can limit unnecessary or abusive credential requests, and ensure that a verifier 's access is restricted to the specific credential attributes it registered for. user agents 's access is restricted to the specific credential attributes it registered for.

Checking verifier authorization is usually handled by the digital wallet, but user agents could find the presence of such a scheme helpful in preventing API abuse and designing a well-informed user permission experience.

Issue 281 Issue 281 : User agents that only support authorized verifiers (for government credentials) privacy-tracker
user agents

Should we require protocols to include provisions that allow user agents to understand verifier authorization?

11.3.1.7 11.3.1.7 Encrypting credential responses

To prevent exposure of user information to other parties in "transit", for example browser extensions loaded on verifier pages, and to encourage secure storage of user credentials by the verifier , protocols are required to support and mandate encrypted responses in a credential exchange.

Related to Related to #49 and several other discussions we've had: do we want to say that the response must always be encrypted (and if so, by which algorithms), or are we OK leaving that as optional? and several other discussions we've had: do we want to say that the response must always be encrypted (and if so, by which algorithms), or are we OK leaving that as optional?

11.4 11.4 Unnecessary Requests for Credentials

Intentional abuse of the API to learn sensitive information about the user for the purpose of fraud, tracking, or sale of the data. For example, a site could trick a user into sharing their passport information through misleading content. This can lead to identity theft and financial loss, and severe loss of control and/or leakage of personal information. Unnecessary requests for credentials without the explicit intent of user harm, such as an online store requesting users to sign up with their driver's license instead of generic email & passkey or federated credentials. This can lead to

Unnecessary credential requests are a key privacy risk to the entire digital credentials ecosystem. They could manifest in different ways and from different motivations:

One challenge here is determining what constitutes "valid" purposes and which requests are therefore "unnecessary", and requires participation from all parties involved in the credential exchange.

For a more detailed exploration of how to determine and address unnecessary usage, it makes sense to consider government-issued credentials and other credentials separately, as they potentially differ in the sensitivity of their data and the potential harms from misuse as well as legal & regulatory considerations.

A key component of risk mitigation and ensuring user control that applies to both types of credentials is the user agent 's ability to inspect the credential request metadata and make decisions or UI presentation based on it. The DC API ensures this user agent access to the presentation through requirements placed on protocols to transmit requests unencrypted and to include relevant information.

11.4.1 11.4.1 Government-issued credentials

Government-issued digital credentials

Government-issued digital credentials include travel documents, personal licenses, proof of welfare and public health programs, vehicle registrations, and other documents issued by government authorities, or other documents representing this information. These documents are highly sensitive, as they can contain permanent, irrevocable, unique identifiers that are central to a person's individual identity and ability to interact with vital public services.

11.4.1.1 11.4.1.1 Risk of theft and leakage of government credentials

The high value of these credentials to users and attackers means there is a significant risk of theft, and significant potential harm from leakage to unauthorized third parties. This includes the request of government identity for the purpose of tracking and personalization.

11.4.1.2 11.4.1.2 Risk of proliferation of requests for government credentials
Jevon's Paradox user agent user agents Increased risk of information leakage, and ultimately a less trusted user experience on the Web. When a large number of services access and store government-issued credentials in an insecure manner (i.e. not maintaining encryption or failing to safeguard private keys), the chance of data leaks and unauthorized access increases as well. Even seemingly non-identifying information like birthdates and postal codes, when combined, can statistically identify an individual. Prompt fatigue and a loss in trust by users when they are prompted by a large number of websites to share personal information. Increased potential for

A major concern with increased availability of government credentials online is Jevon's Paradox , i.e., the chance of increasing demand for credentials through lower friction of access. This effect is not inherently caused by the Digital Credentials API, but rather the overall increasing adoption of digital credentials across the ecosystem, which, however, would likely see additional momentum from user agent implementation of the Digital Credentials API. As such, the effect needs to be considered by user agents implementing the API, as it might result in harmful outcomes for users:

  • Increased risk of information leakage, and ultimately a less trusted user experience on the Web. When a large number of services access and store government-issued credentials in an insecure manner (i.e. not maintaining encryption or failing to safeguard private keys), the chance of data leaks and unauthorized access increases as well. Even seemingly non-identifying information like birthdates and postal codes, when combined, can statistically identify an individual.
  • Prompt fatigue and a loss in trust by users when they are prompted by a large number of websites to share personal information.
  • Increased potential for surveillance and restrictions on pseudonymous use of online services. Collusion between verifiers and issuers Exclusion and discrimination , or other parties, might result in the ability to closely monitor a user's activity on the Web and take adverse action against this individual. Even when no action is taken, the possibility of surveillance alone can cause anxiety, discomfort, and behavioral changes such as inhibition and self-censorship, impacting individual autonomy and freedom of expression.
  • Exclusion and discrimination of individuals who cannot, or do not want to, provide these credentials, prohibiting them from participation in services that would previously not require government-issued credentials, such as forums and social media platforms on the Web.
11.4.1.3 11.4.1.3 Mitigating unnecessary requests for government credentials

The outlined risks of government-issued digital credentials present a challenge that cannot be solved by a single participant in the ecosystem, and will require a broader policy discussion within individual sovereign nations about the risks and benefits of accessing online services through real-world credentials.

It is desirable that a government that issues digital credentials also enact laws and regulations that clearly define how and for what purposes those credentials are able to be used. All parties involved in the exchange, whether they are legally obliged to do so or not, are advised to support any government verifier EUDI access and registration certificates user agents Only supporting protocols that enable selective disclosure and other techniques of data minimization can reduce the impact and likelihood of information leakage, and provide better context to users in permission and consent flows. Support for protocols that allow unlinkability mechanisms such as Zero-Knowledge Proofs can prevent authentication schemes, if they exist. The support for (and integration of) verifier authentication schemes such as EUDI access and registration certificates -based surveillance and potential discrimination, by hiding the can mitigate risks of proliferation of unnecessary credential requests. However, the presence of such schemes is not guaranteed, which significantly increases the risk in a credential exchange.

There are other practical steps that user agents implementing the Digital Credentials API can take to reduce risk, increase user understanding, and prevent certain types of harm:

It is further critical that user agents design a permission experience that accounts for the lack of these mitigations, e.g., the exchange of personal information from government credentials without any verifier authentication scheme. It is recommended that a higher level of friction and clear user messaging that highlights the involved risk be applied to these types of exchanges.

11.4.2 11.4.2 Non-government-issued credentials

Non-government-issued credentials include all other digital documents, certificates, and attestations that are not government-issued and don't represent government-issued documents. This could include proof of employment, (non-government) education credentials, or cinema tickets. Notably, their exchange is likely less restricted by laws and regulations. While these documents often don't exhibit the same risks as government-issued credentials, they could also contain identifiable or sensitive information.

11.4.2.1 11.4.2.1 Risk of theft and leakage of non-government credentials

The impact and viability of credential theft and leakage of non-government credentials is largely based on the content of each individual credential type. In general, it could lead to loss of control and exposure of sensitive private information, as well as impersonation and data theft, which can increase the likelihood of further attacks on the affected individual.

11.4.2.2 11.4.2.2 Risk of proliferation of requests for non-government credentials

The flexibility and lack of regulation of non-government credentials carries potential for abuse for the purpose of cross-site tracking and linking identities through long-lived identifiers, such as email address or phone number. verifiers participating in a tracking scheme based on digital credentials could create user incentives to accept sharing identifier credentials across many sites ("loyalty cards" for the Web), without fully understanding the implications on their privacy.

Even users unwilling to share their information in such a scheme could be affected by prompt fatigue and potentially risk exclusion from using these services.

11.4.2.3 11.4.2.3 Mitigating unnecessary requests for non-government credentials
user agent user agent User agents user agent different user agents

For non-government-issued credentials, it is recommended that the user agent understand the requested credential format and its privacy attributes, and build a risk framework that informs the context that is shown to the user, as well as the amount of friction that is appropriate for each credential type. Protocols and formats involved in the exchange of these credentials are generally expected to support features such as selective disclosure and unlinkability, but these features might not always be appropriate or necessary in the exchange of information, especially when it concerns low-risk credentials such as cinema tickets.

A user agent that recognizes the type of credential being requested is encouraged to customize its permission experience to best suit the requested credential and help users understand the consequences of sharing it.

User agents cannot be expected to understand all credential requests. A user agent that does not recognize the type of credential being requested is advised to significantly increase user friction in their permission experience, and very clearly communicate the risks of sharing unknown credentials with websites to the user. Note that this could require integration between different user agents to apply appropriate levels of friction and transparency. For example, a browser might delegate knowledge about credential requests to the operating system, which might require digital wallets to register known credential types and reject an exchange request for an unknown credential type.

Issue 100 Issue 100 : Consider applying the robustness principle with regard to user agent request validation discussion privacy-considerations
user agent

The need to provide users with appropriate transparency conflicts with the desire to enable the ecosystem to develop new credential formats without explicit user agent buy-in.

11.4.2.4 11.4.2.4 Reporting abuse

Consider an interoperable abuse reporting system for verifiers making unnecessary and abusive requests.

11.5 11.5 Fingerprinting and Data Leakage

11.5.1 11.5.1 Browser fingerprinting

While the API ensures that no user data is ever shared without a permission prompt (see 11.6 User Permission and Transparency 11.6 User Permission and Transparency ), the longevity and uniqueness of real-world identifiers that are likely to be returned by the Digital Credentials API make it a potential target for trackers and fingerprinters. ), the longevity and uniqueness of real-world identifiers that are likely to be returned by the Digital Credentials API make it a potential target for trackers and fingerprinters.

Even with selective disclosure, attackers might combine data from a digital credential (such as the user's age, or the credential issuer , timestamps, see 11.5.2 Leaking incidental data with credential presentations 11.5.2 Leaking incidental data with credential presentations ) to reidentify and/or fingerprint users. ) to reidentify and/or fingerprint users.

This attack might be harder for third-party attackers (such as scripts embedded on the verifier 's pages but not actively collaborating with them for the purpose of tracking) because response encryption is mandatory and responses should be decrypted on the 's pages but not actively collaborating with them for the purpose of tracking) because response encryption is mandatory and responses should be decrypted on the verifier 's server. The 's server. The verifier could thus ensure not to reflect back decrypted information to client-side JavaScript. Not all verifiers will choose to do so, however.

11.5.2 11.5.2 Leaking incidental data with credential presentations

To ensure authenticity of a credential, its presentation to verifiers generally includes more information than the content the verifier is requesting access to. It will usually contain at least a signature of the issuer user agents and the digital wallet, and potentially other metadata.

This additional information could be used to reidentify and fingerprint users, which is especially relevant when an otherwise unlinkable presentation is made.

While the Digital Credentials API does not control the content of a credential response, user agents can help protect users against this type of tracking through clearly highlighting which information likely gets shared with the verifier beyond what was requested, and, more broadly, by identifying and blocking fingerprinting through the API by verifiers .

11.5.3 11.5.3 Revealing device properties through protocol availability

The Digital Credentials API exposes information about which presentation and issuance user agent protocols are supported by the user agent through userAgentAllowsProtocol () user agent . It mitigates browser fingerprinting and revealing information about the user's device configuration by not customizing its response based on, for example, which digital wallet applications are installed on a user's device. The returned information is thus, at best, equivalent to a user agent version.

11.5.4 11.5.4 Avoiding leaks of credential availability

user permission flow

The Digital Credentials API does not enable sites to learn whether a credential is available without first going through a user permission flow . Revealing the presence of credentials would be a risk to user privacy, as the presence of a credential is personal information that the user might not have preferred to share with the site, and, in combination with other signals, could be used to identify the user without their permission. It is also a risk to free expression, as websites might increasingly start to demand the presentation of these credentials from the user in order to access services, excluding individuals who are unwilling to present credentials.

11.6 11.6 User Permission and Transparency

Issue : Work in progress : Work in progress

user agent The origin of the

The Digital Credentials API enables the sharing of highly personal, sensitive, and at-risk user information with websites via credentials, potentially granting the ability to track users online and offline, through permanent, unique, irrevocable, cross-context identifiers. It also reveals parts of the user's browsing activity as well as their intent to identify to specific websites and/or digital wallets. One crucial responsibility of the user agent in a credential request is to gather permission from the user to proceed with the exchange of information.

Important context details that are needed for a user to make an informed decision about proceeding with a credential exchange include the following:

It is advised that user agents in their implementation ensure that the details listed are fully disclosed to the user before an exchange of any user-related information occurs.

Issue 252 Issue 252 : Should we normatively define elements of a permission prompt? privacy-considerations

Should these be normative in the spec?

Issue 44 Issue 44 : API requests should provide the site with what they need to explain why and how requested credential information will be used enhancement dc2-proposal privacy-tracker

Should the API be designed so the site can provide in-context explanations?

11.6.1 11.6.1 Handling multiple credential requests

Issue 286 Issue 286 : Privacy Considerations for multiple presentation requests (and responses) privacy-tracker privacy-considerations

We need to describe concerns, tradeoffs and possible mitigations of handling multiple requests and responses for credential presentation.

11.6.2 11.6.2 Integrating Multiple User Agents

Depending on the technical architecture of a user's system, it is likely that the definition of a " user agent

Depending on the technical architecture of a user's system, it is likely that the definition of a " user agent " will include multiple cooperating layers of the software stack, such as a browser and the operating system. The greatest priority for these layers has to be a safe and well-informed user permission experience. As such, integration can be vital for user safety. Some layers may hold information that is inaccessible by other layers, such as the availability of a user's credentials. Overprompting or prompting without sufficient context could lead to (exploitable) confusion and prompt blindness. user agents " will include multiple cooperating layers of the software stack, such as a browser and the operating system. The greatest priority for these layers has to be a safe and well-informed user permission experience. As such, integration can be vital for user safety. Some layers may hold information that is inaccessible by other layers, such as the availability of a user's credentials. Overprompting or prompting without sufficient context could lead to (exploitable) confusion and prompt blindness.

For this reason, user agents prompting for permission are encouraged to integrate software layers for an ideal user experience, if they consider it safe to do so. This could happen, for example, if a browser trusts the API contract of an operating system to show an appropriate prompt, and thus does not show a prompt itself.

11.6.3 11.6.3 Permission Prior to Wallet Selection

user agent

As part of the user permission flow, the user agent needs to ensure that users retain the power to choose whether to forward a credential request to a digital wallet, and which digital wallet to select. This is due to the information disclosure that happens as part of the request, and the ability of digital wallets to retain or share this information at the time of the request.

12. 12. Accessibility Considerations

credential choosers

Implementers need to consider accessibility when designing credential choosers specifically for this API. The content of modal dialogs presented during issuance or presentation , which can include text, QR codes, and other visual media, SHOULD be labelled and exposed to assistive technologies.

Interactive elements, particularly those that allow the user to continue or abort issuance or presentation requests, MUST be operable in a device-independent manner.

A. A. Index

A.1 Terms defined by this specification A.1 Terms defined by this specification

abort algorithm

A.2 Terms defined by reference A.2 Terms defined by reference

[

B. IDL Index

WebIDLpartial dictionary CredentialRequestOptions {
  DigitalCredentialRequestOptions digital;
};
dictionary DigitalCredentialRequestOptions {
  required sequence<DigitalCredentialGetRequest> requests;
};
dictionary DigitalCredentialGetRequest {
  required DOMString protocol;
  required object data;
};
partial dictionary CredentialCreationOptions {
  DigitalCredentialCreationOptions digital;
};
dictionary DigitalCredentialCreationOptions {
  required sequence<DigitalCredentialCreateRequest> requests;
};
dictionary DigitalCredentialCreateRequest {
  required DOMString protocol;
  required object data;
};
typedef (DigitalCredentialPresentationProtocol or DigitalCredentialIssuanceProtocol) DigitalCredentialProtocol;
[Exposed=Window, SecureContext]
interface 

interface DigitalCredential : Credential {

  [Default] object toJSON();
  readonly attribute DigitalCredentialProtocol protocol;
  [SameObject] readonly attribute object data;
  static

  static boolean userAgentAllowsProtocol(DOMString protocol);

};
enum DigitalCredentialPresentationProtocol {
  "openid4vp-v1-unsigned",
  "openid4vp-v1-signed",
  "openid4vp-v1-multisigned",
  "org-iso-mdoc"
};
enum DigitalCredentialIssuanceProtocol {
  "openid4vci-v1",
};

C. C. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY , MUST MUST NOT , MUST NOT , RECOMMENDED , and SHOULD BCP 14 [ in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here. ] when, and only when, they appear in all capitals, as shown here.

D. D. Acknowledgements

Some of the Editors would like to thank the following individuals for their feedback and contributions to this specification: Christian Bormann (SPRIND), John Bradley (Yubico), Rick Byers (Google), Brian Campbell (Ping Identity), Lee Campbell (Google), Nick Doty (CDT), Heather Flanagan (Spherical Cow Consulting), Ryan Galluzzo (NIST), Joseph Heenan (Authlete), Dominique Hazael-Massieux (

Some of the Editors would like to thank the following individuals for their feedback and contributions to this specification: Christian Bormann (SPRIND), John Bradley (Yubico), Rick Byers (Google), Brian Campbell (Ping Identity), Lee Campbell (Google), Nick Doty (CDT), Heather Flanagan (Spherical Cow Consulting), Ryan Galluzzo (NIST), Joseph Heenan (Authlete), Dominique Hazael-Massieux ( W3C ), Bjorn Hjelm (Yubico), Johann Hofmann (Google), Mike Jones (Self-Issued Consulting), Tobias Looker (MATTR), Matthew Miller (Cisco), Theresa O'Connor (Apple Inc.), Simone Onofri ( ), Bjorn Hjelm (Yubico), Johann Hofmann (Google), Mike Jones (Self-Issued Consulting), Tobias Looker (MATTR), Matthew Miller (Cisco), Theresa O'Connor (Apple Inc.), Simone Onofri ( W3C ), Helen Qin (Google), Wendy Seltzer (Invited Expert), Manu Sporny (Digital Bazaar), Orie Steele (Transmute), Ted Thibodeau Jr (OpenLink Software), David Waite (Ping Identity), and Kristina Yasuda (SPRIND). ), Helen Qin (Google), Wendy Seltzer (Invited Expert), Manu Sporny (Digital Bazaar), Orie Steele (Transmute), Ted Thibodeau Jr (OpenLink Software), David Waite (Ping Identity), and Kristina Yasuda (SPRIND).

E. E. References

E.1 Normative references E.1 Normative references

[credential-management]
Credential Management Level 1 Credential Management Level 1 . Nina Satragno; Marcos Caceres. W3C. 13 February 2026. W3C Working Draft. URL: https://www.w3.org/TR/credential-management-1/
[dom]
DOM Standard DOM Standard . Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[html]
HTML Standard HTML Standard . Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[infra]
Infra Standard Infra Standard . Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[ISO18013-7]
ISO/IEC 18013-7:2025 ISO-compliant driving licence, Part 7: Mobile driving licence (mDL) add-on functions ISO/IEC 18013-7:2025 ISO-compliant driving licence, Part 7: Mobile driving licence (mDL) add-on functions . ISO/IEC JTC 1/SC 17. International Organization for Standardization. May 2025. URL: https://www.iso.org/standard/91154.html
[OPENID4VCI]
OpenID for Verifiable Credential Issuance 1.0 OpenID for Verifiable Credential Issuance 1.0 . Torsten Lodderstedt; Kristina Yasuda; Tobias Looker; Paul Bastian. OpenID Foundation. 16 September 2025. Final. URL: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
[OPENID4VP]
OpenID for Verifiable Presentations 1.0 OpenID for Verifiable Presentations 1.0 . Oliver Terbu; Torsten Lodderstedt; Kristina Yasuda; Daniel Fett; Joseph Heenan. OpenID Foundation. 9 July 2025. Final. URL: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
[permissions]
Permissions . Marcos Caceres; Mike Taylor. W3C. 6 October 2025. W3C Working Draft. URL: https://www.w3.org/TR/permissions/
[permissions-policy]
Permissions Policy Permissions Policy . Ian Clelland. W3C. 6 October 2025. W3C Working Draft. URL: https://www.w3.org/TR/permissions-policy-1/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels Key words for use in RFCs to Indicate Requirement Levels . S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words . B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[vc-data-model]
Verifiable Credentials Data Model v2.0 Verifiable Credentials Data Model v2.0 . Ivan Herman; Michael Jones; Manu Sporny; Ted Thibodeau Jr; Gabe Cohen. W3C. 15 May 2025. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/
[WEBIDL]
Web IDL Standard Web IDL Standard . Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/

E.2 Informative references E.2 Informative references

[credential-considerations]
User considerations for credentials on the Web User considerations for credentials on the Web . Nick Doty; Rick Byers. W3C. 2025-03-26. URL: https://github.com/w3c/credential-considerations/blob/main/credentials-considerations.md
[custom-schemes]
Concerns with custom schemes for identity presentment Concerns with custom schemes for identity presentment . Rick Byers. W3C. 2024-05-01. URL: https://github.com/w3c-fedid/digital-credentials/blob/main/custom-schemes.md
[design-principles]
Web Platform Design Principles Web Platform Design Principles . Martin Thomson; Jeffrey Yasskin. W3C. 27 January 2026. W3C Working Group Note. URL: https://www.w3.org/TR/design-principles/
[identity-web-impact]
Identity & the Web Identity & the Web . Simone Onofri. W3C. 2025-02-25. URL: https://www.w3.org/reports/identity-web-impact
[presenting-credentials-on-the-web]
Presenting Credentials on the Web Presenting Credentials on the Web . Simone Onofri. URL: https://docs.google.com/document/d/1Ppaz_EnhzHqPOz5UusRJvbSunh-RXPWgJ3Np_TM2EE0/
[privacy-principles]
Privacy Principles Privacy Principles . Robin Berjon; Jeffrey Yasskin. W3C. 15 May 2025. STMT. URL: https://www.w3.org/TR/privacy-principles/
[rfc6973]
Privacy Considerations for Internet Protocols Privacy Considerations for Internet Protocols . A. Cooper; H. Tschofenig; B. Aboba; J. Peterson; J. Morris; M. Hansen; R. Smith. IETF. July 2013. Informational. URL: https://www.rfc-editor.org/rfc/rfc6973
[threat-model-decentralized-identities]
Threat Model for Decentralized Identities Threat Model for Decentralized Identities . Simone Onofri. W3C. 2025-05-28. URL: https://github.com/w3c-cg/threat-modeling/blob/main/models/decentralized-identities.md