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

From: Nico Williams <[email-masked]>
Date: Thu, 30 Apr 2020 14:42:05 -0500

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 May 2020 09:32:27 +1000

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 <[email-masked]> wrote:
> 

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Apr 2020 20:35:57 -0500

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

The more to say really is to have some examples showing how to do the
multi-tenancy thing.

I mean, it's obvious -- it's obvious to me anyways.

But evidently it's not actually that obvious.  At least one person I've
spoken to thought the text in section 3 of RFC 8615 does allow use below
the root, and I can see how such a misunderstanding can happen: "each
app has its own root, no?".  Because, yes, if you think about "mounting
an app" on the URI local-part "filesystem", then "each app has its own
root" makes sense.

> (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).

It's not an itch though, more like an accident.  People do this because
they build a service, they put it under /mysvc, then they add
multi-tenancy and don't set up a separate authority for each tenant
because hey, local-part components are cheap.

> (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.

+1  (I wrote "possibly" because I'm not keen on it either.)

> (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.

Well, as you're the Expert Reviewer, maybe you can just start looking
out for this, asking registrants to write a blurb about this in their
specs and user-facing docs.  Maybe that's all that needs to be done for
the moment.

> 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>)?

Not urgent.  I think this can be handled by the Expert Reviewer for new
registrations until more changes pile up for RFC 8615.

I've opened https://github.com/mnot/I-D/issues/315

Thanks for the quick reply!

Nico
--