Wildcards in Permissions Policy Origins

[arichiv]

This change will add support for wildcard in permissions policy structured like SCHEME://.HOST:PORT (e.g., https://.foo.com/) where a valid Origin could be constructed from SCHEME://HOST:PORT (e.g., https://foo.com/). This requires that HOST is at least eTLD+1 (a registrable domain). This means that https://.bar.foo.com/ works but https://.com/ won’t (if you want to allow all domains to use the feature, you should just delegate to ). Wildcards in the scheme and port section will be unsupported and https://.foo.com/ does not delegate to https://foo.com/.

Before, a permissions policy might need to look like:
permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://cdn1.foo.com" "https://cdn2.foo.com")

With this feature, it could look like:
permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://*.foo.com")

This flexibility assists developers that need to delegate permissions to multiple subdomains (e.g., CDNs).

This is an in-progress change, the following components are needed:

• Update ABNF
• Define matching
• Add example

Design Doc: https://docs.google.com/document/d/1_Y5qRs0CO2_R7o8M_YaVAWQvyjXniG70RG2z1a2uwN8/edit

closes #479

---

Preview | Diff

[arichiv]

@yoavweiss have a sec for review? I want to get the ABNF correct before moving on to deeper integration

The other option is to do something more explicit like https://www.w3.org/TR/CSP2/#host_part, but it seemed desirable to not reinvent the wheel since we aren't supporting wildcards everywhere.

[arichiv]

Forgot @yoavweiss is out, @clelland have time to take a look?

[arichiv]

Updated with the matching logic.

[yoavweiss]

Non-authoritative LGTM

[clelland]

I think there's still a piece missing here -- we're going to need at least 4 parts to incorporate this:

• The syntax of an origin with a wildcard (which I think is good)
• An internal representation that can be part of an allowlist
• The parsing logic to get from a header string to that internal representation
• The matching logic to compare that internal representation to an origin in algorithms

So far, this has the syntax, and correctly defines serialized-origin-with-wildcard-subdomain as a string, but those strings aren't allowed in allowlists (per https://w3c.github.io/webappsec-permissions-policy/#allowlists), and I think that the matching logic is trying to operate directly on those strings, which is awkward -- and to do it right, we'd need to convert back and forth between strings and origins.

A way to resolve this would be to change the definition of what an allowlist can contain -- define an "origin with possible wildcard" to be an origin, and a boolean that says whether it also matches subdomains. Then the matching logic can check that boolean to know whether to do the deeper match.

Regardless of how we handle it, we'll need to change 9.2. Construct policy from dictionary and origin and 9.3. Parse policy directive to parse the serialized-origin-with-wildcard-subdomain strings explicitly. Currently the call to the URL parser will fail because of the wildcards.

[arichiv]

@clelland good point! I think I integrated at the necessary spots now.

[arichiv]

I thought we reached agreement at TPAC that this should share logic with CSP?

I thought the agreement was that any further expansion of the wildcard syntax would require sharing logic with CSP, but that for this restrictive wildcard support a local modification was acceptable.

[annevk]

I think that any kind of wildcard parsing needs to have shared logic. We don't want multiple independent code paths for this that need to be audited separately and have the opportunity for divergence if future maintainers are not careful.

[arichiv]

Restarting this since it's been a while. Will live on in:
#516