Use base URL as client ID, AS should add on `.well-known/oauth-client-metadata` itself

[aaronpk]

This would make this spec parallel the AS Metadata RFC8414) and RS Metadata RFC9728 specs.

This would also help address the concern described here: bluesky-social/bsky-docs#363 giving the AS a better way to display a clean URL to the user.

[ThisIsMissEm]

However, this would prevent one host from serving multiple Client ID Metadata Documents (as is often necessary in development/staging environments)

[aaronpk]

Sorry, not fully written out. It doesn't actually prevent that.

client_id=https://example.com/ metadata at https://example.com/.well-known/oauth-client-metadata

client_id=https://example.com/client1 metadata at https://example.com/.well-known/oauth-client-metadata/client1

[ThisIsMissEm]

That seems like unnecessary indirection? Part of the beauty of these is that the client_id is the direct URI to the document, if you want to inspect it you can just visit the URL.

This would also break backwards compatibility with Solid-OIDC.

[aaronpk]

This would also break backwards compatibility with IndieAuth.

This is based on a long discussion with some MCP folks, largely stemming from the security concern of someone being able to get an AS to fetch arbitrary resources. There are also some threads on the BlueSky repo about these concerns.

Requiring some fixed string in the URL to the metadata helps avoid that, since it limits the possible URLs that can be fetched to URLs that contain the string. There are multiple ways to achieve this:

• Require that oauth-client-metadata or some other string appear anywhere in the URL
• Require the metadata URL ends in .json (much more permissive, but better than nothing)
• Use the .well-known pattern like AS and RS Metadata

BlueSky did a hybrid of this which is that if a predefined string is used in the URL, the full URL is not displayed to the end user: bluesky-social/atproto-website#419

[aaronpk]

Additional arguments extracted from the Discord chat about this:

• This would anchor on the hostname as the security boundary of the client. This is both a practical limitation as well as a security feature.
  • There are much better tools today for creation and management of subdomains compared to 10 years ago
  • This aligns better with the web origin model in browsers
• We will have to have the discussion of whether to use the IETF .well-known construct (insert .well-known/oauth-client-metadata between the host and path, or the OpenID pattern of tacking on /.well-known/oauth-client-metadata to the end of the URL

[panva]

I'd like to draw your attention to this summary of the current inconsistencies in the well-knowns we already have https://mailarchive.ietf.org/arch/msg/oauth/LLoteOrAn0sd172dsll254oHGX4/ in hopes that we can avoid them for future well-knowns.

We will have to have the discussion of whether to use the IETF .well-known construct (insert .well-known/oauth-client-metadata between the host and path, or the OpenID pattern of tacking on /.well-known/oauth-client-metadata to the end of the URL

I don't think the OpenID pattern would survive the IETF review process (much like it didn't for RFC-to-be 8414 and 9728)

[ThisIsMissEm]

I think I'd be fine with adding a constraint that the Client ID Metadata Document URL MUST contain a path component and MUST end with .json — this should be compatible with all existing deployments, including the prior art from Solid OIDC.

We could also add in a recommendation that "should a Client ID Metadata Document fail to resolve to a valid JSON document over successive calls (with backoff), then the URL/host should change to a "banned hosts" state. i.e., too many failures on a give domain, and the domain gets prohibited from being used.

[ThisIsMissEm]

I'd maybe even go as far as agreeing with oauth-client-metadata.json as the final path component, but I think it's still important to be able to host multiple Client ID Metadata Documents on the one domain.