XRD: Separating resource descriptions from authority

[Eran Hammer-Lahav <eran@hueniverse.com>]

- Should we continue to support XRD/Service/Type (well, XRD/Link/Type)?
There are useful use cases for providing discovery hints beyond media types,
and we already have this widely deployed (more than any other feature) in
XRDS. The first problem with this is the name, which will have to change
since 'type' means media type in Link header and element. Is <Attribute> any
better? <ResourceType>?

This brings up a following questions:

* if we change the element name at the Link level, should we also change it
at the <XRD> level?

* the XRD level <Type> has a new 'required' attribute which is used to warn
applications not to interact with the resource if they do not understand a
certain Type declaration. If we support a 'type' element at the Link level,
should it also support this attribute? It can be very useful but the
semantics are getting nuts here... A "required" attribute on a "hint"
element...
The CanonicalID seems to be used exclusively for trust, which makes me
wonder if we shouldn't add a separate trust element that is about the XRD
and not about the resource. One such idea looks like this:

<XRD>
    <Expires>2009-01-01T08:30:00Z</Expires>
    <About>http://example.com/resource/1</About>
    <Type>http://example.com/type/profile_photo</Type>

    <Authority>
        <Identifier />
        <Signature>
            <Base64 />
        </Signature>
    </Authority>

    <Link>
        <URI>http://example.com/resource/2</URI>
        <Rel>http://example.com/rel/profile</Rel>
    </Link>
</XRD>

Where an authority element is introduced which identifies who is making the
claims in the XRD and its certificate (or link) and the entire content of
the XRD (without any Authority elements) in Base64 and its signature. This
allows multiple signatures if an XRD is claimed to have multiple
authorities.

This way a document at google.com can describe a resource from example.com
and include both signatures, or only one. And the consumer can look for a
matching domain authority as the <About> resource(s) or for the URI that
started the whole XRD discovery flow (which might not even be listed in an
<About> element).

For OpenID purposes, the existing use case of CanonicalID needs to be better
defined and resolved.

This is all very initial but something on my mind.

EHL