requireScheme checks for a scheme and nothing else, so urn:example:api constructs a resource here and fails later, at derivation, if a PRM URL is asked for. Other implementations in this family refuse it at construction, requiring a scheme and a non-empty host.
So the same configured identifier starts this server and stops another at startup. That is a divergence, not a gap, and it should be settled once rather than per SDK.
Both readings are defensible
Scheme-only (what this SDK does). RFC 8707 §2 requires the resource indicator to be an absolute URI, and urn:example:api is one. Construction is not the place to refuse it; derivation is, and that is where it fails today with a message naming the missing component.
Scheme-and-host. RFC 9728 §1.2 defines the resource identifier as a URL, and a URN is not one. §3 forms the metadata URL by inserting the well-known string after the host component — with no host there is nothing to insert into, so an identifier that cannot produce a document URL cannot serve the role at all. Refusing it at construction refuses it where the operator can still act, rather than at the first 401.
The two RFCs are describing different roles for the same string — the §8707 indicator sent to an authorization server, and the §9728 identifier this server publishes about itself. That is why implementations landed on different answers rather than one of them simply being wrong.
What depends on this
The rfc9728-resource-identifier-must-be-an-absolute-url-with-scheme-and-host conformance case is registered here as PARTIAL with exactly this as the named gap: both of the case's stimuli are refused, but the requirement is scheme and host and only the scheme half is enforced at construction. Settling this moves the case to FULL or leaves it honestly partial forever.
If scheme-and-host wins, requireScheme becomes requireSchemeAndHost, the derivation-time check stays as a backstop, and opaque identifiers stop constructing — a behaviour change with a migration note.
requireSchemechecks for a scheme and nothing else, sourn:example:apiconstructs a resource here and fails later, at derivation, if a PRM URL is asked for. Other implementations in this family refuse it at construction, requiring a scheme and a non-empty host.So the same configured identifier starts this server and stops another at startup. That is a divergence, not a gap, and it should be settled once rather than per SDK.
Both readings are defensible
Scheme-only (what this SDK does). RFC 8707 §2 requires the resource indicator to be an absolute URI, and
urn:example:apiis one. Construction is not the place to refuse it; derivation is, and that is where it fails today with a message naming the missing component.Scheme-and-host. RFC 9728 §1.2 defines the resource identifier as a URL, and a URN is not one. §3 forms the metadata URL by inserting the well-known string after the host component — with no host there is nothing to insert into, so an identifier that cannot produce a document URL cannot serve the role at all. Refusing it at construction refuses it where the operator can still act, rather than at the first 401.
The two RFCs are describing different roles for the same string — the §8707 indicator sent to an authorization server, and the §9728 identifier this server publishes about itself. That is why implementations landed on different answers rather than one of them simply being wrong.
What depends on this
The
rfc9728-resource-identifier-must-be-an-absolute-url-with-scheme-and-hostconformance case is registered here asPARTIALwith exactly this as the named gap: both of the case's stimuli are refused, but the requirement is scheme and host and only the scheme half is enforced at construction. Settling this moves the case toFULLor leaves it honestly partial forever.If scheme-and-host wins,
requireSchemebecomesrequireSchemeAndHost, the derivation-time check stays as a backstop, and opaque identifiers stop constructing — a behaviour change with a migration note.