This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We define domain names, including IDNA. We should consider defining https://publicsuffix.org/ to more properly define cookies. If we want to "explain" this, we need an API too. Promise-based, to allow asynchronous cross-process lookup? Or would that not allow for explaining cookies well? IETF effort by Yngve in this area that is apparently still ongoing (including an XML format I once sketched): http://tools.ietf.org/html/draft-pettersen-subtld-structure Twitter had the idea first: https://twitter.com/hillbrad/status/469465792237826048
https://wiki.mozilla.org/Public_Suffix_List/Uses
The public suffix list defines some of the effective security boundaries of the Web by setting rules about where cookies can be set or the limits of lowering of document.domain for the purposes of SOP enforcement. It would be useful to be able to interrogate the current environment's definition of these boundaries from a non-same-origin perspective. e.g. it would be nice if example.com could determine if example.co.uk and example2.co.uk are both subdomains of a registry-issued domain name "co.uk" or if they are distinct and isolated entities (which is actually the case). Given that domain/origin-based security mechanisms are already explicitly used elsewhere in the platform, e.g. for postMessage, it can be useful to know if two domains are effectively isolated or not, or if a domain is a public suffix. External libraries exist that incorporate the publicsuffix.org data, but this risks being out-of-sync with the actual data being enforced by the platform, especially for packaged apps or extensions.
I filed https://github.com/publicsuffix/list/issues/27 to see if the Public Suffix List is interested in defining the processing model. The check document.domain makes is to see if domain is a public suffix or if a public suffix ends with "." followed by domain. The check cookies has is just "is a public suffix" which does not seem to account for the second scenario. Likely a bug? What you're asking for seems slightly different, but if you know what a a domain's public suffix is you should be able to figure out the rest.
We'll leave this to HTML for now and require everyone to reuse the algorithm defined there: https://github.com/whatwg/html/pull/2365.