RE: [xri] XRD Examples

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

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Thursday, June 25, 2009 1:46 PM
> To: XRI TC
> Subject: Re: [xri] XRD Examples
> 
> 
> On Jun 25, 2009, at 1:03 PM, Eran Hammer-Lahav wrote:
> > 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.
> 
> This has actually been a problem with Identifier Select in OpenID 2.x,
> where the identifier is not actually known until you're done with the
> authentication flow.  Did you see Nat's post on this?[0]  This may not
> actually change things, but I believe more weight actually does need
> to be given to the actual Subject value of the XRD.
> 
> [0]: http://www.sakimura.org/en/modules/wordpress/index.php?p=82

Yes, but in an application specific manner.

> On Jun 25, 2009, at 1:13 PM, Eran Hammer-Lahav wrote:
> 
> > Both trust elements provide narrowing of the authority scope. This
> > is needed because subjects and authorities can change during the
> > discovery process or via delegation. Google can use a single
> > certificate to sign all their XRDs which means without the ability
> > to be explicit about what subject to expect on the other side, an
> > attacker can manipulate the reply and issue a 307 to someone else's
> > (perfectly valid and signed) XRD hosted by Google (which is likely
> > to be their own legitimate but customized XRD).
> >
> > TargetAuthority allows an XRD to be signed by something other than
> > the authority of the XRD subject. TargetSubject allows an XRD to
> > spell out what XRD it deems trusted following a link.
> 
> After reading both yours and Drummond's reply to this, I absolutely
> agree (again, *sigh*) that there is a use case that necessitates
> TargetSubject.  But given the above question regarding the value of
> Subject, I'm not exactly sure what the "inherited" or default value of
> TargetSubject should be.

It defaults to the Link's <URI> (the one used if more than one is present).

> I am still not convinced we need the TargetAuthority element.  I agree
> we need something to address the need that TargetAuthority was
> intended for, but I don't think we need a new element.  The intention
> of TargetAuthority is to somehow identify the authority that the
> target XRD should be issued from (though not necessarily hosted by).
> How is that authority identified?  It's not identified by an XRI as it
> was in XRI Resolution, because we don't have any of those elements
> anymore.  The only thing we have is what is included in the
> ds:Signature, right?  If that's the case, then the only thing inside
> of the <Link> is a <ds:KeyInfo>.. adding a new element is just
> duplicating what KeyInfo does.

The problem with TargetAuthority is that is makes the target XRD impossible to validate without obtaining it through the Link first. All the other elements are contained in the same document which you can pass to a parser in a self contained manner. Even TargetSubject works this way because you get an XRD and just make sure it has the right Subject, but you validate the Subject using the information contained in the Target XRD alone.

If the TargetAuthority is different from that of the target Subject, that XRD cannot be validated without the information in the Link that says it is ok for them to be different.

I agree this is not an ideal solution but the need is pretty clear in terms of deployment. Maybe we should think about this one harder.

EHL