Re: [xri] XRD Signing and Trust

On Fri, May 22, 2009 at 10: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.

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

xri message