Re: same-origin assertions in the DNS (Fwd: [apps-discuss] draft-sullivan-domain-origin-assert-00)

On May 10, 2012, at 4:24 PM, =JeffH <Jeff.Hodges@KingsMountain.com> wrote:

> In reply to Adam's and Maciej's noting that there's issues with -domain-origin-assert with respect to "the web origin concept" (RFC6454)..
> 
> The use of the term "origin" for this notion -- i.e., asserting administrative realm domain name boundaries -- is obviously unfortunately confusing and a different term/name probably should be used.
> 
> That said, the intention of this (so-called at the moment) "BOUND" declaration would be as a data source for "effective TLD (eTLD)" aka "public suffix" information, which is presently used in a number of places where domain names are manipulated/compared in (notably) browsers (e.g. search firefox and/or chromium source for "effective_tld" or "eTLD").
> 
> A couple of particular examples of such use are in evaluating whether to allow a cookie to be set for a particular Domain attribute (RFC6265), and in examining asserted server certificate subject domain names (e.g., not accepting a cert for "*.com").

Then why does it mention "cross-document information sharing in ECMAScript DOM", which has nothing to do with the eTLD mechanism?

> 
> The only way it seems that such a mechanism (e.g. "BOUND" and/or eTLD data) would be involved in Web Origins would be in evaluation/comparison of a web origin's host (aka domain name) component -- and this appears to already be the case anyway.

Do you just mean that a host extracted from an Origin could possibly be processed after the fact, using eTLD data from BOUND records, or are you implying that BOUND record data would affect the comparison of hosts that is part of making a same-origin determination?

Regards,
Maciej

Received on Sunday, 13 May 2012 10:46:08 UTC