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 <n...@cryptonector.com> 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/
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
