Skip to content

Commit 3eae550

Browse files
johannhofjohannhof
authored
Add initial privacy considerations section for protocol requirements (#260)
1 parent bd989f6 commit 3eae550

File tree

1 file changed

+184
-11
lines changed

1 file changed

+184
-11
lines changed

‎index.html

Lines changed: 184 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -647,15 +647,16 @@ <h3>
647647
structures.
648648
</li>
649649
<li>MUST have undergone privacy review by the W3C's <a href=
650-
"https://www.w3.org/Privacy/IG/">Privacy Interest Group</a> and
651-
<a href="https://www.w3.org/groups/wg/fedid/">Federated Identity
652-
Working Group</a>.
650+
"https://www.w3.org/groups/wg/privacy/">Privacy Working Group</a> and
651+
<a href="https://www.w3.org/groups/wg/fedid/">Federated Identity Working
652+
Group</a>.
653653
<aside class="note" title="Organizing reviews">
654654
Once an expression of registration is received via GitHub, the
655655
registry maintainers will organize the privacy review with the
656-
<a href="https://www.w3.org/Privacy/IG/">Privacy Interest Group</a> .
657-
Please see the [[[[security-privacy-questionnaire]]] for the kind of
658-
questions that will be asked of the protocol you are registering.
656+
<a href="https://www.w3.org/groups/wg/privacy/">Privacy Working
657+
Group</a> . Please see the [[[security-privacy-questionnaire]]] for
658+
the kind of questions that will be asked of the protocol you are
659+
registering.
659660
</aside>
660661
</li>
661662
<li>MUST have undergone security review by the <a href=
@@ -900,10 +901,10 @@ <h2>
900901
</ul>
901902
<p>
902903
Instead, these considerations focus on the Digital Credentials API
903-
itself, and describe how user agents can satisfy their <a href=
904-
"https://w3ctag.github.io/privacy-principles/#dfn-user-agent-duties">user
905-
agent duties</a> in an implementation of the API, taking into account
906-
the relevant privacy properties of the ecosystem it interacts with.
904+
itself, and describe how user agents can satisfy their <a data-cite=
905+
"privacy-principles#dfn-user-agent-duties">user agent duties</a> in an
906+
implementation of the API, taking into account the relevant privacy
907+
properties of the ecosystem it interacts with.
907908
</p>
908909
<p>
909910
The privacy considerations for digital credentials are not static. They
@@ -945,6 +946,178 @@ <h3>
945946
the exchange of information, before the exchange begins.
946947
</p>
947948
</section>
949+
<section>
950+
<h3>
951+
Exchange Protocol and Credential Format
952+
</h3>
953+
<p>
954+
Because the Digital Credentials API sits at the center of an exchange
955+
that involves multiple independent parties, the exchange protocol and
956+
credential format used by these parties for exchanging user
957+
information are crucial to the user agent's goal of protecting user
958+
privacy.
959+
</p>
960+
<p>
961+
The protocol registry for the Digital Credentials API is designed to
962+
ensure that, among other requirements, supported protocols facilitate
963+
specific privacy-enhancing capabilities. Protocols are required to
964+
undergo privacy review by the W3C's <a href=
965+
"https://www.w3.org/groups/wg/privacy/">Privacy Working Group</a>.
966+
</p>
967+
<h4>
968+
Exchange Protocol Considerations for User Privacy
969+
</h4>
970+
<h5>
971+
Selective disclosure
972+
</h5>
973+
<p>
974+
<a data-cite=
975+
"credential-considerations#selective-disclosure">Selective
976+
disclosure</a> is a fundamental technique for <a data-cite=
977+
"privacy-principles#data-minimization">data minimization</a> that
978+
allows holders to share the minimum required information that is
979+
requested by a verifier. Protocols are expected to facilitate
980+
selective disclosure by allowing the verifier to specify the exact
981+
claims needed.
982+
</p>
983+
<h5>
984+
Unlinkable presentations
985+
</h5>
986+
<p>
987+
<a data-cite=
988+
"credential-considerations#unlinkable-presentations">Unlinkability</a>
989+
is a property that ensures that, if a user presents attributes from a
990+
credential multiple times, verifiers cannot link these separate
991+
presentations to conclude they concern the same user
992+
(verifier-verifier linkability), or that verifiers can not collude
993+
with issuers to report the exchange of a credential from a wallet to
994+
the issuer (verifier-issuer linkability). The former is a property
995+
that can be maintained by the wallet and issuer, e.g. through issuing
996+
fresh credentials for individual verifiers.
997+
</p>
998+
<p>
999+
While the latter is achievable, e.g. through <a data-cite=
1000+
"vc-data-model#zero-knowledge-proofs">Zero-Knowledge Proofs</a>,
1001+
design choices of the API such as encrypted responses make it
1002+
impossible for a user agent to prove that verifier-issuer
1003+
unlinkability was achieved in practice. Nonetheless, protocols are
1004+
requested to limit linkability wherever possible.
1005+
</p>
1006+
<p>
1007+
Note that unlinkability is exclusively a consideration for attributes
1008+
that can not be linked to a specific user identity. Inherently linkable
1009+
attributes such as names, driver's license numbers or phone numbers do
1010+
not benefit from unlinkability.
1011+
</p>
1012+
<p>
1013+
Through the Digital Credentials API, the user agent can help verifiers
1014+
and wallets exchange unlinkable attributes, but it can not guarantee
1015+
that no linkable information is passed between verifiers and wallets.
1016+
It is recommended that user agents account for this fact in their
1017+
user permission experience.
1018+
</p>
1019+
<p class="issue" data-number="279">
1020+
Which level of unlinkability is the goal for this API? Can we
1021+
normatively enforce support for any particular unlinkability features
1022+
as part of the protocol registry inclusion criteria?
1023+
</p>
1024+
<h5>
1025+
"Phone home" mechanisms
1026+
</h5>
1027+
<p>
1028+
<a data-cite="credential-considerations#no-phoning-home">"Phoning
1029+
home"</a> refers to scenarios where the presentation or verification
1030+
of a digital credential causes a notification or communication back
1031+
to the issuer or another central entity, which can lead to tracking
1032+
and profiling of individuals.
1033+
</p>
1034+
<p>
1035+
Similar to unlinkability, it is impossible for user agents to ensure
1036+
that an issuer isn't actively involved in the creation or validation
1037+
of credential presentations after a user has given permission to
1038+
proceed with a credential request. From that point on, the wallet
1039+
application owns this decision. While some wallets can be considered
1040+
user agents, it is generally recommended that the user agent
1041+
implementing the Digital Credentials API designs its permission
1042+
experience to prevent <a href=
1043+
"#permission-prior-to-wallet-selection">exposure of a request to the
1044+
wallet application</a> before user confirmation (keeping in mind
1045+
<a href="#multiple-user-agents">considerations for integrating
1046+
multiple cooperating user agents</a>).
1047+
</p>
1048+
<p>
1049+
Protocols are required to support mechanisms that allow issuers,
1050+
wallets and verifiers avoid or reduce the dependence on "phone home"
1051+
mechanisms.
1052+
</p>
1053+
<p class="issue" data-number="279">
1054+
Which level of unlinkability is the goal for this API? To what degree
1055+
can the spec mandate restrictions to issuer involvement?
1056+
</p>
1057+
<h5>
1058+
Unlinkable revocation
1059+
</h5>
1060+
<p class="issue" data-number="280">
1061+
A common instance of issuer involvement in a credential exchange is
1062+
for credential revocation checks. This is particularly challenging
1063+
when presentations are intended to be verifier-issuer unlinkable.
1064+
When credential presentations are made unlinkable through the use of
1065+
e.g. Zero-Knowledge Proofs, the credential formats used in protocols
1066+
are expected to support offline revocation methods such as <a href=
1067+
"https://eprint.iacr.org/2024/657.pdf">Cryptographic
1068+
Accumulators</a>. It is further expected that protocol design and
1069+
specification discourages the involvement of verifiers for the
1070+
purpose of revocation where possible.
1071+
</p>
1072+
<p class="issue" data-number="280">
1073+
We should discuss whether unlinkable revocation techniques are
1074+
practical enough to be required normatively.
1075+
</p>
1076+
<h5>
1077+
Support for user transparency, permission and consent
1078+
</h5>
1079+
<p>
1080+
User understanding and participation are non-negotiable properties of
1081+
a credential exchange. The protocol is expected to help all involved
1082+
parties enable user participation by providing the information vital
1083+
for informed permission and/or consent.
1084+
</p>
1085+
<h5>
1086+
Support for verifier authorization
1087+
</h5>
1088+
<p>
1089+
Verifier authorization refers to the process by which a verifier
1090+
proves its identity and demonstrates that it is legitimately entitled
1091+
to request specific attributes or credentials. This is particularly
1092+
useful when exchanging sensitive data, such as from government-issued
1093+
credentials. Verifier authorization can limit unnecessary or abusive
1094+
credential requests, and ensure that a verifier's access is
1095+
restricted to the specific credential attributes it registered for.
1096+
</p>
1097+
<p>
1098+
Checking verifier authorization is usually handled by the wallet, but
1099+
user agents could find the presence of such a scheme helpful in
1100+
preventing API abuse and designing a well-informed user permission
1101+
experience.
1102+
</p>
1103+
<p class="issue" data-number="281">
1104+
Should we require protocols to include provisions that allow user
1105+
agents to understand verifier authorization?
1106+
</p>
1107+
<h5>
1108+
Encrypting credential responses
1109+
</h5>
1110+
<p>
1111+
To prevent exposure of user information to other parties in
1112+
"transit", for example browser extensions loaded on verifier pages,
1113+
and to encourage secure storage of user credentials by the verifier,
1114+
protocols are required to support and mandate encrypted responses in
1115+
a credential exchange.
1116+
</p>
1117+
<p class="issue" data-number="255">
1118+
Actually write these in the protocol requirements
1119+
</p>
1120+
</section>
9481121
<section>
9491122
<h3>
9501123
Unnecessary Requests for Credentials
@@ -1061,7 +1234,7 @@ <h3>
10611234
Should the API be designed so the site can provide in-context
10621235
explanations?
10631236
</p>
1064-
<h4>
1237+
<h4 id="multiple-user-agents">
10651238
Integrating Multiple User Agents
10661239
</h4>
10671240
<p>

0 commit comments

Comments
 (0)