Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

I have to say that the current known use-cases for site-meta are:

1. Security critical ones, but for server-to-server discovery uses (not
browser mediated)

2. Semantic ones, for user consumption, of an informative rather than
security-critical nature. These use cases may be handled by browsers.

I agree that it is worth to look at the security consequences, but at least
to me at this point, it is not clear that the traditional same-policy
paradigm used by browsers is relevant here.


On Wed, Feb 11, 2009 at 12:38 PM, Adam Barth <w3c@adambarth.com> wrote:

>
> On Wed, Feb 11, 2009 at 11:55 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> > There is nothing incorrect about: GET mailto:joe@example.com HTTP/1.1
>
> I don't know how to get a Web browser to generate such a request, so I
> am unable to assess its security implications.
>
> > It might look funny to most people but it is perfectly valid. The
> protocol
> > is HTTP, the scheme is mailto. HTTP can talk about any URI, not just http
> > URIs. Since this is about *how* /host-meta is obtained, it should talk
> about
> > protocol, not scheme.
>
> Here's my understanding of how this should work (ignoring redirects
> for the moment).  Please correct me if my understanding is incorrect
> or incomplete:
>
> 1) The user agent retrieves the host-meta file by requesting a certain
> URL from the network layer.
>
> 2) The network layer does some magic involving protocols and
> electrical signals on wires and returns a sequence of bytes.
>
> 3) The user agent now must compute a scope for the retrieved host-meta
> file.
>
> I recommend that the scope for the host-meta file be determined from
> the URL irrespective of whatever magic goes on in step 2. because this
> is the way all other security scopes are computed in Web browsers.
> For example, if I view an HTML document location at
> http://example.com/index.html, its security origin is (http,
> example.com, 80) regardless of whether the HTML document was actually
> retrieved by carrier pigeon or SMTP.
>
> (To handle redirects, by the way, you have to use the last URL in the
> redirect chain.)
>
> Adam
>
>


-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)