RE: [xri] XRD delegated identifer element (was part of: questions about LRDD / OpenID)

["Drummond Reed" <drummond.reed@cordance.net>]

Responses inline to two questions Will raised:

> -----Original Message-----
> Will Norris [mailto:will@willnorris.com]
> Can someone remind me what the use case is for #1 (including the
> canonical URI for the link target resource).  I want to say it has to
> do with one of the trust or signing profiles, but am not 100% sure.
> If that's right, then I absolutely believe we need to be thinking
> about it.  No, it's not in OpenID 2.0, but 1) OpenID isn't the only
> use-case we're thinking about and 2) I'm sure that as OpenID is used
> in more high-risk transactions (PayPal joined the OpenID board, after
> all) it's absolutely going to be something they will want.  If that
> element isn't about trust, then just ignore me :)

You're right on, Will, it's about trust. It's correct to say that, "It's not
in OpenID 2.0", but it absolutely was part of XRI 2.0 (specifically XRI
Resolution 2.0). The basic use case is that it allows the owner of the
resource to which the XRD is linked (for example, an OpenID service
provider) to use a canonical identifier (what SAML calls a "logical
identifier") to identify itself, because the URLs that it uses to identify
specific service endpoints may change over time. In XRI land this canonical
identifier is typically an XRI i-number that is never reassigned.

This same use case is used heavily by XDI data sharing relationships, so the
requirement to include it is quite a strong one.

For cross-thread correlation, this element is the one I proposed to call
<XRD:Link:Object> until a better suggestion comes along.

> > As for (2), I would think that an OP-local identifier is an
> > OpenID-specific thing that XRD doesn't/shouldn't worry about. It could
> > be one of those extensions that Eran has been blogging about:
> > http://www.hueniverse.com/hueniverse/2009/03/the-xrd-extensibility-
> model.html
> > .
> >
> > So I'd think it would look something like this:
> >
> > <XRD xmlns:openid="http://specs.openid.net/...";>
> >  <Subject>http://claimed-id-of-the-user</Subject>
> >  <Link>
> >    <Rel>http://something-designating-openid-endpoint</Rel>
> >    <URI>http://location-of-op-endpoint</URI>
> >    <openid:LocalID>http://local-id-of-user-at-op</openid:LocalID>
> >  </Link>
> > </XRD>
> 
> well if you call it a "OP-local identifier" then it certainly sounds
> like something specific to OpenID.  But what about my photo sharing
> service?  Flickr doesn't know me by my OpenID, I have a different
> identifier there.  I would argue that the same is true for the vast
> majority of services today which one might want to list in their
> XRD... most of those services have their own identifier of some sorts
> for users.  This was part of XRDS, after all, so I'm sure Drummond or
> John could probably give a clearer reason for why its there.

Actually, Will, I think you summarized the reasons pretty well. But I'll
take that summary one step further: today, context-specific identifiers
(CSIDs) are the norm. They also have certain privacy benefits. So the goal
of XRD should not be to get rid of CSIDs, but to provide a way for them to
be mapped when necessary -- mapped either to other CSIDs, or to global IDs,
depending on what the user and/or the consuming application requires. This
proposed element is the way to do that mapping consistently and
interoperably across all XRD-consuming applications.

For cross-thread correlation, this element is the one I proposed to call
<XRD:Link:RelativeSubject> until a better suggestion comes along.

=Drummond