Re: [xri] XRD Signing and Trust

[Will Norris <will@willnorris.com>]

On May 22, 2009, at 12:33 PM, Dirk Balfanz wrote:
>
> Guys - this looks good. I have a couple of questions.
>
> I understand the concerns about the signature-in-a-header. I don't  
> have a
> response to the philosophical concerns, but the distribution of pre- 
> signed
> files is actually covered by Brian's original
> proposal<http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile>.
> There, you could link to the signature through another URL. So you  
> could
> pre-sign and distribute, although it would be two files instead of  
> one.

well exactly, it would be two requests.  The idea with this method was  
to include the data and the signature in a single payload body.


> How would this form-encoded delivery work? If a client tries to  
> fetch an
> XRD, and the server doesn't sign the XRD, would they still just send  
> back
> the XRD as application/xrd+xml? But if they _do_ sign it, then they  
> would
> set Content-Type to application/x-www-form-urlencoded? So the client  
> would
> have to fork based on the Content-Type sent back by the server? I  
> guess
> that's doable. But if you keep the header as an option I don't  
> really care
> :-)

yep, that would be the idea... the consuming application would use the  
content-type as an indicator of how to parse the response.


> Finally, what's the TargetSubject for? In this example:
>
> <Link>
> <Rel>http://www.iana.org/assignments/relation/describedby</Rel>
> <MediaType>application/xrd+xml</MediaType>
> <URITemplate>https://www.google.com/accounts/o8/user-xrds
> ?uri={%uri}</URITemplate>
> <trust:TargetSubject>http://my-hosted-domain.com</trust:TargetSubject>
> <trust:TargetAuthority>hosted-id.google.com</trust:TargetAuthority>
> </Link>
>
> presumably, a client performing OpenID discovery or some such thing  
> would
> plug the OpenID they're performing discovery on (let's say
> http://my-hosted-domain.com/openid/bob) into the URI template, and  
> then
> fetch the XRD for that OpenID from the URL that falls out of the  
> template.
> The subject of that XRD must be the OpenID that we're performing  
> discovery
> on (http://my-hosted-domain.com/openid/bob), not "
> http://my-hosted-domain.com";. So I'm not sure what TargetSubject is  
> for.
> TargetAuthority, on the other hand, is useful in this case: Bob's  
> XRD can be
> signed by hosted-id.google.com.

yeah, that was actually a bad example, because it's delegating the  
user's XRD, not a specific service.  Imagine I hosted my own XRD, but  
still wanted to delegate to Google as my OpenID Provider...

<Link>
   <Rel>http://example.com/openid/provider</Rel>
   <URI>https://www.google.com/a/mydomain.com/openid</URI>
   <trust:TargetSubject>http://mydomain.com</trust:TargetSubject>
   <trust:TargetAuthority>hosted-id.google.com</trust:TargetAuthority>
</Link>

In this example, https://www.google.com/a/balfanz.net/openid would  
provide an XRD which describes the specific OpenID endpoints and  
supported extensions at Google.  This is not an XRD for any particular  
user, but rather describes OpenID services for that hosted domain, so  
the subject would be "http://my-hosted-domain.com";.  Perhaps it would  
be in a broader site-meta XRD that includes more than just OpenID  
services, I don't know.  As long as it had a Type value of "http://example.com/openid/provider 
", it wouldn't really matter.