OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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.

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.

-will





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]