The spec describes "inserting "/.well-known/" and the well-known URI suffix between the host component and the path component". I know why you're specifying that, and indeed, the reasons are discussed in the Compatibility Notes section at https://www.rfc-editor.org/rfc/rfc8414.html#section-5 . However, in practice, in multitenant systems, while the tenant will likely have write access to https://example.com// and can put a .well-known resource there, it likely will not have write access to https://example.com/ and so cannot put a .well-known resource there.
At a minimum, I'd describe the problem and say that, in practice, most implementations using paths will need to put the .well-known resource at the end of the path,.
P.S. There's a chance that Mark Nottingham and will update the .well-known RFC to explicitly allow this. I plan to talk to him about it at IETF in London next week.
The spec describes "inserting "/.well-known/" and the well-known URI suffix between the host component and the path component". I know why you're specifying that, and indeed, the reasons are discussed in the Compatibility Notes section at https://www.rfc-editor.org/rfc/rfc8414.html#section-5 . However, in practice, in multitenant systems, while the tenant will likely have write access to https://example.com// and can put a .well-known resource there, it likely will not have write access to https://example.com/ and so cannot put a .well-known resource there.
At a minimum, I'd describe the problem and say that, in practice, most implementations using paths will need to put the .well-known resource at the end of the path,.
P.S. There's a chance that Mark Nottingham and will update the .well-known RFC to explicitly allow this. I plan to talk to him about it at IETF in London next week.