Discovery

[martinthomson]

This probably covers a bunch of things, so I'll start with a few things that might want to be discovered automatically:

1. Clients might want to ask the oblivious proxy resource which oblivious request resource it forwards to.
2. Clients might want to learn about which oblivious target resources a particular oblivious request resource is willing to forward to.
3. Clients might want to learn automatically about the public keys the oblivious request resource has (along with key identifiers, see #16).
4. Clients might want to ask about the oblivious proxy resources that forward to a particular oblivious request resource. This is a little tricky, because clients will need to exercise discretion in selecting from this set. This also risks exposing the existence of DoS exemption agreements between the oblivious request resource server and the oblivious proxy resource server.
5. Clients might want to ask the oblivious target resource for an oblivious request resource (or by extension oblivious proxy resource) that it can use to reach that resource.

If you look at this as link relations, this is two forward links, a key configuration, and two backward links. Defining link relation types for this might be a way to address this. Assuming that we also define a media type for a key configuration format, that is.

[elear]

This seems to me to the fundamental challenge with this system, and a great many other systems. DHTs have been used to advertise resource availability, but the searched object is quite hard to blind from everyone. We could say that good is the enemy of great, only we've been at this a while, and neither have shown up.

[chris-wood]

@elear use of the word "system" is interesting here. OHTTP does not describe a system, but a protocol. The way that this protocol is deployed and used in practice, I think, defines the system. (The same argument goes for protocols like DoH.) So I don't see this as a challenge to the protocol design, but rather to how one might configure and use it in practice. And that seems rightfully out of scope.

[elear]

@chris-wood Document that practice a bit, then, if it is practice. I don't view the DoH document as a resounding success, fwiw. It left many questions unanswered, to the point that we had to spin up another working group just to address them. My fundamental question remains: does ohttp contribute more positive than negative? No use case in the document means no understanding of that. I do appreciate Martin and Eric's explanation on list. Perhaps that should be incorporated.

[martinthomson]

You might not find this satisfactory, but there is text in the draft about exactly the use cases that Ekr described.

https://unicorn-wg.github.io/oblivious-http/draft-thomson-http-oblivious.html#name-applicability has those two.

Are you asking for more discussion of the relationship between various actors in those use cases?

[elear]

Martin, the example you gave was really good. The trick is to show how the players interact.

[martinthomson]

Discussed at IETF 113 and the WG decided that we would continue the discovery discussion in relation to other drafts.