Re: Fallback flow for /site-meta for top level domains

On Tue, Dec 2, 2008 at 4:24 PM, Mark Nottingham <mnot@mnot.net> 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@foobar.com to be forwarded
>> to dirk@gmail.com. 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@foobar.com 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@foobar.com; 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

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

Received on Wednesday, 3 December 2008 02:35:40 UTC