Encourage the use of OHTTP

[awoie]

From w3cping/privacy-request#121 (comment):

One additional point that was highlighted in w3cping/privacy-request#119 would be to utilize OHTTP more when needing to resolve contexts, status lists, credential schemas, etc from central servers to reduce IP based correlation.

[iherman]

The issue was discussed in a meeting on 2023-09-06

• no resolutions were taken

View the transcript

3.1. Encourage the use of OHTTP (issue vc-data-model#1267)

See github issue vc-data-model#1267.

Brent Zundel: oliver, can you walk us through #1267 and why it should be pre- or post-CR.

awoie: This issue resulted from ping group review, and a clarification or addition to security considerations would probably cover it, I believe.
… I can't think of any normative changes that this would necessitate, and I don't have strong opinion on pre- versus post.

Brent Zundel: if non-normative, post- should be fine.

Sebastian Crane: OHTTP hasn't cleared IETF yet, so even if we wanted to add a normative reference we can't yet.

Kristina Yasuda: ohttp has not been published by ietf yet!?

Manu Sporny: https://w3c.github.io/vc-data-integrity/#fingerprinting-network-requests.

Sebastian Crane: OHTTP === 'oblivious' HTTP.

Oliver Terbu: +1 manu.

Manu Sporny: the precedent is in the link i've just shared.

Dave Longley: https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/10/.

Sebastian Crane: I can take this issue and add a note post-CR.

[iherman]

The issue was discussed in a meeting on 2023-09-15

• no resolutions were taken

View the transcript

3.1. Encourage the use of OHTTP (issue vc-data-model#1267)

See github issue vc-data-model#1267.

Brent Zundel: This one is about use of OHTTP in the spec, as of yet, OHTTP isn't yet finished at IETF, can't reference it normatively, add encouragement that people make use of it when they can, when they make use of HTTP.

Kristina Yasuda: Similar to brent, we do have concerns about pointing to OHTTP since it's a draft at IETF... don't know if it's mature enough to recommend it -- OHTTP should be used once it's ready, is something like that acceptable?
… What are other WGs doing here?

Nick Doty: Rather than the specifics about OHTTP, it seems like recommendation is identifying when there is a threat about identifying IP address and using privacy preserving proxy, when you do that in a way that you can collude, use privacy preserving proxy... don't need to make normative reference to OHTTP, you can say when it's a threat and use privacy preserving proxy.

Kristina Yasuda: that makes more sense.

Manu Sporny: what about a CDN, would that work?

Nick Doty: Usually CDN works on behalf of issuer, so I don't think we'd say "that gives you privacy" -- some resources could be cached in a way that decreases how there is a request back to origin server, but I don't think we think about CDNs protecting you from colluding from server learning about the request.

Brent Zundel: I think we have enough direction to move forward on this issue... before CR w/o being assigned to it... otherwise, first thing we tackle before meeting again.

[OR13]

I suggest closing this issue, and taking no action

[iherman]

The issue was discussed in a meeting on 2023-10-18

• no resolutions were taken

View the transcript

2.1. Encourage the use of OHTTP (issue vc-data-model#1267)

See github issue vc-data-model#1267.

Brent Zundel: This doesn't have an assignee, came up during privacy review.

Manu Sporny: I can take this PR.

Orie Steele: I suggest we not do a PR for that, and instead close the issue.

Manu Sporny: 2-3 weeks, someone else do a PR before I get to it.

Dave Longley: could mark it after / during CR too instead.

Manu Sporny: This came from security/privacy review... it might be bad to just close it since it came from horizontal review.

Brent Zundel: Yes, we could ignore it, but neither of those options are the way things ought to be done.
… Thanks for volunteering, manu.

[msporny]

PR #1322 has been raised to address this issue. This issue will be closed once PR #1322 has been merged.

[msporny]

PR #1322 has been merged, closing.