Markus,
These are all good issues that I’d
like to see covered on our call tomorrow. XRD signatures is the first agenda
item and may well take up the whole call.
=Drummond
From:
markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Sunday, May 24, 2009 4:00 PM
To: XRI TC
Subject: Re: [xri] XRD Signing and
Trust
Just wanted to note that
in some applications (e.g. XRI resolution, but maybe in others as well), the
XRD can be very dynamic (e.g. the <Expires> element can be different with
every single request). Therefore it seems impractical to have the signature
(which would be dynamic as well) at a different location than the XRD itself.
I forgot, why exactly aren't we using <SignedXRD> for all situations? I
like this better than the <SignatureLocation>, the signature header and
the x-www-form-urlencoded approaches. Is anything wrong with having two schemas
and two mime types (one for XRD, one for SignedXRD) ?
Markus
On Fri, May 22, 2009 at 9: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 ##
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
|