Re: [xri] XRD: Separating resource descriptions from authority

[Dirk Balfanz <balfanz@google.com>]

On Mon, Jan 26, 2009 at 5:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> - 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>?

I like 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?

No, because at the link level it describes a relationship to _that_
endpoint over there, e.g. "that is my OpenID provider over there". At
the XRD level, it describes properties of the resource at hand, e.g.,
"this OpenID provider supports PAPE". These feel different to me.

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

I'd vote for not putting it at the link level, but that's just a gut feeling.

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

To be honest, I'm not quite sure what the difference of <About> and
<CanonicalID> is, but then I've only thought about this in the context
of OpenID discovery. If you give us <About>, I don't think we need
<CanonicalID>, at least not for OpenID discovery :-)

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

Yeah, something like that. I think Brian will send out a proposal soon
(for the authority/signature section) that looks a lot like this,
perhaps a little simpler.

Dirk.


> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>