Re: [xri] XRD Signing and Trust

[Will Norris <will@willnorris.com>]

On May 22, 2009, at 1:10 PM, Will Norris wrote:

>
> 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.

wow, screwed up the domain names pretty bad there as well :)   
mydomain.com == balfanz.net == my-hosted-domain.com