RE: [xri] XRD Examples

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

-- Single user delegating to an OpenID Provider with one layer of indirection:

<XRD> 
    <Subject>http://mycompany.biz/joe</Subject>
    <ds:Signature>
        <ds:KeyName>mycompany.biz</ds:KeyName>
    </ds:Signature>
    <Link>
        <Rel>http://specs.openid.net/role/provider</Rel>
        <URI>http://example.com/openid/provider</URI>
        <trust:TargetAuthority>example.com</trust:TargetAuthority>
        <openid:Delegate>http://joe.example.com/</openid:Delegate>
    </Link>
</XRD>

There is no need to use <trust:TargetAuthority> because it is inherited from the Link's URI. You only need it if the domain of the URI is different, or you expect it to change or redirect (but keeping the authority fixed). So to keep the example as is requires some explanation about potential redirections.

It is not true this is application specific but it is deployment specific. Because we only care about the final document received in each step, ignoring the presence (in terms of trust) of redirections and other such hops, we need to make sure the link URI can be verified in the final document. <trust:TargetAuthority> lets you anchor the authority of the final document regardless of the change in URI and subjects along the way.

-- Single user delegating their XRD hosting to an external party:

First, this is very different from <Ref> or <Redirect> which included a 'stop processing this document and ignore the rest of it' directive to a large degree. XRD does not have such an override function, unless you define a new relation type that means that. All we have today is the ability to link to another XRD with the same relation used to get this XRD from the resource itself.

If an XRD includes nothing else but a 'describedby' link, it translate into a blanket delegation to another XRD. But if it includes other links, without any additional application specific restrictions, it is the combination of links from both documents that are available to the client to pursue based on its needs.

There is still a problem with this approach if the intention is to delegate the entire XRD elsewhere for a single resource. The problem is that LRDD is not limited in any way to just 'describedby'. This means applications can indicate that a client needs to look for other link relations to find the appropriate XRD in addition or instead of 'describedby'. When put in this context, the links inside the XRD might not pass the same filter as required by the application.

I am not sold yet on the need for a single XRD delegation feature, but if we demonstrate a clear need for it, we should consider an element such as <Redirect> or <Delegate> to accomplish such a 'stop and go elsewhere' meaning. <Link> just doesn't provide it.

Second, I am not sure why you use a <URITemplate> here when there is clearly only one subject.

Regarding your open question of what the subject of the second XRD should be, both are correct. It is a question of how the application uses this information beyond what XRD defines. XRD does not define persistent identifiers or identity. It simply states what resource it describes. If discovery begins with one resource URI and ends with either another resource URI (via 3xx) or another subject, it is up to the application to define what that may mean.

We should keep our definition and handling of these cases as simple and minimal as possible. This is something for OpenID to address. Also keep in mind that XRD should be authored with specific use cases in mind. I know we all like to think about a single all-powerful XRD document but the reality is that it is such a generic container and requires applications to give it more depth and meaning. Since applications are likely to have conflicting meanings, they should each use a separate XRD linked to the same resource. This is where LRDD needs to improve to define ways to easily pick a descriptor from multiple options.

-- Delegating an entire domain

This is pretty simple. Using the new host-meta XRD form, we simply include a <Link> with a <URITemplate> that tells you where to find XRDs for each URI under the same host. The only tricky part here is how to apply this to the other two LRDD methods (Link: header and <LINK> element). They can either point to a local XRD which will in turn redirect to the same place the template points to, or they can include a local XRD with a link (same as individual XRD delegation).

-- Regarding <TargetSubject>

<TargetSubject> is needed when the authority is just not narrow enough to limit an attacker replacing, say, my Google hosted XRD for my company with that of another company. Since both would be signed with the same authority, but might also include a Google namespaced subject for my resource (see your open question at the end of 'Single user delegating their XRD hosting to an external party' which clearly indicates the subject of the XRD may not be the same as that of the delegating resource).

EHL



> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Monday, June 15, 2009 2:11 PM
> To: XRI TC
> Subject: [xri] XRD Examples
> 
> So I finally sat down and sketched out a number of example XRDs that
> demonstrate the major use cases I could identify.  A few major
> takeaways:
> 
>   - I've modified the "delegate an entire domain" flow a bit from
> Dirk's example he presented at IIW9... I'm really curious to see if
> this flow will work for what Google wants to do.
> 
>   - I've proposed dropping the <TargetSubject> element
> 
> It's a bit long, but should definitely be read in order, as most
> sections build on previous ones:
>    http://wiki.oasis-open.org/xri/XrdOne/XRDExamples
> 
> -will
> 
> ---------------------------------------------------------------------
> 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