Allow semi-wildcard `Timing-Allow-Origin` values (for subdomains)

4.5.1 Timing-Allow-Origin Response Header
...
If the Timing-Allow-Origin header value list contains a case-sensitive match for the value of the origin of the current document, or a wildcard ("*"), return pass.

With the current state of the art, it's possible to return TAO values like:

• https://www.example.com
• *

It's not possible to specify "semi-wildcard" values to allow subdomains of a given domain, like:

• https://*.example.com

Was this use case ever considered? Are there any reasons to not allow it like this?
(it would add a bit more complexity to the spec and implementations, but nothing unreasonable).

A scenario I'm thinking about is:

• my subresources are hosted by a CDN (though I can control the response headers), hence different origin than the website
• I want to allow various subdomains of my domain to opt-in to TAO, including internal ones.
• I do not want to enumerate all internal subdomains explicitly in the header value for security reasons, to not leak too much information about the internal environment.
• I do not want to allow * either for security reasons.
• It's much easier to set static TAO response header than to vary it on a per-response basis.

We could argue that in the CDN scenario with static responses it's probably (most of the time) not a big deal to allow * origins, so maybe the example I made up is a bit artificial. But I still think that in some environments, it might be easier to convince ops people to activate the header on *.mydomain.com than on * -- it would require less analysis from security point of view to have it approved.

Start with the quoted Resource Timing 4.5.1 specification text describing Timing-Allow-Origin matching. Review the proposed https://.example.com syntax and the security trade-offs against explicit origins and ''. Done means reaching a documented decision on whether semi-wildcard values should be specified and how they should match subdomains.