Tighten discovery/API base URL, TLS identity, and credential boundaries

[Mehrn0ush]

Summary

.well-known endpoints[].url and tea-server-info.rootUrl are still format: uri with no HTTPS / component restrictions. That undercuts #276’s TLS and credential-boundary rules if a conforming base can be http://, and it makes /v{version}/… appending ambiguous (userinfo, query, fragment, trailing slash).

Follow-up to #276 / #275. Related but separate from #282. Independent of #261 TEI syntax.

Proposed

Require absolute HTTPS base URLs with no userinfo, query, fragment, or trailing slash (well-known url and discovery rootUrl).

Optional: explicit hostname checks per RFC 6125 section 6; same “no TEA token to external URLs” sentence on release-distribution.url / signatureUrl (already stated for artifact formats / redirects).

My question

For 1.0: should absolute HTTPS base URLs be required?
If yes, include the TLS-identity and release-distribution riders in the same PR, defer them, or drop as non-blocking?

[taleodor]

Yes to absolute HTTPS base URLs for conforming deployments, with two adjustments: enforce the structural rules in the schema, and the scheme rule in prose with a client-side carve-out for local testing.

Context: the prose already requires HTTPS everywhere (discovery/readme.md lines 255, 435–443, 509; auth/readme.md 207; signatures/signature.md 46). What is missing is that endpoints[].url and tea-server-info.rootUrl are format: uri, which validators treat as annotation only, so http://host/x?y#z/ validates as a conforming base. The more useful half of this issue is the structure: appending /v{version}/… is only well defined if the base has no userinfo, query, fragment or trailing slash, and nothing enforces that today. There is no test-server carve-out anywhere; the only http:// in the consumer surface is the OpenAPI servers example http://localhost/tea/v1.0.0 ("Local development"), which an HTTPS-only schema would contradict.

1. Structure in the schema

One pattern on both discovery/tea-well-known.schema.json endpoints[].url and OpenAPI tea-server-info.rootUrl:

^https?://[^/?#@]+(/[^?#]*[^/?#])?$

Absolute, authority without userinfo, optional path, no query, no fragment, no trailing slash. http stays allowed at the schema level so test documents still validate (#282 made a non-conforming well-known document a failover trigger).

2. Scheme in prose, carve-out on the client side

discovery/readme.md, TLS section:

Conforming deployments shall advertise only `https` base URLs, in `.well-known/tea`
`endpoints[].url` and in `/discovery` `servers[].rootUrl` alike. A client shall reject an
`http` base URL unless it has been explicitly configured to allow it for local testing.

And on the OpenAPI servers entry, so the existing example is honest:

servers:
  - url: http://localhost/tea/v1.0.0
    description: Local development only; HTTPS is required outside local testing

3. Riders, in the same PR

• Server identity check: after "verify the server certificate", add "including the server identity check of RFC 9525". RFC 6125 is obsolete (replaced by 9525 in 2023); cite the current one.
• release-distribution.url / signatureUrl: copy the sentence already on artifact formats — a TEA access token is sent only to the TEA server's own API base URL, never to an external URL. Distribution locations are external in exactly the same way.

Nothing deferred; all of it is one small PR.