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 Signing and Trust




On Fri, May 22, 2009 at 12:07 PM, Will Norris <will@willnorris.com> wrote:
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 ##

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

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

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.

Dirk.
 

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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