Code change:
This provides two band-aids to URL, and may also close it far enough that RD can progress without the underlying topic being solved in full.
This is a tracking issue to cover the topics of URL -- see there for discussion, the issue is primarily kept for cross-linking PRs.
Since this is covered well enough that it need not stop RD. Further exploration should happen in ACE and CoRE. Hello CoRE, one of the outstanding issues in RD is server authorization with respect to operations on particular paths. This continues an ACE thread[1] I regrettably missed to follow up on, but simplifies the examples based on the recent interims. While originally phrased as the attacker tricking the server into using the client's good credentials for something the client did not intend, here they are phrased now in terms of server authorization as relevant for RD discovery and RD security policies. For two examples, a client needs to trust a server to provide a service, but has received misleading hints that cause disagreement between the client and the server about the performed operation. Example 1 An RD with a "links are confidential" policy also operates a bulletin board at . During the unprotected discovery phase, the endpoint is fed a link . The client connects to URL, verifies that its server credentials are good for an RD that will reveal links posted to it only to authorized lookup clients. It then posts all its links to /bb, where anyone who knows to use a bulletin board can read them. Example 2 A time server also exposes its current core temperature as . A malicious RD operator modifies the time server's registration to read . A starting device in the network asks the RD for any rt=unixtime, verifies that URL is indeed authorized to give the right time, and wakes up on the morning of January 1st, 1970. Problem summary The client has an abstract intention with an operation, which it checks against the server's authorization. Then it forms that intention, with additional unverified knowledge about the server, into a request, which it protects. The server then reconstructs that intention with its authoritative knowledge of itself, and uses any client provided credentials to act on it. If the client's knowledge about the server is erroneous, the intentions are misaligned. Neither is the intention protected, nor does the client point out the claims it wants to hold the server to in its request (or, in the original examples from the ACE thread, express the precise claims about itself it intends the server to assess). Solution approaches In the ACE thread back then, Jim said that he'd expect the client to use different keys (originally in talking to the AS, and thus different keys in talking to the RS). Doing that to the end would probably result in the devices having to handle a lot more keys, something like one for any operation that could be mixed up with any other? Michael in the last interim mentioned that in OAuth it's common to only run one service on one host for the very same reason. Kind of boils down to the same thing, as virtual-hosting these services would create multiple keys. My approach in the -25 RD Section 7.2 is to (losely, there; would need stronger and more precise wording) say that any information that any information using which intention is encoded in the request in a lossy way is to be rechecked from the origin server. That'd be more or less straightforward for example 1, but incur an additional costly recheck with the origin server about many things that could be learned efficiently from the RD. Does any of that solve the issues? Can we do any better? How do we put that into RD to satisfy the small comment about Section that opens this can of worms? Is there anything quotable on OAuth's best practices on multiple services on the same host? Best regards Christian [1]: URL To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom

Related discussion:
text: URIs and relative references, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. <ins> With security policies where the client requires the RD to be authorized to act as an RD, that authorization may be limited to resources on which the authorized RD advertises the adequate resource types.  Clients that have obtained links they can not rely on yet can repeat the URI discovery step at the /.well-known/core resource of the indicated host to obtain the resource type information from an authorized source. </ins> The URI Discovery operation can yield multiple URIs of a given resource type.  The client of the RD can use any of the discovered addresses initially.