Clarify: must `jwksUri` be same-authority as the discovery endpoint, or is cross-host allowed?

[MahdiBaghbani]

Hi all, I'm working on an OCM implementation and ran into something the spec doesn't seem to answer directly, so I wanted to get other people's read on it before I lock anything in.

When a server advertises jwksUri in its discovery response, does the jwksUri host have to match the discovery/ocm endpoint host, or is a different host allowed (say a CDN or a dedicated keys host)?

The spec is clear about three things: the path is not fixed, it MUST use https (HTTP only in testing), and it MUST be advertised when http-sig is exposed. What I can't find is any line saying the jwksUri host has to equal the discovery host. The example is same-host with a custom path (https://cloud.example.org/ocm/jwks), but that's an example, not a constraint.

Refs at 6a05861:

• spec.yaml:

  OCM-API/spec.yaml

  Lines 534 to 545 in 6a05861

  	jwksUri:
  	type: string
  	format: uri
  	description: >
  	Optional URL of a JWK Set document [RFC7517] containing the
  	public keys this OCM Server uses for HTTP Message Signatures
  	[RFC9421]. The URL is discovered from this field; it is not a
  	fixed path in the OCM API. If the `http-sig` capability is
  	exposed, the jwksUri MUST be advertised in the discovery
  	response and MUST use https, though implementations MAY fall
  	back to HTTP in testing setups.
  	example: https://cloud.example.org/ocm/jwks

• discovery field:

  OCM-API/IETF-OCM.md

  Lines 774 to 782 in 6a05861

  	* OPTIONAL: jwksUri (string) - https URL of a JWK Set document
  	[RFC7517] containing the public keys this OCM Server uses for HTTP
  	Message Signatures. The URL is discovered from this field; it is
  	not a fixed path in the OCM API.
  	Implementations that advertise the `"http-sig"` capability MUST
  	provide this URL as well, and it MUST use https. As with the
  	Discovery Process, implementations MAY fallback to HTTP instead of
  	HTTPS in testing setups.
  	Example: `"https://cloud.example.org/ocm/jwks"`.

• verifier discard reasons:

  OCM-API/IETF-OCM.md

  Lines 1297 to 1299 in 6a05861

  	* no trusted JWK Set can be obtained for the FQDN part of the
  	`sender` field in the request body, via the `jwksUri` field of its
  	Discovery response

That last one ties the JWK Set to "the FQDN part of the sender field ... via the jwksUri field of its Discovery response". To me that reads like the keys belong to the same server identified by the sender FQDN, but it doesn't actually add a "host must match" rule, it just says the keys are obtained via whatever URL the discovery advertises.

I can argue both ways and I'm honestly not sure which is intended.

For allowing cross-host: the spec doesn't forbid it, and moving jwksUri into a discovery field was supposedly about operator flexibility. A CDN or a separate keys host is a real pattern, OIDP IdPs do it with jwks_uri all the time. And for self-advertisement it's the operator's own URL, not peer-controlled input, so the SSRF argument against it is kind of weak.

For same-authority only: the FQDN -> discovery -> jwksUri chain reads more naturally if the keys live on the same host. And if a receiver enforces same-authority on peers (some do), a server that advertises a cross-host jwksUri just becomes interoperably broken, peers would reject the URL it advertised. Same-host also keeps the fetch target on the already-vetted discovery origin, smaller surface than "any https URL a discovery doc points at".

So, a few things I'd like to hear from you:

1. Is same-authority for jwksUri an intended constraint, or just a side effect of the example?
2. How do existing implementations (Reva, Nextcloud, ownCloud/oCIS) treat a peer jwksUri whose host differs from the discovery host? Accept, reject, or not implemented yet?
3. Worth adding one normative line either way, a MUST for same-authority or an explicit "host is not constrained" note?

[mickenordin]

My intent has been that it should not have to be served from the ocm server itself, the vision I have is that we should be able to reuse infrastructure that is already there, and point to them from the ocm server. If the ocm discovery is served over tls, then it should not matter if it points to another https url, the same thing is true for the token endpoint, that we also want to be able to serve from somewhere else. Den 29 juli 2026 08:47:22 CEST, Mahdi Baghbani ***@***.***> skrev:

…

MahdiBaghbani created an issue (cs3org/OCM-API#394) Hi all, I'm working on an OCM implementation and ran into something the spec doesn't seem to answer directly, so I wanted to get other people's read on it before I lock anything in. When a server advertises `jwksUri` in its discovery response, does the `jwksUri` host have to match the discovery/ocm endpoint host, or is a different host allowed (say a CDN or a dedicated keys host)? The spec is clear about three things: the path is not fixed, it MUST use https (HTTP only in testing), and it MUST be advertised when `http-sig` is exposed. What I can't find is any line saying the `jwksUri` host has to equal the discovery host. The example is same-host with a custom path (`https://cloud.example.org/ocm/jwks`), but that's an example, not a constraint. Refs at `6a05861`: - spec.yaml: https://github.com/cs3org/OCM-API/blob/6a0586183cbef10ecae9dedc42561806447eb2f5/spec.yaml#L534-L545 - discovery field: https://github.com/cs3org/OCM-API/blob/6a0586183cbef10ecae9dedc42561806447eb2f5/IETF-OCM.md#L774-L782 - verifier discard reasons: https://github.com/cs3org/OCM-API/blob/6a0586183cbef10ecae9dedc42561806447eb2f5/IETF-OCM.md#L1297-L1299 That last one ties the JWK Set to "the FQDN part of the `sender` field ... via the `jwksUri` field of its Discovery response". To me that reads like the keys belong to the same server identified by the sender FQDN, but it doesn't actually add a "host must match" rule, it just says the keys are obtained via whatever URL the discovery advertises. I can argue both ways and I'm honestly not sure which is intended. For allowing cross-host: the spec doesn't forbid it, and moving `jwksUri` into a discovery field was supposedly about operator flexibility. A CDN or a separate keys host is a real pattern, OIDP IdPs do it with `jwks_uri` all the time. And for self-advertisement it's the operator's own URL, not peer-controlled input, so the SSRF argument against it is kind of weak. For same-authority only: the FQDN -> discovery -> `jwksUri` chain reads more naturally if the keys live on the same host. And if a receiver enforces same-authority on peers (some do), a server that advertises a cross-host `jwksUri` just becomes interoperably broken, peers would reject the URL it advertised. Same-host also keeps the fetch target on the already-vetted discovery origin, smaller surface than "any https URL a discovery doc points at". So, a few things I'd like to hear from you: 1. Is same-authority for `jwksUri` an intended constraint, or just a side effect of the example? 2. How do existing implementations (Reva, Nextcloud, ownCloud/oCIS) treat a peer `jwksUri` whose host differs from the discovery host? Accept, reject, or not implemented yet? 3. Worth adding one normative line either way, a MUST for same-authority or an explicit "host is not constrained" note? -- Reply to this email directly or view it on GitHub: #394 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>