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

That also what I took from this conversation.

On Wed, Dec 3, 2008 at 10:13 AM, Dirk Balfanz <balfanz@google.com> wrote:
> 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)
>>
>
>



-- 
--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 18:17:04 UTC