Consolidating allowed/preferred?

[eeeps]

The current proposal forces the name of the "preferred" policy to be listed twice:

Origin-Policy: allowed=(null "my-policy" "my-old-policy"), preferred="my-policy"

Could Origin-Policy instead take an ordered List of all "allowed" policy names, and treat the first policy as the de-facto “preferred” policy?

Origin-Policy: "my-policy", "my-old-policy", null

Pros: Simpler, lighter.
Cons: Not as self-explanatory. Less extensible? (to future keys besides allowed/preferred)

[domenic]

My intention while speccing out the algorithm was that you don't need to duplicate your preferred inside of allowed. I think this is captured in https://wicg.github.io/origin-policy/#update-an-origins-origin-policy, but perhaps not in the explainer.

I think the list version could work. It does lose one capability, which is to not have a preferred policy. I.e. if you do Origin-Policy: allowed=(null "my-policy" "my-old-policy") currently then the browser won't even bother to fetch an origin policy. But, uh, now that I write that out, that seems unrealistic.

Hmm...

[domenic]

I'm pretty convinced now that we should not separate allowed and preferred. However, the future keys problem is an issue, especially since we want to add report-to (#62).

My reading of the structured headers spec, then, is that the best way to accomplish this is to continue to use a dictionary + inner list, so something like

Origin-Policy: allowed=("my-policy" "my-old-policy" null); report-to=some-reporting-group

in the future. I don't see any way in the structured headers spec to use a top-level list, but also have parameters or other configuration options.

[domenic]

Gah. In the process of writing up a PR for this, I changed my mind.

The issue is that preferred= as a separate entry makes it explicit you are opting in to extra background updates. That is, you actually have preferences about what origin policy is in use, and if they're not met, then you expect the browser to do something.

If we just treat the first entry of allowed= as the preferred one, then the background updates become much more implicit. I.e., here is some of the text I ended up writing for how that world would look:

When the browser makes a request to a URL, the response can contain a header of the form

Origin-Policy: allowed=("polA" "polB" "polC" null)

This indicates that policies with identifiers "polA", "polB", or "polC", are acceptable to the site, and that the null origin policy is also acceptable. It also indicates that "polA" is the most-preferred policy identifier, in the fashion described below. (If the response contains no such header, this indicates that the page will accept any origin policy that is available, and there is no most-preferred policy.)

The browser then consults its current origin policy for the origin of the response, i.e. the one stored in the HTTP cache at $origin/.well-known/origin-policy:

• If that origin policy's "ids" member contains "policyA", the first policy ID, then the origin policy gets used, and nothing further happens.
• If that origin policy's "ids" member contains "polB" or "polC" and not "polA", then that origin policy gets used for this response, but the browser refreshes $origin/.well-known/origin-policy in the background.
• If that origin policy's "ids" member contains none of "polA", "polB", or "polC", then...
• If there is nothing stored there, then...

I think the current separation is a bit nicer. We still need to clarify that it's additive with allowed=, and you don't need to duplicate, but I think the model should stay as-is.