Repository navigation
Question for adding a protocol to the Digital Credentials spec
Questions we ask when considering adding a protocol to the spec:
- Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
- How do the features in your specification deal with sensitive information?
- Does data exposed by your specification carry related but distinct information that may not be obvious to users?
- Does this specification allow an origin to send data to the underlying platform?
- Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
- Does the protocol define the request and the response as objects the API can carry?
- Does the protocol bind the response to the origin the browser supplies?
- Does the protocol define validation rules for the request and the response? For the wallet, and for the browser?
- Does the protocol encrypt the response?
- Can the wallet identify the verifier beyond its origin?
- Can a presentation happen without contacting the issuer?
- How does the protocol handle revocation, and can a verifier check revocation without telling the issuer?
- Which body standardizes the protocol, and what is its status?
- How can implementers and reviewers read the specification?
- Which privacy and security reviews has the protocol had?
- Which browsers have committed to implement the protocol?
- Did the group record consensus to include the protocol?
ISO/IEC TS 18013-7:2025, Annex C, together with ISO/IEC 18013-5:2021.
Identifier in the Digital Credentials API:
org-iso-mdoc
Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
Yes, ISO mdoc has a way to ask for only the claims the verifier needs. The verifier requests data elements one by one. ISO/IEC 18013-5 tells verifiers to request only the data they need. See ISO/IEC 18013-5, Annex E, the part called "Collection limitation".
Yes, ISO mdoc gives the wallet what the wallet needs to ask the user for informed consent. ISO/IEC 18013-5 lets the holder consent before or during the exchange. See ISO/IEC 18013-5, Annex E, the part called "mDL holder consent", with the sub-parts "Pre-consent" and "Transaction-time consent". Each data element carries an intent-to-retain flag. See ISO/IEC 18013-5, Annex E.
Does data exposed by your specification carry related but distinct information that may not be obvious to users?
ISO mdoc has a way to prevent linking across verifiers. The protocol does not always prevent linking. The method works if the issuer gives the wallet many copies of the credential. The wallet uses each copy only once. See ISO/IEC 18013-5, Annex E, the part called "Rotation of public keys". ISO/IEC 18013-5 lists colluding verifiers and passive observers as threats. The standard does not list an issuer and a verifier working together as a threat. See ISO/IEC 18013-5, Annex E, the part called "Anonymity and unlinkability", sub-part "Applicability", and the part called "Tracking mDL usage". See issue #279 (Linkability and issuer involvement as a protocol requirement).
Yes. The website sends the request through the API, and the browser can read the request. The request uses CBOR. CBOR is a binary data format. The request is not encrypted. See ISO/IEC TS 18013-7:2025, Annex C ("Digital credentials API retrieval"), the part called "Request".
ISO/IEC 18013-7 has a short clause on protocol considerations. The clause covers custom URI schemes. A URI is a web address. The clause covers a relay attack. The clause refers to the privacy recommendations in ISO/IEC 18013-5, Annex E. See ISO/IEC TS 18013-7:2025, the clause called "Protocol considerations".
Yes, ISO mdoc defines the request and the response as objects the API can carry. Annex C defines both objects. See ISO/IEC TS 18013-7:2025, Annex C, the parts called "Request" and "Response".
Yes, ISO mdoc always binds the response to the origin. The browser supplies the origin. The origin goes into the session transcript. The wallet stops if the wallet gets no origin. See ISO/IEC TS 18013-7:2025, Annex C, the part called "Session transcript".
Does the protocol define validation rules for the request and the response? For the wallet, and for the browser?
ISO mdoc defines validation rules for the wallet. The protocol defines no rules for the browser. See ISO/IEC TS 18013-7:2025, Annex C, the parts called "Request", "Response" and "Session transcript". See PR #520 (Specify protocol validation + enforce encryption).
Yes, ISO mdoc always encrypts the response. The wallet encrypts every response with HPKE. HPKE, short for Hybrid Public Key Encryption, is a standard way to lock data. RFC 9180 defines HPKE. See ISO/IEC TS 18013-7:2025, Annex C, the part called "Encryption".
ISO mdoc has a way to identify the verifier beyond the origin. The protocol does not always identify the verifier. The method is reader authentication. ISO/IEC 18013-7 makes reader authentication optional. See ISO/IEC TS 18013-7:2025, the clause called "Security mechanisms support requirements". A wallet may require reader authentication before the wallet releases data. See ISO/IEC TS 18013-7:2025, the clause called "mDL data model".
ISO mdoc has a way to make a presentation without contacting the issuer. A presentation may still contact the issuer. Annex C uses device retrieval. Device retrieval needs no issuer contact. See ISO/IEC TS 18013-7:2025, Annex C, the part called "General". A verifier can also ask for server retrieval details as ordinary data elements. See ISO/IEC 18013-5, the clause called "Server retrieval information". ISO/IEC 18013-7 adds no requirements for server retrieval. See ISO/IEC TS 18013-7:2025, the clause called "Device retrieval data transmission technology". Server retrieval contacts the issuer. ISO/IEC 18013-5 recommends that the issuer not use the call to track usage. See ISO/IEC 18013-5, Annex E, the part called "Tracking mDL usage". PR #520 (Specify protocol validation + enforce encryption) would make the browser refuse a request for server retrieval details.
How does the protocol handle revocation, and can a verifier check revocation without telling the issuer?
ISO mdoc leaves revocation out of scope. Freshness comes from validity periods. See ISO/IEC TS 18013-7:2025, the clause called "Security architecture". ISO/IEC 18013-5 recommends that any revocation method beyond validity periods keep past presentations unlinkable. See ISO/IEC 18013-5, Annex E, the part called "Anonymity and unlinkability", sub-part "Applicability".
ISO/IEC JTC 1/SC 17 standardizes ISO mdoc. The status is Technical Specification, second edition, 2025. See the title page and foreword of ISO/IEC TS 18013-7:2025 ("Second edition", "2025-05", "Joint Technical Committee ISO/IEC JTC 1", "Subcommittee SC 17").
ISO sells the specification. DIN Media offers a sponsored viewer. The viewer is read-only. "Access is read-only. Printing, copying, and downloading are not possible and are expressly prohibited." issue #578 (Annex C being optional). DIN Media reserves the right to stop the viewer at any time. "DIN Media reserves the right to discontinue the Viewer and the access to the Sponsored Standards at any time" issue #578 (Annex C being optional). A formal objection said the spec should not normatively reference a paid specification. To normatively reference a document means the spec depends on that document. "a normative reference to a fee-gated specification" the W3C Council report. The W3C Council overruled the objection. "to overrule the Formal Objection, allowing the normative reference to [ISO18013-7] to stand" the W3C Council report. The Council report is dated 19 June 2026. the W3C Council report.
No W3C Privacy Working Group or W3C Security Interest Group has reviewed ISO mdoc. On 15 October 2026 we searched the W3C Privacy request list and the W3C Security request list for mdoc and for mobile driving licence. Neither list had a request to review ISO mdoc. (A search for another topic on the same lists did return results, so the search works.) The FedID Working Group's own review of the supported protocols is still open. See PR #543 (Privacy Considerations: ecosystem note and per-protocol privacy review).
Safari and Chrome ship the API, and Firefox does not. MDN's browser compatibility data for DigitalCredential lists the API from Safari 26 and Chrome 141, and lists no support in Firefox.
The spec requires every browser that supports the API to support ISO mdoc. The spec says: "A user agent MUST support all the presentation protocols listed in the table of supported presentation and issuance protocols." See Protocols in the Digital Credentials API specification. PR #454 (Require support for all presentation protocols) added that rule, and the group merged it on 19 August 2026.
WebKit lists ISO mdoc as "org-iso-mdoc" in its source file DigitalCredentialPresentationProtocol.idl. WebKit tracks the work in WebKit bug 268516 ([Meta] Implement Digital Credentials API). WebKit's standards position is support: see WebKit's standards position on the Digital Credentials API. Mozilla's standards position, set on 15 May 2024, is negative: see Mozilla's standards position on Digital Credentials.
Yes. PR #401 (Change from Registry to Protocols) added the supported protocols to the spec. Its description says: "Adds a new Supported Protocols section, with a table for details about each protocol". The group merged the pull request on 28 January 2026, and the group merges nothing without consensus.
OpenID for Verifiable Presentations 1.0 and its appendix for the Digital Credentials API.
Identifiers in the Digital Credentials API:
openid4vp-v1-unsignedopenid4vp-v1-signedopenid4vp-v1-multisigned
Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
Yes, OpenID4VP has a way for the verifier to ask for only the claims the verifier needs. "allowing the Wallet to disclose only the claims that are relevant to the Verifier's request" Selective Disclosure in OpenID4VP. The verifier uses DCQL, a query language. The way works if the credential format supports selective disclosure. "Some Credential formats support selective disclosure" Selective Disclosure in OpenID4VP.
Yes, OpenID4VP gives the wallet what the wallet needs to ask the user for informed consent. Wallets should get informed consent. "Wallets SHOULD obtain explicit, informed consent from the End-User before releasing any Verifiable Credential or Presentation to a Verifier" User Consent in OpenID4VP. Requests can carry a purpose. "the purpose is shown to the End-User before or within the presentation request that is sent to the Wallet" Purpose Legitimacy in OpenID4VP. Requests can also carry verifier information. "Verifier Info parameter allows the Verifier to provide additional context or metadata as part of the Authorization Request" Verifier Info in OpenID4VP.
Does data exposed by your specification carry related but distinct information that may not be obvious to users?
OpenID4VP has a way to prevent linking across verifiers, but the protocol does not always prevent linking. The way works if the issuer gives the wallet many copies of the credential and the wallet uses each copy only once. "a Wallet can use an issued Credential instance only once in a Presentation to a specific Verifier, before discarding the Credential" Verifier-to-Verifier Unlinkable Presentations in OpenID4VP. "One technique mentioned to achieve some important unlinkability properties is the use of batch issuance" Verifier-to-Verifier Unlinkable Presentations in OpenID4VP. OpenID4VP does not address linking between a verifier and the issuer. The unlinkability section of OpenID4VP is only about linking between verifiers. We searched the whole OpenID4VP specification and found no text about an issuer and a verifier linking presentations together. (We searched for the words collude and collusion and found none.) Verifier-to-Verifier Unlinkable Presentations in OpenID4VP. See issue #279 (Linkability and issuer involvement as a protocol requirement).
Yes. The website sends the request through the API, and the browser can read the request. "Depending on the mechanism used to identify and authenticate the Verifier, the request can be signed or unsigned." Signed and Unsigned Requests in the Digital Credentials API appendix of OpenID4VP. The API appendix defines a plain JSON request. "The Verifier MAY send all the OpenID4VP request parameters as members in the request member passed to the API." Unsigned Request in the Digital Credentials API appendix of OpenID4VP. The appendix also defines a signed JWS request, which uses a JSON Web Signature. "Verifiers SHOULD format signed Requests using JWS Compact Serialization but MAY use JWS JSON Serialization" Signed Request in the Digital Credentials API appendix of OpenID4VP. The appendix does not mention encrypting the request. OpenID4VP describes an encrypted request using a web address or URI. "a signed, optionally encrypted, request object" Request URI Method post in OpenID4VP. The API does not support the URI method. The list of request parameters the API supports does not include request_uri. The list names client_id, response_type, response_mode, nonce, client_metadata, request, transaction_data, dcql_query and verifier_info. The Digital Credentials API appendix never says the request can be encrypted. The only encrypted request is the one in the Request URI part. the Request part of the Digital Credentials API appendix of OpenID4VP.
Yes, the specification has both a Security Considerations section and a Privacy Considerations section. The appendix for the Digital Credentials API adds a Security Considerations section. "The following security considerations from OpenID4VP apply" Security Considerations in the Digital Credentials API appendix of OpenID4VP. The appendix also adds a Privacy Considerations section. "The following privacy considerations from OpenID4VP apply" Privacy Considerations in the Digital Credentials API appendix of OpenID4VP.
Yes, OpenID4VP defines the request and the response as objects the API can carry. The protocol defines a request object. "The Verifier MAY send a request, as defined in Section 5, to the DC API." the Request part of the Digital Credentials API appendix of OpenID4VP. The protocol defines a response object. "the response is an instance of the DigitalCredential interface" the Response part of the Digital Credentials API appendix of OpenID4VP.
Yes, OpenID4VP always binds the response to the origin the browser supplies. "achieved by binding the response to the Origin it was received from" the Response part of the Digital Credentials API appendix of OpenID4VP. The audience for the response is the origin. "The audience for the response (for example, the aud value in a Key Binding JWT) MUST be the Origin" the Response part of the Digital Credentials API appendix of OpenID4VP.
Does the protocol define validation rules for the request and the response? For the wallet, and for the browser?
OpenID4VP defines validation rules for the wallet, but the protocol defines none for the browser. The wallet must check the origin. "The Wallet MUST compare values in this parameter to the Origin to detect replay of the request from a malicious Verifier." the Request part of the Digital Credentials API appendix of OpenID4VP. The wallet must ignore unknown parameters. "The Wallet MUST ignore any unrecognized parameters." the Request part of the Digital Credentials API appendix of OpenID4VP. The Digital Credentials API appendix mentions the browser once, in the words "the Web PKI utilized by the browser", and gives the browser no rules. Signed Request in the Digital Credentials API appendix of OpenID4VP. See PR #520 (Specify protocol validation + enforce encryption).
OpenID4VP has a way to encrypt the response, but the protocol does not always do so. "Encrypting the Authorization Response can, for example, prevent personal data in the Authorization Response from leaking" Encrypted Responses in OpenID4VP. The verifier chooses an encrypted or unencrypted response mode. "The value of the response_mode parameter MUST be dc_api when the response is not encrypted and dc_api.jwt when the response is encrypted" the Request part of the Digital Credentials API appendix of OpenID4VP. See issue #519 (Spec doesn’t enforce encrypted response requirement).
Signed and multisigned OpenID4VP requests always identify the verifier through a trust framework. "The signed request allows the Wallet to authenticate the Verifier using one or more trust framework(s)" Signed Request in the Digital Credentials API appendix of OpenID4VP. The wallet checks more than the origin. "the Wallet can no longer rely only on the web origin of the Verifier" Signed Request in the Digital Credentials API appendix of OpenID4VP. Unsigned requests identify the verifier by origin only. "The client_id parameter MUST be omitted in unsigned requests" the Request part of the Digital Credentials API appendix of OpenID4VP.
OpenID4VP has a way to make a presentation without contacting the issuer, but a presentation may still contact the issuer. A verifier policy can include revocation checks. "Perform the checks required by the Verifier's policy based on the set of trust requirements such as trust frameworks it belongs to (e.g., revocation checks)" VP Token Validation in OpenID4VP. Trust checks that need online lookups can leak information. "Mechanisms that require online resolution can leak information that could be used to profile the usage of the Credentials." Establishing Trust in the Issuers in OpenID4VP.
How does the protocol handle revocation, and can a verifier check revocation without telling the issuer?
OpenID4VP defines no revocation mechanism. We searched the whole OpenID4VP specification for the word revocation. The main text uses the word once, as an example of a check in the VP Token Validation part: "(e.g., revocation checks)". The specification describes no way to check revocation. VP Token Validation in OpenID4VP.
The OpenID Foundation standardizes OpenID4VP. "Workgroup: OpenID Digital Credentials Protocols" the OpenID4VP specification. The status is Final, published 9 July 2025. "Status: Final" the OpenID4VP specification. "Published: 9 July 2025" the OpenID4VP specification.
OpenID4VP is free to read on the web. You can read the specification on the web for free. the OpenID4VP specification.
No W3C Privacy Working Group or W3C Security Interest Group has reviewed OpenID4VP. On 15 October 2026 we searched the W3C Privacy request list and the W3C Security request list for openid4vp. Neither list had a result. (A search for another topic on the same lists did return results, so the search works.) the W3C Privacy request list and the W3C Security request list. The FedID Working Group's own review of the supported protocols is still open. See PR #543 (Privacy Considerations: ecosystem note and per-protocol privacy review).
Safari and Chrome ship the API, and Firefox does not. MDN's browser compatibility data for DigitalCredential lists the API from Safari 26 and Chrome 141, and lists no support in Firefox.
The spec requires every browser that supports the API to support OpenID4VP. The spec says: "A user agent MUST support all the presentation protocols listed in the table of supported presentation and issuance protocols." See Protocols in the Digital Credentials API specification. PR #454 (Require support for all presentation protocols) added that rule, and the group merged it on 19 August 2026.
WebKit lists OpenID4VP as "openid4vp-v1-unsigned", "openid4vp-v1-signed" and "openid4vp-v1-multisigned" in its source file DigitalCredentialPresentationProtocol.idl. WebKit tracks the work in WebKit bug 268516 ([Meta] Implement Digital Credentials API). WebKit's standards position is support: see WebKit's standards position on the Digital Credentials API. Mozilla's standards position, set on 15 May 2024, is negative: see Mozilla's standards position on Digital Credentials.
Yes. PR #401 (Change from Registry to Protocols) added the supported protocols to the spec. Its description says: "Adds a new Supported Protocols section, with a table for details about each protocol". The group merged the pull request on 28 January 2026, and the group merges nothing without consensus.
meeting notes