XRD Signing and Trust

[Will Norris <will@willnorris.com>]

So to try and recap what was discussed yesterday with respect to  
signing and trust...

## Trust ##

Eran managed to convince everyone that we did in fact need to add an  
additional element under <Link> that would represent the authority  
that signed the XRD document of the related resource.  Especially in  
Google's case, this could be different than the <Subject> of the  
resource, so it necessitates a new element.  We agreed on  
<TargetAuthority> for this new element to coincide with  
<TargetSubject>.  This is the same as <NextAuthority> in Google's XRDS  
example.

There was also a desire to designate these two elements as being used  
for the purposes of trust, both to alert consuming applications that  
they can ignore them if they don't care about trust, but also to  
dissuade publishers from abusing them by shoving other stuff into  
them.  We considered nesting the two elements beneath a <Trust>  
element, but didn't like adding the extra layer.  Instead, we agreed  
to move these two elements to a separate XRD Trust namespace.  So you  
would end up with a Link element looking like...

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

If TargetAuthority is not defined, the value of TargetSubject is used  
for authority verification.  If TargetSubject is not defined, the URI  
value is used as both the TargetSubject and TargetAuthority.  The  
current XRD working draft has been updated to include these new  
elements, though I still need to write out this inheritance stuff.


## Signing ##

We spent quite a bit of time talking about different ways to return a  
signed XRD.  There were already two proposed solutions on the table:  
including a <SignatureLocation> element in the XRD which contains the  
URL of a resource whose content is the signature of the XRD, and  
including the Signature in an HTTP header.  Everyone liked the ability  
to include the signature and XRD in a single payload, but there were  
concerns about using an HTTP Header.  The concerns were both  
philosophical (binding the signature delivery to a specific transport  
protocol) as well as practical (not being able to distribute a pre- 
signed static file out to file servers which can be served as-is).

This led to a new proposal for delivery of a signed XRD -- an x-www- 
form-urlencoded response body which contains two parameters.   
'signature' which is the base64-encoded and url-encoded signature, and  
'xrd' which is the base64-encoded and url-encoded string whose value  
is the XRD document.  This is the same approach OAuth takes for  
responding to token requests and is very similar to SAML SimpleSign,  
except that it is in the response instead of the request.  Advantages  
of this approach -- everything can be included in the message body,  
making it transport agnostic and easy to distribute among many web  
servers in large deployments.  Disadvantages -- it's a bit more  
difficult for developers to debug, since they can't read the XRD on  
the wire... they'd need to manually base64-decode it.

To prevent confusion if multiple signing methods are used (ie. x-www- 
form-urlencoded body AND a Signature header), we decided to make the  
<SignatureLocation> element required (but still single-valued).  We  
will define two special URIs which instruct consuming applications to  
retrieve the signature from the HTTP Header or the message body,  
respectively.

There was also talk of a wrapper element for XRD which could contain  
the signature and data in XML:
<SignedXRD>
   <Signature /> (Required, Signature value)
   <Data /> (Required, base64 encoded XRD)
</SignedXRD>

This will be particularly useful for XRDS, which is still necessary  
for XRI resolution.  But because it would change the root element (and  
therefore the schema, content type, etc), we opted NOT to include this  
format in the XRD spec itself.  With the x-www-form-urlencoded  
approach, it's really just another transport binding(?) with no  
changes to the schema at all.


## Feedback ##

Thoughts on any of this?  For people that were at the face to face  
yesterday, did I miss anything?  For those that weren't, does this  
make sense?  Particularly from Google folks, what do you think of this  
new method for delivering signed XRDs?  Would this obviate the need  
for the signature HTTP header, or is there still value in having both  
methods available to XRD publishers?

-will