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

[johannhof]

FYI @RByers @simoneonofri @martinthomson @npdoty

---

Preview | Diff

[marcoscaceres]

Suggested change

	This API is not meant to inhibit the development of other Web APIs
	that further push the boundaries on user privacy, for example an API
	that more strictly enforces unlinkability for specific purposes such
	as age verification.
	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.

[npdoty]

yeah, "push the boundaries on user privacy" definitely sounds like "which APIs can we develop that will invade users' privacy even more"

[npdoty]

But I think you should stick with "is not meant to inhibit" (if indeed we have agreement on that). As a practical matter it seems very likely that it will inhibit the development of more privacy-preserving APIs that have overlapping use cases. As noted in the Privacy Principles, designed-for-purpose APIs would make it easier to evaluate and explain the purposes of particular data practices and to limit harmful secondary uses.
https://www.w3.org/TR/privacy-principles/#purpose-limitation
As noted in the Web Platform Design Principles, it would also make it easier to for user agents to intervene on behalf of the user.
https://www.w3.org/TR/design-principles/#high-level-low-level

Suggested change

	This API is not meant to inhibit the development of other Web APIs
	that further push the boundaries on user privacy, for example an API
	that more strictly enforces unlinkability for specific purposes such
	as age verification.
	Although it is a risk of this approach, this API is not intended to inhibit the development of other Web APIs
	that enhance user privacy, for example an API
	that more strictly enforces unlinkability for specific purposes such
	as age verification.
	Higher-level, designed-for-purpose APIs often enable purpose limitation [[privacy-principles#purpose-limitation]], ease of explanation to the user, and privacy and security protections from user agents [[design-principles#high-level-low-level]].

[npdoty]

Opened #289 to track this consideration.

[martinthomson]

I'm not seeing a lot here that adds value, I'm afraid.

The core of the argument seems to be exactly the sort of "browsers acting as gatekeepers" language that elicits negative reactions from those outside of this industry.

Instead, I would choose a different framing for this...

• The goal of the API is to allow user agents to mediate requests for DCs from websites.
• This is necessary because user agents are able to better contextualize requests in the context of ongoing interactions with websites. This makes their involvement necessary to ensure that people are given the best tools to understand how their personal information will be used and by whom.
• Alternative approaches that attempt to circumvent these measures cannot deliver the same agency to people as they lose important context for reasons explained in these cited studies.

[martinthomson]

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.

[johannhof]

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".

[martinthomson]

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.

[johannhof]

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.

[johannhof]

I think that framing makes sense, thanks Martin. I can try to make it sound more like that :)

[npdoty]

I left some comments and suggestions, but then see that they were marked as resolved.

It's a lot harder to do reviews and keep track of potential changes when comments can just be marked resolved without comment. Then I have to chase down every time whether they were actually addressed or not, or where the issue needs to be tracked elsewhere.

Sorry! I left some comments in the conversation view on some other existing comments, which I thought submitted them immediately, and then Github showed them as marked resolved, when in fact they hadn't been submitted because it had started a review that I didn't submit. sigh Sorry for the extra confusion and noise here.

[npdoty]

I hadn't seen documentation of consumer demand and I'm not sure we need to include that here. I have seen regulatory mandates, and increased coercion by apps to force identity verification in more or less burdensome ways.

[npdoty]

yeah, "push the boundaries on user privacy" definitely sounds like "which APIs can we develop that will invade users' privacy even more"

[npdoty]

But I think you should stick with "is not meant to inhibit" (if indeed we have agreement on that). As a practical matter it seems very likely that it will inhibit the development of more privacy-preserving APIs that have overlapping use cases. As noted in the Privacy Principles, designed-for-purpose APIs would make it easier to evaluate and explain the purposes of particular data practices and to limit harmful secondary uses.
https://www.w3.org/TR/privacy-principles/#purpose-limitation
As noted in the Web Platform Design Principles, it would also make it easier to for user agents to intervene on behalf of the user.
https://www.w3.org/TR/design-principles/#high-level-low-level

Suggested change

	This API is not meant to inhibit the development of other Web APIs
	that further push the boundaries on user privacy, for example an API
	that more strictly enforces unlinkability for specific purposes such
	as age verification.
	Although it is a risk of this approach, this API is not intended to inhibit the development of other Web APIs
	that enhance user privacy, for example an API
	that more strictly enforces unlinkability for specific purposes such
	as age verification.
	Higher-level, designed-for-purpose APIs often enable purpose limitation [[privacy-principles#purpose-limitation]], ease of explanation to the user, and privacy and security protections from user agents [[design-principles#high-level-low-level]].

[npdoty]

Opened #289 to track this consideration.