chris-wood
commented
2 years ago I think there's some confusion in terminology going on here. As I understand the situation, the path parameter (which still seems necessary) discussed in #12 was for the oblivious request resource, not the oblivious target resource. It's unfortunate that the request resource is referred to as the target in ODoH, which seems to contribute to the confusion.
In any case, maybe adding the path to the .well-known endpoint that vends out keys is a reasonable way forward. @bemasc rightfully points out that these need to be treated atomically anyway from a consistency perspective. Then there'd be one simple way to fetch a configuration.
The current document is a little light on detail, probably a little too light.
Firstly, it needs to be directly acknowledged that the assertion being made here is that ALL resources on an HTTP server are accessible using OHTTP. That is all the HTTPS record is able to assert. See also, the closed #12, which talked about
ohttp-path. This is fine, as OHTTP doesn't really care what you put inside the encrypted message to the oblivious request resource, so an origin-wide assertion works fine as long as your intermediaries (proxy and request resources) are OK with it.What you then need in order to make a request is a) an oblivious proxy resource, and b) an oblivious request resource. The draft acknowledges the need for the first and says that you bring your own. What it doesn't say is how to get the latter.
As OHTTP depends on these being independent entities, it isn't at all clear that the choice of oblivious request resource follows from your choice of oblivious proxy resource OR the choice of oblivious target resource.
It's possible that clients will have separate arrangements with entities that operate both proxy and request resources, entities that are independent of this target. That's probably the ideal situation.
As we've discussed though, it makes a fair bit of sense to co-locate the request resource with the target. For that, you need to know which resource on the server serves that function. A .well-known for that is a possibility, though I might prefer not to overuse .well-known and might instead suggest that you would provide a path to the request resource in configuration. There is no harm in allowing configuration for that resource.