Marking  issue 554220  as dependency because both bugs require a largish change to do PUSH validation as a function of response headers, and I'll work on the other one first.

Just to capture some discussions with bnc@ on a design doc:

The current requirement (that a channel ID be scoped to the eTLD+1) is a requirement driven by both privacy and security requirements.

Privacy, in that a channel ID is "effectively" a cookie and that, by allowing this request cross-pollination, conceptually represents a "third-party tracking cookie" - which is unacceptable.

Security, in that channel ID is not exclusively limited to cookies. That is, it's functionally a mechanism that can allow you to bind any resources/expressions to the bound token (and via Chrome-specific APIs, allows you to extract the public key from the bound token), and thus it's important to ensure a resource has the correct channel ID associated with the origin.

For non-credentialed (Fetch term) or anonymous (CORS term) or privacy mode (Chrome term) requests, the eTLD+1 restriction won't apply, because Channel ID will not have been used.

For virtually all non-Google traffic, the eTLD+1 restriction won't apply (because Channel ID will not have been used)

For Google traffic, that is credentialed (Fetch), non-anonymous (CORS), non-privacy mode (Chrome), Channel ID may be used, and if so, the eTLD+1 restriction is important for both security and privacy, independent of cookies, so can't be removed.

Re comment #4: thank you for the detailed explanation.  Based on our discussion, I am closing this issue at WontFix.