Resource Identifier Validation Enforces URL Semantics

[dacamposol]

RFC 8707 and RFC 8693 introduce the resource indicator for OAuth 2.0, defined as a URI. Critically, RFC 8707 states:

The client SHOULD use the base URI of the API as the resource parameter value unless specific knowledge of the resource dictates otherwise.

Many Authorization Server implementations (correctly) interpret this as allowing the use of URNs to uniquely identify logical resources within an application scope. For example:

urn:<NAMESPACE>:identity:application:provider:name:<API_NAME>

This pattern is in production today.

However, the resource metadata validation (per the draft) enforces strict identity checks on the resource field that are only coherent if the resource identifier is a URL:

The resource value returned MUST be identical to the protected resource's resource identifier value into which the well-known URI path suffix was inserted to create the URL used to retrieve the metadata.
...
If the protected resource metadata was retrieved from a URL returned by the protected resource via the WWW-Authenticate resource_metadata parameter, then the resource value returned MUST be identical to the URL that the client used to make the request to the resource server.

These rules imply a strict one-to-one mapping between resource identifiers and metadata URLs, assuming that the resource is a dereferenceable HTTP(S) URL. This assumption breaks when URNs or other non-resolvable identifiers are used, which is entirely valid per the original RFCs.

As a consequence, this breaks compatibility with existing deployments where:

• Authorization Servers issue tokens based on URNs as resource values
• Resource Servers use these URNs for authorization decisions
• No direct HTTP URL representation of the resource exists or is meaningful

Such deployments cannot expose metadata under a .well-known location derived from a URL, because no such URL exists for the resource identifier.

RFC 8693 explicitly supports abstract (non-dereferenceable) resource identifiers:

A URI that indicates the target service or resource where the client intends to use the requested security token. [...] In many cases, a client will not have knowledge of the logical organization of the systems with which it interacts and will only know a URI of the service where it intends to use the token.

This explicitly anticipates situations where the client uses opaque or abstract URIs (like URNs) to indicate the target resource.

Request

Please clarify whether the intent is to mandate resolvable URL-based resource identifiers across the ecosystem, or whether the spec should remain compatible with URN-based deployments as allowed by RFC 8693 and RFC 8707.

If URL-based identity is mandatory, this constitutes a breaking change that invalidates a class of compliant implementations. If not, the metadata validation rules should be revised to support non-URL resource identifiers (e.g., by decoupling the identifier from the retrieval URL, or by providing an explicit mapping).

[aaronpk]

Protected Resource Metadata only applies to resource identifiers that are URLs. The point is to enable the resource server to publish metadata about itself at a URL. This does not apply to resources identifiers that are not URLs, as the metadata about the resource server is already solved today via out-of-band methods such as prior registration at the AS.

[dacamposol]

@aaronpk While I agree with your point, my use case specifically concerns the Model Context Protocol (MCP), which depends on the Protected Resource Metadata to determine the appropriate Authorization Server (AS) for Dynamic Client Registration (DCR), or alternatively, to obtain a public client ID, as per the GitHub Copilot workaround for AS implementations that don’t support DCR.

Given this, I’ll aim to shift the discussion toward how MCP handles this scenario. Currently, our Authorization Server either:

1. Does not require a .resource parameter at the token endpoint, as it is considered optional.
2. Expects .resource to contain a valid URN identifying the resource, per customer requirements.

Since many enterprise-grade AS implementations have reservations about supporting DCR (hence the Copilot workaround), it may be worthwhile to define an additional flow within MCP that allows a client to obtain a pre-registered public client ID and proceed using a public client authorization flow.

[aaronpk]

There's a lot of discussion going on right now about how to better handle clients for MCP when you don't want to have an open DCR endpoint. But in any case, that is irrelevant to the question about the resource identifier.

One of the things this spec enables is to configure a client by only entering the URL of the resource server. That capability is desirable regardless of whether the client is pre-registered at the AS. For example, you could imagine an employee downloads VS Code and wants to connect it to their enterprise GitHub account. The employee could still enter only the MCP server URL for GitHub and proceed with the OAuth flow. How the GitHub AS knows what client this is, and how the client determines what client ID to use, is an interesting problem and there are some solutions such as using Client ID Metadata to avoid DCR but also allow the AS to have an explicit list of allowed clients. But that still has nothing to do with the resource server metadata URL.