Add suggestion to use Oblivious HTTP when fetching resources.

[msporny]

This PR attempts to address issue #1267 by suggesting that implementers consider Oblivious HTTP when fetching external resources. /cc @kdenhartog

---

Preview | Diff

[martinthomson]

What is your goal here? Are you seeking to protect the link between network identity and interest in a given identity? Is that the only factor that might be relevant from a privacy perspective?

[ShivanKaul]

I'd suggest using the official IETF datatracker link: https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp

[msporny]

Done in 0c37885, thank you!

[msporny]

@martinthomson wrote:

What is your goal here? Are you seeking to protect the link between network identity and interest in a given identity? Is that the only factor that might be relevant from a privacy perspective?

The goal is to do as much as possible to protect the link between the entity evaluating a Verifiable Credential (usually the Holder or Verifier) and any associated party of the Verifiable Credential (usually the Issuer). For example:

• For Holders using Digital Wallets, we want to reduce the chances that a Holder interacting with a Verifiable Credential in the digital wallet provides tracking information to a 3rd party. For example, a digital wallet fetching and rendering externally linked images, checking the validity of a Verifiable Credential (checking revocation lists stored externally to the credential), or visually displaying a particular aspect of the Verifiable Credential (links to external images, PDF files, or thumbnails).
• For Verifiers, we want to reduce signalling to an Issuer that the Verifier has received the Verifiable Credential -- for example, while checking the validity of a Verifiable Credential (checking revocation lists stored externally to the credential).

There are other factors that we care about from a privacy perspective (see the Privacy Considerations in the Table of Contents): https://www.w3.org/TR/vc-data-model-2.0/

The use of OHTTP was suggested by PING to be helpful from a "network signal that an attacker might use" standpoint.

[kdenhartog]

Noting this would close w3c/vc-bitstring-status-list#80 as well. It may be useful to point that status list back to here, but not necessary since it should be a given that people looking at those specs will refer back here.

@martinthomson During the original PING review, the main goal I was trying to prevent here was the resources hosted by the issuer (e.g. vc-status-list) can recreate the phone-home problem that this is trying to avoid. @msporny pointed out the main cases for this such as vc-status-list which is often hosted by the issuer such that they can analyze the IP traffic to see who's using the VC. It wouldn't be able to prevent time based correlation of when the verifier is verifying the status of the credential, but it would be able to help a bit was the idea.

[msporny]

@kdenhartog wrote:

It wouldn't be able to prevent time based correlation of when the verifier is verifying the status of the credential, but it would be able to help a bit was the idea.

It might also help noting that since the herd privacy status list this group is working on is also a Verifiable Credential, that the status list can be provided directly by the Holder, which avoids the "phone home to get the status list" problem entirely, even over OHTTP. The trade-off being that it can make the exchange protocol more complicated. We're going to speak to this in the status list specification... I was on the fence about mentioning it here.

[kdenhartog]

We're going to speak to this in the status list specification... I was on the fence about mentioning it here.

I think that makes sense to make that a focus there. Particularly because you still run into a liveness tradeoff if the holder is utilzing a cached status list or are faced with a temporal correlation (e.g. how often it's used) if the holder's UA decides to retrieve it each time before presentation. Given that's very specific to that spec that makes sense to do it separately there and here just more generally speak about the decorrelation of network identities and credential identities.

[msporny]

@martinthomson wrote:

What is your goal here? Are you seeking to protect the link between network identity and interest in a given identity? Is that the only factor that might be relevant from a privacy perspective?

I added new text in 0234a2b to provide concrete examples on the benefits of using OHTTP in certain scenarios.

[msporny]

Editorial, multiple reviews, changes requested and made, no objections, merging.

[TallTed]

@msporny — Actionable as comments, or do you want a PR for these?

[TallTed]

Suggested change

	of device tracking and fingerprinting. Concrete examples for how Oblivious HTTP
	can benefit ecosystem participants are included below.
	of device tracking and fingerprinting. Concrete examples of ways that Oblivious
	HTTP can benefit ecosystem participants are described below.

[TallTed]

Suggested change

	A <a>holder</a> using a digital wallet can reduce the chances that they
	will be tracked by a 3rd party when accessing external links within a
	A <a>holder</a> using a digital wallet can reduce their chances of being
	tracked by a third party when accessing external links within a

[TallTed]

Suggested change

	For example, a digital wallet might fetch and render linked images, or
	check the validity of a <a>verifiable credential</a> by fetching an
	externally linked revocation list.
	For example, a digital wallet might use Oblivious HTTP to fetch linked
	images for rendering, or to fetch an externally linked revocation list
	for use in checking the validity of a <a>verifiable credential</a>.

[TallTed]

Suggested change

	For example, a <a>verifier</a> might fetch an externally linked revocation
	list while performing status checks on a <a>verifiable credential</a>.
	For example, a <a>verifier</a> might use Oblivious HTTP to fetch an
	externally linked revocation list while performing status checks on a
	<a>verifiable credential</a>.