Privacy Considerations: ecosystem note and per-protocol privacy review - #543
Privacy Considerations: ecosystem note and per-protocol privacy review#543marcoscaceres wants to merge 1 commit into
Conversation
Adds two non-normative subsections to the Privacy Considerations: an "Ecosystem privacy" note stating that whole-deployment privacy is out of scope, and a "Privacy review of the supported protocols" reviewing OpenID4VP, mdoc, and OpenID4VCI against the existing considerations. Descriptive only; normative requirements are tracked in #255. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adds two informative clarifications to the spec’s Privacy Considerations section: (1) a note that ecosystem-wide privacy properties of deployments are out of scope for this API spec, and (2) a descriptive, per-protocol privacy review for the currently listed supported protocols.
Changes:
- Add an “Ecosystem privacy” subsection to scope the section to the API interaction and user agent duties.
- Add a “Privacy review of the supported protocols” subsection describing privacy-relevant properties of each currently listed protocol (OpenID4VP variants, ISO mdoc path, OpenID4VCI).
| This section reviews how each [=digital credential/presentation | ||
| protocol=] listed in [[[#protocols]]] addresses the considerations | ||
| above, and notes where a property depends on deployment choices or is | ||
| left to the credential format. It is descriptive: it records the |
| OpenID for Verifiable Presentations | ||
| </h5> | ||
| <p> | ||
| [[OPENID4VP]] facilitates selective disclosure through its query |
There was a problem hiding this comment.
@marcoscaceres — Copilot is mistaken about how ReSpec works.
The double-square-bracket ([[ ]]) is seen in the final document as the cited shortname, with an href of that document's listing in the CITATIONS section within the final document.
The triple-square-bracket ([[[ ]]]) is seen in the final document as the title of the referenced spec, with an href of the referenced spec external to the final document.
Normative citations are [[!...]] or [[...]] (! or nothing preceding the shortname within the double-square-bracket). Informative citations are [[?...]] (? preceding the shortname within the double-square-bracket).
All that said, I would recommend some change, to wit, assuming non-normative reference was intended and remains desired, as seems likely given that this is a non-normative section —
| [[OPENID4VP]] facilitates selective disclosure through its query | |
| [[[?OPENID4VP]]] [[?OPENID4VP]] facilitates selective disclosure through its query |
If normative reference is desired, then change the ? immediately following each set of opening square-brackets to !.
| unlinkability as an inherent property: it addresses | ||
| verifier-to-verifier linkability only, and treats unlinkability as | ||
| achievable by presenting a single-use credential instance, with | ||
| batch issuance of such instances defined in [[OPENID4VCI]] rather |
There was a problem hiding this comment.
@marcoscaceres — As above, Copilot is mistaken about how ReSpec works.
The double-square-bracket ([[ ]]) is seen in the final document as the cited shortname, with an href of that document's listing in the CITATIONS section within the final document.
The triple-square-bracket ([[[ ]]]) is seen in the final document as the title of the referenced spec, with an href of the referenced spec external to the final document.
Normative citations are [[!...]] or [[...]] (! or nothing preceding the shortname within the double-square-bracket). Informative citations are [[?...]] (? preceding the shortname within the double-square-bracket).
All that said, I would recommend some change, to wit, assuming non-normative reference was intended and remains desired, as seems likely given that this is a non-normative section —
| batch issuance of such instances defined in [[OPENID4VCI]] rather | |
| batch issuance of such instances defined in [[[?OPENID4VCI]]] [[?OPENID4VCI]] rather |
If normative reference is desired, then change the ? immediately following each set of opening square-brackets to !.
| [=verifier=] requests individual data elements, and an mdoc need not | ||
| release an element merely because it is present, which supports data | ||
| minimization (for example, an age-over attestation can confirm a | ||
| threshold without revealing date of birth). As with [[OPENID4VP]], |
There was a problem hiding this comment.
As above.
| threshold without revealing date of birth). As with [[OPENID4VP]], | |
| threshold without revealing date of birth). As with [[[?OPENID4VP]]] [[?OPENID4VP]], |
| Digital Credentials API path defined in [[ISO18013-7]] Annex C, the | ||
| presentation is a direct exchange between the wallet and the | ||
| verifier with no issuer contact, and the response is encrypted to | ||
| the verifier, so a [=user agent=] cannot inspect it. Revocation is | ||
| out of scope for [[ISO18013-7]]; freshness relies on the validity |
There was a problem hiding this comment.
As above —
| Digital Credentials API path defined in [[ISO18013-7]] Annex C, the | |
| presentation is a direct exchange between the wallet and the | |
| verifier with no issuer contact, and the response is encrypted to | |
| the verifier, so a [=user agent=] cannot inspect it. Revocation is | |
| out of scope for [[ISO18013-7]]; freshness relies on the validity | |
| Digital Credentials API path defined in [[[?ISO18013-7]]] [[?ISO18013-7]] Annex C, the | |
| presentation is a direct exchange between the wallet and the | |
| verifier with no issuer contact, and the response is encrypted to | |
| the verifier, so a [=user agent=] cannot inspect it. Revocation is | |
| out of scope for [[[?ISO18013-7]]] [[?ISO18013-7]]; freshness relies on the validity |
| ISO/IEC mdoc ({{DigitalCredentialPresentationProtocol/"org-iso-mdoc"}}) | ||
| </h5> | ||
| <p> | ||
| The mdoc data model ([[ISO18013-5]]) is element-granular: a |
There was a problem hiding this comment.
As above —
| The mdoc data model ([[ISO18013-5]]) is element-granular: a | |
| The [[[?ISO18013-5]]] ([[?ISO18013-5]]) is element-granular: a |
| verifier with no issuer contact, and the response is encrypted to | ||
| the verifier, so a [=user agent=] cannot inspect it. Revocation is | ||
| out of scope for [[ISO18013-7]]; freshness relies on the validity | ||
| window of the signed object, and [[ISO18013-5]] cautions that |
There was a problem hiding this comment.
| window of the signed object, and [[ISO18013-5]] cautions that | |
| window of the signed object, and [[[?ISO18013-5]]] [[?ISO18013-5]] cautions that |
| OpenID for Verifiable Credential Issuance ({{DigitalCredentialIssuanceProtocol/"openid4vci-v1"}}) | ||
| </h5> | ||
| <p> | ||
| [[OPENID4VCI]] is an [=digital credential/issuance protocol=], so |
There was a problem hiding this comment.
| [[OPENID4VCI]] is an [=digital credential/issuance protocol=], so | |
| [[[?OPENID4VCI]]] [[?OPENID4VCI]] is an [=digital credential/issuance protocol=], so |
Closes #226
This adds two non-normative additions to the Privacy Considerations.
First, an "Ecosystem privacy" subsection clarifies that the privacy implications of a complete deployment that combines this API with particular presentation protocols, credential formats, issuance systems, and governance rules are out of scope for this specification, and that each deployment is encouraged to evaluate privacy across all of the specifications it uses and to consult their privacy considerations in addition to the considerations described here. This reflects the ecosystem-scope clarification discussed on the 2026-02-23 FedID call, based on text proposed by @gffletch in #226.
Second, a "Privacy review of the supported protocols" subsection reviews how each presentation and issuance protocol listed in the Protocols table addresses the considerations the section already sets out, and notes where a property depends on deployment choices or on the credential format rather than on the protocol itself. OpenID for Verifiable Presentations is reviewed across its unsigned, signed, and multi-signed request variants, which differ in verifier authentication strength rather than in presentation unlinkability. The mdoc review (ISO/IEC TS 18013-7 Annex C, building on ISO/IEC 18013-5) covers selective disclosure, the conditional nature of unlinkability, the origin binding the Digital Credentials API path adds, and the encrypted response. OpenID for Verifiable Credential Issuance is covered as an issuance protocol, with a note that its binding to the Digital Credentials API has not yet been published and that the review will be revisited once it is defined.
The review is descriptive: it records the current state of the referenced protocol specifications, not new conformance requirements. Concrete normative requirements are tracked separately in #255.
The following tasks have been completed:
Implementation commitment:
Documentation and checks
Preview | Diff