Fallback flow for /site-meta for top level domains

[Eran Hammer-Lahav-2]

(sorry for potential duplicates, I'm having problems posting to the list)

This issue was brought up by Google.

There are many cases where the HTTP server for example.com resides at www.example.com. Should /site-meta specify that if a top level domain returns a 404 for a GET /site-meta, the user-agent must try the same request for www.*?

EHL

[Douglas Boldt]

I would think that any competent host master/web master would have properly setup IN A records for the rootdomain, and CNAME's for www, per RFC specs. Ideally they would go further and 301 redirect one to the other on the application level.

 

douglas [at] http://boldt.us

On Sat, Nov 29, 2008 at 4:55 PM, Eran Hammer-Lahav <hueniverse@...> wrote:

(sorry for potential duplicates, I'm having problems posting to the list)

This issue was brought up by Google.

There are many cases where the HTTP server for example.com resides at www.example.com. Should /site-meta specify that if a top level domain returns a 404 for a GET /site-meta, the user-agent must try the same request for www.*?

EHL

[mnot]

Absolutely not. the spec is already stomping on an authority's control  
over its namespace quite enough, and it's easy for people to work  
around this if their intent is for the two to be the same.


On 30/11/2008, at 8:55 AM, Eran Hammer-Lahav wrote:

> (sorry for potential duplicates, I'm having problems posting to the  
> list)
>
> This issue was brought up by Google.
>
> There are many cases where the HTTP server for example.com resides  
> at www.example.com. Should /site-meta specify that if a top level  
> domain returns a 404 for a GET /site-meta, the user-agent must try  
> the same request for www.*?
>
> EHL
>

--
Mark Nottingham     http://www.mnot.net/

[Dirk Balfanz]

I'm not quite following. How does this proposal stomp on people's namespace? If they want to serve different documents on the two domains (and can figure out how to do so), they can.

Also, the question isn't really whether _we_ think it's easy or not to point one to the other, but whether we think that a large number of registrars make it unintuitive for a large number of amateurs to do so.

Dirk.

On Nov 30, 2008 6:56 PM, "Mark Nottingham" <mnot@...> wrote:


Absolutely not. the spec is already stomping on an authority's control over its namespace quite enough, and it's easy for people to work around this if their intent is for the two to be the same.

On 30/11/2008, at 8:55 AM, Eran Hammer-Lahav wrote: > (sorry for potential duplicates, I'm havin...

--
Mark Nottingham     http://www.mnot.net/

[Breno de Medeiros]

On Sun, Nov 30, 2008 at 6:05 PM, Dirk Balfanz <balfanz@...> wrote:
> I'm not quite following. How does this proposal stomp on people's namespace?
> If they want to serve different documents on the two domains (and can figure
> out how to do so), they can.
>
> Also, the question isn't really whether _we_ think it's easy or not to point
> one to the other, but whether we think that a large number of registrars
> make it unintuitive for a large number of amateurs to do so.

Yes, this is a concern for long tail-end of sites with less
professional administrators. Hosted site administrators typically do
not like to deal with DNS issues if they can afford not to.

>
> Dirk.
>
> On Nov 30, 2008 6:56 PM, "Mark Nottingham" <mnot@...> wrote:
>
>
> Absolutely not. the spec is already stomping on an authority's control over
> its namespace quite enough, and it's easy for people to work around this if
> their intent is for the two to be the same.
>
> On 30/11/2008, at 8:55 AM, Eran Hammer-Lahav wrote: > (sorry for potential
> duplicates, I'm havin...
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>
>

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

[Dirk Balfanz]

[+www-talk again]

On Sun, Nov 30, 2008 at 6:17 PM, Mark Nottingham <mnot@...> wrote:

On 01/12/2008, at 1:05 PM, Dirk Balfanz wrote:

I'm not quite following. How does this proposal stomp on people's namespace? If they want to serve different documents on the two domains (and can figure out how to do so), they can.

Yes, but doing it by default is forcing them to work around a special case. If www.example.com and example.com are really equivalent, the site administrator is already making that work (through a variety of means); why do they need this?

Also, the question isn't really whether _we_ think it's easy or not to point one to the other, but whether we think that a large number of registrars make it unintuitive for a large number of amateurs to do so.

Explain the use case; what can't they do?

Well, here is the scenario: I buy foobar.com for $3/year at cheapdomains.com. I pay an extra dollar to have "email", which means I tell them where I want my email forwarded. I pick dirk@... to be forwarded to dirk@.... I pay another extra dollar per year for "web hosting", which means I get a web interface on cheapdomains.com to create some web pages, which get served on www.foobar.com. I set up a couple of pages there with pictures of my cats or whatever and I am done. 

I now also want to use my email address dirk@... as my OpenID identifier [1] because I heard that that will end my having to create ever-more accounts on the web. I am told that in order to get that to work I need to host a page called "site-meta" on my site with some weird-looking text in it that I don't understand. But, hey, I know how to get that served off www.foobar.com so that's cool.

I have never heard of DNS.

Is that a use case we want to support?

Dirk.

[1] Let's assume that OpenID 3.0 and XRD 2.0 allow that and define some way to discover OpenID endpoints from email addresses.

 

Dirk.


On Nov 30, 2008 6:56 PM, "Mark Nottingham" <mnot@...> wrote:


Absolutely not. the spec is already stomping on an authority's control over its namespace quite enough, and it's easy for people to work around this if their intent is for the two to be the same.
On 30/11/2008, at 8:55 AM, Eran Hammer-Lahav wrote: > (sorry for potential duplicates, I'm havin...

--
Mark Nottingham     http://www.mnot.net/

--
Mark Nottingham     http://www.mnot.net/

[mnot]

On 02/12/2008, at 1:25 PM, Dirk Balfanz wrote:

>
> Well, here is the scenario: I buy foobar.com for $3/year at  
> cheapdomains.com. I pay an extra dollar to have "email", which means  
> I tell them where I want my email forwarded. I pick dirk@...  
> to be forwarded to dirk@.... I pay another extra dollar per  
> year for "web hosting", which means I get a web interface on  
> cheapdomains.com to create some web pages, which get served on www.foobar.com
> . I set up a couple of pages there with pictures of my cats or  
> whatever and I am done.
>
> I now also want to use my email address dirk@... as my OpenID  
> identifier [1] because I heard that that will end my having to  
> create ever-more accounts on the web. I am told that in order to get  
> that to work I need to host a page called "site-meta" on my site  
> with some weird-looking text in it that I don't understand. But,  
> hey, I know how to get that served off www.foobar.com so that's cool.
>
> I have never heard of DNS.
>
> Is that a use case we want to support?
>
> Dirk.
>
> [1] Let's assume that OpenID 3.0 and XRD 2.0 allow that and define  
> some way to discover OpenID endpoints from email addresses.

/site-meta on http://foobar.com/ doesn't (and can't, on its own) make  
any authoritative assertions about mailto:dirk@...; even though  
the authority is the same, the URI scheme is different.

I know this particular issue is an important one to the OpenID folks,  
but there needs to be a very careful and broad discussion of allowing  
policy and metadata from HTTP to be considered *automatically*  
authoritative for other protocols.

--
Mark Nottingham     http://www.mnot.net/

[Breno de Medeiros]

On Tue, Dec 2, 2008 at 4:24 PM, Mark Nottingham <mnot@...> wrote:

>
>
> On 02/12/2008, at 1:25 PM, Dirk Balfanz wrote:
>>
>> Well, here is the scenario: I buy foobar.com for $3/year at
>> cheapdomains.com. I pay an extra dollar to have "email", which means I tell
>> them where I want my email forwarded. I pick dirk@... to be forwarded
>> to dirk@.... I pay another extra dollar per year for "web hosting",
>> which means I get a web interface on cheapdomains.com to create some web
>> pages, which get served on www.foobar.com. I set up a couple of pages there
>> with pictures of my cats or whatever and I am done.
>>
>> I now also want to use my email address dirk@... as my OpenID
>> identifier [1] because I heard that that will end my having to create
>> ever-more accounts on the web. I am told that in order to get that to work I
>> need to host a page called "site-meta" on my site with some weird-looking
>> text in it that I don't understand. But, hey, I know how to get that served
>> off www.foobar.com so that's cool.
>>
>> I have never heard of DNS.
>>
>> Is that a use case we want to support?
>>
>> Dirk.
>>
>> [1] Let's assume that OpenID 3.0 and XRD 2.0 allow that and define some
>> way to discover OpenID endpoints from email addresses.
>
> /site-meta on http://foobar.com/ doesn't (and can't, on its own) make any
> authoritative assertions about mailto:dirk@...; even though the
> authority is the same, the URI scheme is different.

The email address is a distraction here. The core issue is independent of that.

vanity-example.com (hosted only at www.vanity-example.com) is a small
site and wants to enable all their user URLs
www.vanity-example.com/bob, www.vanity-example.com/alice to be useful
as discovery endpoints for user services. Thankfully some other site,
more professionally managed, is willing to provide discovery services,
aggregation, etc., on behalf of the users of these vanity domains.

If the standard does not call for site-meta to be alternatively hosted
at www.{domain} then we may possibly see application/protocols to use
"expanded" discovery mechanisms that say: if you can't find site-meta
where it is supposed to be, try appending www. before the discovery
location.  The "expanded" version will then become a de-facto
alternative standard, at least in some application contexts. Whether
to support this "www.'' alternative directly in the standard depends
on how the community feels about promoting full interoperability of
the standard across different applications that are built on it.

>
> I know this particular issue is an important one to the OpenID folks, but
> there needs to be a very careful and broad discussion of allowing policy and
> metadata from HTTP to be considered *automatically* authoritative for other
> protocols.

EAUT and a cluster of other mechanisms are already out there that make
this assumption. Since the need to support email-based discovery will
not go away, and can't be addressed by a protocol other than HTTP
(because of the variety of HTTP client architectures), we need to
address it. That is much more likely to lead to fragmentation and poor
interoperability than the issue above (the 'www.' issue). I think it
is a certain bet that something supporting HTTP-based discovery
starting from email identifiers will come into common use.


>
> --
> Mark Nottingham     http://www.mnot.net/
>
>
>



--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

[mnot]

On 03/12/2008, at 1:35 PM, Breno de Medeiros wrote:

> On Tue, Dec 2, 2008 at 4:24 PM, Mark Nottingham <mnot@...> wrote:
>>
>>
>> On 02/12/2008, at 1:25 PM, Dirk Balfanz wrote:
>>>
>>> Well, here is the scenario: I buy foobar.com for $3/year at
>>> cheapdomains.com. I pay an extra dollar to have "email", which  
>>> means I tell
>>> them where I want my email forwarded. I pick dirk@... to be  
>>> forwarded
>>> to dirk@.... I pay another extra dollar per year for "web  
>>> hosting",
>>> which means I get a web interface on cheapdomains.com to create  
>>> some web
>>> pages, which get served on www.foobar.com. I set up a couple of  
>>> pages there
>>> with pictures of my cats or whatever and I am done.
>>>
>>> I now also want to use my email address dirk@... as my OpenID
>>> identifier [1] because I heard that that will end my having to  
>>> create
>>> ever-more accounts on the web. I am told that in order to get that  
>>> to work I
>>> need to host a page called "site-meta" on my site with some weird-
>>> looking
>>> text in it that I don't understand. But, hey, I know how to get  
>>> that served
>>> off www.foobar.com so that's cool.
>>>
>>> I have never heard of DNS.
>>>
>>> Is that a use case we want to support?
>>>
>>> Dirk.
>>>
>>> [1] Let's assume that OpenID 3.0 and XRD 2.0 allow that and define  
>>> some
>>> way to discover OpenID endpoints from email addresses.
>>
>> /site-meta on http://foobar.com/ doesn't (and can't, on its own)  
>> make any
>> authoritative assertions about mailto:dirk@...; even though  
>> the
>> authority is the same, the URI scheme is different.
>
> The email address is a distraction here. The core issue is  
> independent of that.
>
> vanity-example.com (hosted only at www.vanity-example.com) is a small
> site and wants to enable all their user URLs
> www.vanity-example.com/bob, www.vanity-example.com/alice to be useful
> as discovery endpoints for user services. Thankfully some other site,
> more professionally managed, is willing to provide discovery services,
> aggregation, etc., on behalf of the users of these vanity domains.

You just lost me. Why is it important to have site metadata for a site  
that doesn't exist, if the e-mail issue is a distraction?

--
Mark Nottingham     http://www.mnot.net/

[Breno de Medeiros]

The 'naked domain' version of the site may not be DNS-resolvable,
while the www. prepended version of the domain may be. In addition,
the fact that a resource URL does not exist (in the sense that it
might return a 404) does not mean that it cannot have meaningful
associated meta-data.


On Tue, Dec 2, 2008 at 6:40 PM, Mark Nottingham <mnot@...> wrote:

>
> On 03/12/2008, at 1:35 PM, Breno de Medeiros wrote:
>
>> On Tue, Dec 2, 2008 at 4:24 PM, Mark Nottingham <mnot@...> wrote:
>>>
>>>
>>> On 02/12/2008, at 1:25 PM, Dirk Balfanz wrote:
>>>>
>>>> Well, here is the scenario: I buy foobar.com for $3/year at
>>>> cheapdomains.com. I pay an extra dollar to have "email", which means I
>>>> tell
>>>> them where I want my email forwarded. I pick dirk@... to be
>>>> forwarded
>>>> to dirk@.... I pay another extra dollar per year for "web
>>>> hosting",
>>>> which means I get a web interface on cheapdomains.com to create some web
>>>> pages, which get served on www.foobar.com. I set up a couple of pages
>>>> there
>>>> with pictures of my cats or whatever and I am done.
>>>>
>>>> I now also want to use my email address dirk@... as my OpenID
>>>> identifier [1] because I heard that that will end my having to create
>>>> ever-more accounts on the web. I am told that in order to get that to
>>>> work I
>>>> need to host a page called "site-meta" on my site with some
>>>> weird-looking
>>>> text in it that I don't understand. But, hey, I know how to get that
>>>> served
>>>> off www.foobar.com so that's cool.
>>>>
>>>> I have never heard of DNS.
>>>>
>>>> Is that a use case we want to support?
>>>>
>>>> Dirk.
>>>>
>>>> [1] Let's assume that OpenID 3.0 and XRD 2.0 allow that and define some
>>>> way to discover OpenID endpoints from email addresses.
>>>
>>> /site-meta on http://foobar.com/ doesn't (and can't, on its own) make any
>>> authoritative assertions about mailto:dirk@...; even though the
>>> authority is the same, the URI scheme is different.
>>
>> The email address is a distraction here. The core issue is independent of
>> that.
>>
>> vanity-example.com (hosted only at www.vanity-example.com) is a small
>> site and wants to enable all their user URLs
>> www.vanity-example.com/bob, www.vanity-example.com/alice to be useful
>> as discovery endpoints for user services. Thankfully some other site,
>> more professionally managed, is willing to provide discovery services,
>> aggregation, etc., on behalf of the users of these vanity domains.
>
> You just lost me. Why is it important to have site metadata for a site that
> doesn't exist, if the e-mail issue is a distraction?
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

[Breno de Medeiros]

Ah, I see where your confusion is coming from. The average user does
not know that www.vanity-domain.com/bob is a different URL from
vanity-domain.com/bob (or alternatively, that www.vanity-domain.com is
a different location than vanity-domain.com). We can thank all the
major browsers for that.

On Tue, Dec 2, 2008 at 7:45 PM, Breno de Medeiros <breno@...> wrote:

> The 'naked domain' version of the site may not be DNS-resolvable,
> while the www. prepended version of the domain may be. In addition,
> the fact that a resource URL does not exist (in the sense that it
> might return a 404) does not mean that it cannot have meaningful
> associated meta-data.
>
>
> On Tue, Dec 2, 2008 at 6:40 PM, Mark Nottingham <mnot@...> wrote:
>>
>> On 03/12/2008, at 1:35 PM, Breno de Medeiros wrote:
>>
>>> On Tue, Dec 2, 2008 at 4:24 PM, Mark Nottingham <mnot@...> wrote:
>>>>
>>>>
>>>> On 02/12/2008, at 1:25 PM, Dirk Balfanz wrote:
>>>>>
>>>>> Well, here is the scenario: I buy foobar.com for $3/year at
>>>>> cheapdomains.com. I pay an extra dollar to have "email", which means I
>>>>> tell
>>>>> them where I want my email forwarded. I pick dirk@... to be
>>>>> forwarded
>>>>> to dirk@.... I pay another extra dollar per year for "web
>>>>> hosting",
>>>>> which means I get a web interface on cheapdomains.com to create some web
>>>>> pages, which get served on www.foobar.com. I set up a couple of pages
>>>>> there
>>>>> with pictures of my cats or whatever and I am done.
>>>>>
>>>>> I now also want to use my email address dirk@... as my OpenID
>>>>> identifier [1] because I heard that that will end my having to create
>>>>> ever-more accounts on the web. I am told that in order to get that to
>>>>> work I
>>>>> need to host a page called "site-meta" on my site with some
>>>>> weird-looking
>>>>> text in it that I don't understand. But, hey, I know how to get that
>>>>> served
>>>>> off www.foobar.com so that's cool.
>>>>>
>>>>> I have never heard of DNS.
>>>>>
>>>>> Is that a use case we want to support?
>>>>>
>>>>> Dirk.
>>>>>
>>>>> [1] Let's assume that OpenID 3.0 and XRD 2.0 allow that and define some
>>>>> way to discover OpenID endpoints from email addresses.
>>>>
>>>> /site-meta on http://foobar.com/ doesn't (and can't, on its own) make any
>>>> authoritative assertions about mailto:dirk@...; even though the
>>>> authority is the same, the URI scheme is different.
>>>
>>> The email address is a distraction here. The core issue is independent of
>>> that.
>>>
>>> vanity-example.com (hosted only at www.vanity-example.com) is a small
>>> site and wants to enable all their user URLs
>>> www.vanity-example.com/bob, www.vanity-example.com/alice to be useful
>>> as discovery endpoints for user services. Thankfully some other site,
>>> more professionally managed, is willing to provide discovery services,
>>> aggregation, etc., on behalf of the users of these vanity domains.
>>
>> You just lost me. Why is it important to have site metadata for a site that
>> doesn't exist, if the e-mail issue is a distraction?
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>
>
>
> --
> --Breno
>
> [phone] desk
> [phone] (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

[mnot]

So, let's walk through the actual use cases.

AIUI, you're saying that Joe will want to use
   vanity-domain.com/joe
as his identifier, even though
   http://www.vanity-domain.com/joe
is the correct one?

If so, a few thoughts;

1) These days, it's much more likely that the domain will actually be
    http://joe.vanity-domain.com/
so I can't help but feel that this argument is something of a straw-man.

2) Even putting that aside, if Joe puts
   vanity-domain.com/joe
into his browser bar, he'll get
   http://www.vanity-domain.com/joe
thanks to the automated action of the browser; he can (and probably  
will anyway) cut-and-paste that string.

3) Even putting that aside, he can easily learn
   http://www.vanity-domain.com/joe
or his software can for him.

4) ...and if he doesn't like that, he can move to another provider  
which does provide better access (market economies and all that).

5) Even putting that aside, if the browsers are deciding to cowboy it  
up and automagically munge URLs in browser bars (probably in non-
compatible ways, BTW), why does this need to be codified in a  
standard? Why not just let them do it on their own, like they're doing  
now?

Don't get me wrong - if OpenID (for example) wants to specify this  
kind of behaviour, or if browsers / providers want to do it on their  
own, that's up to them. The problem is when we try to enshrine it in a  
*generic* metadata discovery mechanism that potentially will be used  
for lots of things.


On 03/12/2008, at 2:53 PM, Breno de Medeiros wrote:

> Ah, I see where your confusion is coming from. The average user does
> not know that www.vanity-domain.com/bob is a different URL from
> vanity-domain.com/bob (or alternatively, that www.vanity-domain.com is
> a different location than vanity-domain.com). We can thank all the
> major browsers for that.
>
> On Tue, Dec 2, 2008 at 7:45 PM, Breno de Medeiros <breno@...>  
> wrote:
>> The 'naked domain' version of the site may not be DNS-resolvable,
>> while the www. prepended version of the domain may be. In addition,
>> the fact that a resource URL does not exist (in the sense that it
>> might return a 404) does not mean that it cannot have meaningful
>> associated meta-data.
>>
>>
>> On Tue, Dec 2, 2008 at 6:40 PM, Mark Nottingham <mnot@...>  
>> wrote:
>>>
>>> On 03/12/2008, at 1:35 PM, Breno de Medeiros wrote:
>>>
>>>> On Tue, Dec 2, 2008 at 4:24 PM, Mark Nottingham <mnot@...>  
>>>> wrote:
>>>>>
>>>>>
>>>>> On 02/12/2008, at 1:25 PM, Dirk Balfanz wrote:
>>>>>>
>>>>>> Well, here is the scenario: I buy foobar.com for $3/year at
>>>>>> cheapdomains.com. I pay an extra dollar to have "email", which  
>>>>>> means I
>>>>>> tell
>>>>>> them where I want my email forwarded. I pick dirk@... to  
>>>>>> be
>>>>>> forwarded
>>>>>> to dirk@.... I pay another extra dollar per year for "web
>>>>>> hosting",
>>>>>> which means I get a web interface on cheapdomains.com to create  
>>>>>> some web
>>>>>> pages, which get served on www.foobar.com. I set up a couple of  
>>>>>> pages
>>>>>> there
>>>>>> with pictures of my cats or whatever and I am done.
>>>>>>
>>>>>> I now also want to use my email address dirk@... as my  
>>>>>> OpenID
>>>>>> identifier [1] because I heard that that will end my having to  
>>>>>> create
>>>>>> ever-more accounts on the web. I am told that in order to get  
>>>>>> that to
>>>>>> work I
>>>>>> need to host a page called "site-meta" on my site with some
>>>>>> weird-looking
>>>>>> text in it that I don't understand. But, hey, I know how to get  
>>>>>> that
>>>>>> served
>>>>>> off www.foobar.com so that's cool.
>>>>>>
>>>>>> I have never heard of DNS.
>>>>>>
>>>>>> Is that a use case we want to support?
>>>>>>
>>>>>> Dirk.
>>>>>>
>>>>>> [1] Let's assume that OpenID 3.0 and XRD 2.0 allow that and  
>>>>>> define some
>>>>>> way to discover OpenID endpoints from email addresses.
>>>>>
>>>>> /site-meta on http://foobar.com/ doesn't (and can't, on its own)  
>>>>> make any
>>>>> authoritative assertions about mailto:dirk@...; even  
>>>>> though the
>>>>> authority is the same, the URI scheme is different.
>>>>
>>>> The email address is a distraction here. The core issue is  
>>>> independent of
>>>> that.
>>>>
>>>> vanity-example.com (hosted only at www.vanity-example.com) is a  
>>>> small
>>>> site and wants to enable all their user URLs
>>>> www.vanity-example.com/bob, www.vanity-example.com/alice to be  
>>>> useful
>>>> as discovery endpoints for user services. Thankfully some other  
>>>> site,
>>>> more professionally managed, is willing to provide discovery  
>>>> services,
>>>> aggregation, etc., on behalf of the users of these vanity domains.
>>>
>>> You just lost me. Why is it important to have site metadata for a  
>>> site that
>>> doesn't exist, if the e-mail issue is a distraction?
>>>
>>> --
>>> Mark Nottingham     http://www.mnot.net/
>>>
>>>
>>
>>
>>
>> --
>> --Breno
>>
>> [phone] desk
>> [phone] (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>>
>
>
>
> --
> --Breno
>
> [phone] desk
> [phone] (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)

--
Mark Nottingham     http://www.mnot.net/

[mnot]

Considering that one of your core use cases for this is security-
related, I'm surprised that you're effectively arguing that HTTP and  
HTTPS URLs with the same authority be collapsed into one name space.

Many standards and common practices currently sandbox policy and  
metadata to a single URL scheme + authority by default, including  
robots.txt, p3p.xml, cookie scoping, automated redirection processing  
in HTTP, cache invalidation, OPTIONS metadata, cross-site scripting  
and I'm sure quite a few more. This is the de facto standard for what  
a "Web site" is, and while there are many other colloquial meanings of  
that phrase, this is current technical practice.

Trying to establish a standard for site-wide metadata that doesn't  
follow this practice is IMO doomed to sow yet more confusion about an  
already muddled area, and potentially open up security as well as  
usability and technical problems.

That said, there's nothing to stop a particular application -- e.g.,  
OpenID -- saying that for a particular purpose, site-meta should be  
checked on a HTTP URL even though the URL presented is mailto: (for  
example), or even that www.example.com should be tried if example.com  
isn't available (although I still don't think it's necessary).

What I'm not willing to do is enshrine these things in standards that  
are supposed to help extend the Web architecture, not dilute it. The  
fact that a few $2 Web hosts don't provide adequate control to their  
customers in 2008 should not affect something so fundamental as the  
definition of what a Web site is for the next 30 years (if this  
succeeds, of course).

Cheers,


On 03/12/2008, at 6:32 PM, Eran Hammer-Lahav wrote:

>> On 02/12/2008, at 4:24 PM, Mark Nottingham wrote:
>>
>> /site-meta on http://foobar.com/ doesn't (and can't, on its own) make
>> any authoritative assertions about mailto:dirk@...; even  
>> though
>> the authority is the same, the URI scheme is different.
>>
>> I know this particular issue is an important one to the OpenID folks,
>> but there needs to be a very careful and broad discussion of allowing
>> policy and metadata from HTTP to be considered *automatically*
>> authoritative for other protocols.
>
> I do not considered /site-meta to be about HTTP resources. It is  
> metadata about the domain authority and uses HTTP as the protocol to  
> deliver that document. It can equally link to HTTP URIs as to other  
> URIs (i.e. point to its robots.txt available at an ftp:// URI). I  
> think it is safe to assume that whoever controls the domain controls  
> any URI scheme within that domain. Companies can split control  
> between departments but you go high enough there is one entity which  
> owns everything under that authority.
>
> HTTP clearly allows: 'GET mailto:eran@...', but what is  
> actually served is up to the server. In theory, that can serve a 303  
> with Link header to the XRD describing the identifier. The problem,  
> of course, is that most web servers will fail on such request, or at  
> least most platforms will not allow the developer easy access to  
> control the response to such requests. But the point is, the HTTP  
> protocol is nowhere restricted to provide information about HTTP  
> URIs alone. The fact that user-agents will use HTTP when the URI  
> scheme is HTTP and use FTP when the URI scheme is FTP is more of a  
> practical convention than a strict requirement.
>
> The issue of what constitute authoritative metadata with regard to  
> the domain authority is not something we can resolve beyond the  
> reasonable expectation that the entity that control the domain has  
> sufficient authority. Can the profile.yahoo.com admin be considered  
> the authority for my profile page? In the context of discovery, I  
> believe the answer is yes. Philosophically, I can argue that only  
> the profile owner has the authority to control that page, but such  
> control in today's infrastructure, is eventually enforced by the  
> domain admin anyway.
>
> EHL

--
Mark Nottingham     http://www.mnot.net/

[Ben Laurie-3]

On Wed, Dec 3, 2008 at 12:24 AM, Mark Nottingham <mnot@...> wrote:
> /site-meta on http://foobar.com/ doesn't (and can't, on its own) make any
> authoritative assertions about mailto:dirk@...; even though the
> authority is the same, the URI scheme is different.

That seems like a very strong assertion to make. There's no obvious
reason why this is so. DNS, for example, makes many authoritative
assertions about all sorts of things without being the same protocol.

> I know this particular issue is an important one to the OpenID folks, but
> there needs to be a very careful and broad discussion of allowing policy and
> metadata from HTTP to be considered *automatically* authoritative for other
> protocols.

I hadn't thought about it in these terms before, so thanks for the
nudge. Whoever controls DNS for a domain also controls how all schemes
are handled, in practice. Therefore, it seems to me, it should be
possible to declare via DNS that HTTP is authoritative (or not) for a
particular scheme. If DNS makes no statement, then I would argue that
it is reasonable to use defaults instead, such as falling back to
www.foobar.com if foobar.com doesn't work.

Cheers,

Ben.

[Ben Laurie-3]

On Wed, Dec 3, 2008 at 10:38 AM, Mark Nottingham <mnot@...> wrote:
>
> Considering that one of your core use cases for this is security-related,
> I'm surprised that you're effectively arguing that HTTP and HTTPS URLs with
> the same authority be collapsed into one name space.
>
> Many standards and common practices currently sandbox policy and metadata to
> a single URL scheme + authority by default, including robots.txt, p3p.xml,
> cookie scoping,

Surely cookies are scoped to HTTP and HTTPS by default.

> automated redirection processing in HTTP,

I don't know what this is.

> cache invalidation, OPTIONS metadata, cross-site scripting

There are standards for XSS???

> and I'm sure quite a
> few more. This is the de facto standard for what a "Web site" is, and while
> there are many other colloquial meanings of that phrase, this is current
> technical practice.
>
> Trying to establish a standard for site-wide metadata that doesn't follow
> this practice is IMO doomed to sow yet more confusion about an already
> muddled area, and potentially open up security as well as usability and
> technical problems.
>
> That said, there's nothing to stop a particular application -- e.g., OpenID
> -- saying that for a particular purpose, site-meta should be checked on a
> HTTP URL even though the URL presented is mailto: (for example), or even
> that www.example.com should be tried if example.com isn't available
> (although I still don't think it's necessary).
>
> What I'm not willing to do is enshrine these things in standards that are
> supposed to help extend the Web architecture, not dilute it. The fact that a
> few $2 Web hosts don't provide adequate control to their customers in 2008
> should not affect something so fundamental as the definition of what a Web
> site is for the next 30 years (if this succeeds, of course).
>
> Cheers,
>
>
> On 03/12/2008, at 6:32 PM, Eran Hammer-Lahav wrote:
>
>>> On 02/12/2008, at 4:24 PM, Mark Nottingham wrote:
>>>
>>> /site-meta on http://foobar.com/ doesn't (and can't, on its own) make
>>> any authoritative assertions about mailto:dirk@...; even though
>>> the authority is the same, the URI scheme is different.
>>>
>>> I know this particular issue is an important one to the OpenID folks,
>>> but there needs to be a very careful and broad discussion of allowing
>>> policy and metadata from HTTP to be considered *automatically*
>>> authoritative for other protocols.
>>
>> I do not considered /site-meta to be about HTTP resources. It is metadata
>> about the domain authority and uses HTTP as the protocol to deliver that
>> document. It can equally link to HTTP URIs as to other URIs (i.e. point to
>> its robots.txt available at an ftp:// URI). I think it is safe to assume
>> that whoever controls the domain controls any URI scheme within that domain.
>> Companies can split control between departments but you go high enough there
>> is one entity which owns everything under that authority.
>>
>> HTTP clearly allows: 'GET mailto:eran@...', but what is actually
>> served is up to the server. In theory, that can serve a 303 with Link header
>> to the XRD describing the identifier. The problem, of course, is that most
>> web servers will fail on such request, or at least most platforms will not
>> allow the developer easy access to control the response to such requests.
>> But the point is, the HTTP protocol is nowhere restricted to provide
>> information about HTTP URIs alone. The fact that user-agents will use HTTP
>> when the URI scheme is HTTP and use FTP when the URI scheme is FTP is more
>> of a practical convention than a strict requirement.
>>
>> The issue of what constitute authoritative metadata with regard to the
>> domain authority is not something we can resolve beyond the reasonable
>> expectation that the entity that control the domain has sufficient
>> authority. Can the profile.yahoo.com admin be considered the authority for
>> my profile page? In the context of discovery, I believe the answer is yes.
>> Philosophically, I can argue that only the profile owner has the authority
>> to control that page, but such control in today's infrastructure, is
>> eventually enforced by the domain admin anyway.
>>
>> EHL
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>
>

[mnot]

On 03/12/2008, at 11:32 PM, Ben Laurie wrote:

> On Wed, Dec 3, 2008 at 10:38 AM, Mark Nottingham <mnot@...>  
> wrote:
>>
>> Considering that one of your core use cases for this is security-
>> related,
>> I'm surprised that you're effectively arguing that HTTP and HTTPS  
>> URLs with
>> the same authority be collapsed into one name space.
>>
>> Many standards and common practices currently sandbox policy and  
>> metadata to
>> a single URL scheme + authority by default, including robots.txt,  
>> p3p.xml,
>> cookie scoping,
>
> Surely cookies are scoped to HTTP and HTTPS by default.

It depends on who you talk to; we don't really have a spec for cookies  
that reflects reality, and there are subtle differences in the  
implementations. RFC2109 says
> The user agent keeps separate track of state information that  
> arrives via Set-Cookie response headers from each origin server (as  
> distinguished by name or IP address and port).

... but goes on to contradict that later one.

Authentication is a better example.

>> automated redirection processing in HTTP,
>
> I don't know what this is.

Argh - sorry, confused a proposal discussed recently with specified  
behaviour. Never mind.


>> cache invalidation, OPTIONS metadata, cross-site scripting
>
> There are standards for XSS???

There's a de facto standard in the browsers (same origin), and these  
folks are working towards something more formal, maybe;
   http://www.w3.org/2006/WSC/

--
Mark Nottingham     http://www.mnot.net/

[Ben Laurie-3]

On Wed, Dec 3, 2008 at 12:58 PM, Mark Nottingham <mnot@...> wrote:
> On 03/12/2008, at 11:32 PM, Ben Laurie wrote:
>> There are standards for XSS???
>
> There's a de facto standard in the browsers (same origin), and these folks
> are working towards something more formal, maybe;
>  http://www.w3.org/2006/WSC/

Same origin policy isn't really all that much to do with cross-site
scripting, surely?

[Breno de Medeiros]

There is a bit too much emphasis put on the word 'authoritative' here.
There is so much that can be considered authoritative about an
unsigned document, even if served through HTTPS. Serving a document
over HTTPS just requires defacing a web site, something not that hard
to do considering the great variety of vulnerable server software out
there.

When we start talking about signing such documents, and where the
trust is coming from, then maybe the word authoritative will take a
real-world significance.
However, from what I have been hearing, the current proposal does not
plan for signing of site-meta, and the links pointed to by it will
have to carry implicit trust (maybe they will be signed documents, or
maybe they are just informative).

It is probably better to think of site-meta as a 'hint' of where to
find things. Which, come to think of it, in these days of readily
spoofable DNS resolution, it also the only level of assurance that DNS
provides. As Ben pointed out, DNS is happy to be authoritative over
pretty much anything and provide assurance about nothing.


On Wed, Dec 3, 2008 at 7:40 AM, Ben Laurie <benl@...> wrote:

>
> On Wed, Dec 3, 2008 at 12:58 PM, Mark Nottingham <mnot@...> wrote:
>> On 03/12/2008, at 11:32 PM, Ben Laurie wrote:
>>> There are standards for XSS???
>>
>> There's a de facto standard in the browsers (same origin), and these folks
>> are working towards something more formal, maybe;
>>  http://www.w3.org/2006/WSC/
>
> Same origin policy isn't really all that much to do with cross-site
> scripting, surely?
>
>

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

[Ben Laurie-3]

On Wed, Dec 3, 2008 at 5:32 PM, Breno de Medeiros <breno@...> wrote:

> There is a bit too much emphasis put on the word 'authoritative' here.
> There is so much that can be considered authoritative about an
> unsigned document, even if served through HTTPS. Serving a document
> over HTTPS just requires defacing a web site, something not that hard
> to do considering the great variety of vulnerable server software out
> there.
>
> When we start talking about signing such documents, and where the
> trust is coming from, then maybe the word authoritative will take a
> real-world significance.
> However, from what I have been hearing, the current proposal does not
> plan for signing of site-meta,

That seems a shame.

> and the links pointed to by it will
> have to carry implicit trust (maybe they will be signed documents, or
> maybe they are just informative).
>
> It is probably better to think of site-meta as a 'hint' of where to
> find things. Which, come to think of it, in these days of readily
> spoofable DNS resolution, it also the only level of assurance that DNS
> provides. As Ben pointed out, DNS is happy to be authoritative over
> pretty much anything and provide assurance about nothing.

To be fair, this is why DNSSEC exists.

[Breno de Medeiros]

On Wed, Dec 3, 2008 at 9:38 AM, Eran Hammer-Lahav <eran@...> wrote:

> -----Original Message-----
>> From: Breno de Medeiros [mailto:breno@...]
>> Sent: Wednesday, December 03, 2008 9:33 AM
>>
>> However, from what I have been hearing, the current proposal does not
>> plan for signing of site-meta, and the links pointed to by it will
>> have to carry implicit trust (maybe they will be signed documents, or
>> maybe they are just informative).
>
> /site-meta will certainly support signatures, the open question is where to specify that mechanism. I think this will get resolved in the larger context of what building blocks we end up using
> for the end-to-end discovery protocol. We are arguing about what functionality belongs in which spec, not if the functionality itself is needed.

This is not completely apparent from the way the pieces are being
discussed in different settings. If site-meta is to support
signatures, then how the signature fits in probably should live on the
site-meta spec (even if it points to a signature scheme defined
elsewhere, or leaves the actual signature mechanism unspecified).


>
> EHL
>



--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)