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

(It seems like the mailing list is dropping all my emails sent from my
hueniverse.com account, which means only about 4-5 of you have seen my side
of the conversation for the past few days. I am working to correct this.
This is an attempt to recover some of those lost conversations)

> 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.

> 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@foobar.com; 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@example.com', 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