Skip to content

Add design considerations section to privacy considerations (fixes #275) #278

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Add design considerations section to privacy considerations (fixes #275) #278

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
e415f50
Add design considerations section to privacy considerations
johannhof Jun 17, 2025
246b559
Update index.html
johannhof Jun 18, 2025
2318428
Update index.html
johannhof Jun 18, 2025
3a81e0b
Update index.html
johannhof Jun 18, 2025
5be3222
Update index.html
johannhof Jun 18, 2025
d8597b6
Update index.html
johannhof Jun 18, 2025
e8c86fe
Update index.html
johannhof Jun 18, 2025
7589285
Address review comments
johannhof Jun 18, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 59 additions & 8 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,18 @@
date: "2025-05-28",
publisher: "W3C"
},
"custom-schemes": {
title: "Concerns with custom schemes for identity presentment",
href: "https://github.com/w3c-fedid/digital-credentials/blob/main/custom-schemes.md",
authors: ["Rick Byers"],
date: "2024-05-01",
publisher: "W3C"
},
"presenting-credentials-on-the-web": {
title: "Presenting Credentials on the Web",
href: "https://docs.google.com/document/d/1Ppaz_EnhzHqPOz5UusRJvbSunh-RXPWgJ3Np_TM2EE0/",
authors: ["Simone Onofri"]
},
},
xref: {
profile: "web-platform",
Expand Down Expand Up @@ -919,6 +931,45 @@ <h2>
evolving privacy landscape and participate in the corresponding
evolution of the API.
</p>
<section>
<h3>
Design Considerations and Alternatives
</h3>
<p>
When reviewing the privacy characteristics of the Digital Credentials
API it is important to understand the goals of its design, which is
to offer a more secure and private user experience than the existing
alternatives.
Comment on lines +939 to +942
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When reviewing the privacy characteristics of the Digital Credentials
API it is important to understand the goals of its design, which is
to offer a more secure and private user experience than the existing
alternatives.
The goal of the Digital Credentials API is
to offer a more secure and private user experience than existing
alternatives.

We do not/cannot tell people what is important to them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can rephrase this, it's actually meant as "the privacy characteristics of the API are a result of the design choices made for the reasons described in this section".

</p>
<p>
As more [=verifiers=] and [=issuers=] join the rapidly emerging
digital credentials space, an important choice for implementation is
the connection between [=verifiers=] and [=holders=], i.e. the means
by which a [=digital credential/exchange protocol|credential exchange
protocol=] is initiated and the user navigates from the website
they're browsing to their [=holder=] application.
Comment on lines +945 to +950
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This "rapidly emerging" framing is fixed to a point in time and not the sort of thing that we need to talk about.

Also, isn't this "the process of presentation"? Maybe with "on the Web", though that is implied from context, so it might not be necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah... I didn't like writing it like that either, but there's an undeniable reality that we have an opportunity window where new technologies get adopted more quickly than at other times, especially when browsers have little power in restricting these technologies because of regulatory mandates. This is context that I believe (and I think @npdoty who requested this kind of introduction, agrees) may be important to consider for wider review of the API.

I will say it sounds a bit awkward when combined with the "important choice" thing - the fact that the connection is important is not temporary. I can try to reword.

</p>
<p>
As documented in [[[presenting-credentials-on-the-web]]] and
[[[custom-schemes]]], QR codes and custom URL schemes solutions have
security, privacy, and accessibility concerns, and offer the user
agent very little ability to intermediate on behalf of the user (e.g.
in the form of a [=credential chooser=]).
</p>
<p>
With adoption of digital credential technology being driven by
consumer demand and regulatory mandates, it is essential for user
agents to offer an alternative to these harmful technologies that is
easy to use for developers, is compatible with existing credential
exchange protocols and, most importantly, significantly increases
user privacy, security, and accessibility.
</p>
<p>
This API does not inhibit the development of other APIs that further
enhance user privacy. For example, an API that more strictly enforces
unlinkability of age verification.
</p>
</section>
<section data-cite="vc-data-model#spectrum-of-privacy">
<h3>
Spectrum of Privacy
Expand Down Expand Up @@ -1005,16 +1056,16 @@ <h5>
</p>
<p>
Note that unlinkability is exclusively a consideration for attributes
that can not 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.
that can not 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.
</p>
<p>
Through the Digital Credentials API, the user agent can help verifiers
and wallets exchange unlinkable attributes, but it can not guarantee
that no linkable information is passed between verifiers and wallets.
It is recommended that user agents account for this fact in their
user permission experience.
Through the Digital Credentials API, the user agent can help
verifiers and wallets exchange unlinkable attributes, but it can not
guarantee that no linkable information is passed between verifiers
and wallets. It is recommended that user agents account for this fact
in their user permission experience.
</p>
<p class="issue" data-number="279">
Which level of unlinkability is the goal for this API? Can we
Expand Down