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

Ok, I think the discussion has derailed a little bit.

The question at hand was whether we should have a fallback flow for
site-meta on naked domains.

The rationale behind this seemed to come largely (only?) from an OpenID use
case, where the user-supplied identifier mentions only the naked domain "
domain.com", but the site-meta document is served off www.domain.com.

The reason only the naked domain is in the user-supplied identifier could be
because it was derived from an email address, or because the user was lazy
when typing their OpenID URL, or doesn't know the difference and uses the
naked/full domains interchangeably (did I miss other reasons?).

The reason the site-meta document is served off www.domain.com instead of
domain.com is because the owner of that domain is not technically savvy
enough to understand the difference/move to a provider that allows him to
serve something off the naked domain, etc.

There was an objection that site-meta (which is served over http) should not
be authoritative for email: URI schemes, but I think that was voted down :-)


There was also a class of objections that - if I can paraphrase them -
basically said that users _will_ be able to serve site-meta off the naked
domains, b/c if that's what's needed to make important use cases work,
godaddy.com and its ilk will make that easy to do even for amateurs.

Seems to me that although the last objection is somewhat speculative, if
there are no other use cases for this than OpenID, maybe the OpenID
discovery spec is where the fallback flow belongs?

Dirk.


On Wed, Dec 3, 2008 at 9:45 AM, Breno de Medeiros <breno@google.com> wrote:

>
> On Wed, Dec 3, 2008 at 9:38 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> > -----Original Message-----
> >> From: Breno de Medeiros [mailto:breno@google.com]
> >> 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
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>
>