Re: [xri] XRD Signing and Trust

[Will Norris <will@willnorris.com>]

On May 22, 2009, at 1:21 PM, Dirk Balfanz wrote:

> On Fri, May 22, 2009 at 1:10 PM, Will Norris <will@willnorris.com>  
> 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.
>>
>
> Ah, ok - I see (the mydomain.com == balfanz.net ==
> my-hosted-domain.comexplanation was helpful, though :-)
>
> From reading the summary it sounded like you can have a TargetSubject
> without a TargetAuthority, but not the other way round. Is that  
> true? I
> think in our use case, we need a TargetAuthority, but can't put
> TargetSubject in the XRD, because it's essentially whatevert the  
> {%uri} is.


well, the way we talked about it yesterday, both elements would be  
optional, and if absent would be inherited by the value of other  
elements.

  - If TargetSubject is absent, its value is inherited from URI.  In  
the case of URITemplate, I guess it would be the final URI derived  
from the template?  We didn't actually discuss that, so we'd need to  
figure that out.
  - If TargetAuthority is absent, its value is inherited from  
TargetSubject (which then follows the above rule, if absent).

This certainly does create a problem in your case, because then the  
inherited value of TargetSubject would not match the Subject of the  
next XRD.  I'll have to think about this for a bit.

-will