Re: [Gen-art] /.well-known placed below the URI local-part root

[Mark Nottingham <[e-mail]>]

Hi Nico.

(a) (b) Appendix A already talks about it some:

"""
   Why aren't per-directory well-known locations defined?
      Allowing every URI path segment to have a well-known location
      (e.g., "/images/.well-known/") would increase the risks of
      colliding with a preexisting URI on a site, and generally these
      solutions are found not to scale well because they're too
      "chatty".
"""

We could say more in the spec proper, I suppose.

(c) seems like a good pattern to recommend for people who really want to scratch this itch -- although I suspect some will complain that it's hard to maintain the linkages (it's not really, they just need a competent sysadmin).

(d) is not something I'm keen to do. Just because people have done it shouldn't mean that we should give that practice any formal air cover.

(e) The current approach we take is that every registration is effectively its own name space; it can do what it likes with substructure (including establishing another registry). That gives a lot of freedom, but it's caused some confusion (e.g., most recently with EST and extensions to it), so some indication of what policy is in use would be interesting -- either in the spec, or the registry itself. It may be too early or this, but I could see a list of common management mechanisms being created for easy reuse.

Question: do you see any of these issues as urgent? .well-known got revised relatively recently, so I'd like to collect some more feedback/issues before reopening the box, ideally. If they're not urgent, would it be OK to just log them as open issues (I use <https://github.com/mnot/I-D/labels/well-known>)?

Cheers,


> On 1 May 2020, at 5:42 am, Nico Williams <[e-mail]> wrote:
> 
> RFC 8615 (and RFC 5785 before it) says that .well-known should be at the
> root of the URI local-part.  Appendix A explains the rationale.
> 
> However, I'm seeing multi-tenancy in OpenID, with URI local-parts of the
> form /${tenant}/.well-known/openid-configuration, which is not the
> intended usage.  /.well-known/openid-configuration/${tenant} would have
> been better, given what the RFC says.
> 
> I suspect this happened because the registration for the
> openid-configuration well-known URI [0] did not cover this use case.
> 
> Not sure that anything can or should be done about this, but it might be
> worth reporting it here, thus this post.
> 
> If I had to propose anything at all to do about this, it might be to
> update RFC 8615 to a) describe the use case, b) describe what has been
> done, c) recommend or require /.well-known/thing/thang over
> /thing/.well-known/thang, d) possibly grandfather some existing uses of
> /thing/.well-known/thang, e) maybe update the registry to require that
> registrants indicate whether they intend to have further structure below
> their well-known URIs.
> 
> Nico
> 
> [0] https://openid.net/specs/openid-connect-discovery-1_0.html

--
Mark Nottingham   https://www.mnot.net/