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


I agree that yes, TargetSubject should "inherit" from URI if it's not there (and yes, in the case of URITemplate the final derived value should be used).

But it sounds a bit strange to me to say that TargetAuthority inherits from TargetSubject (or URI). Maybe it would be more accurate to say that TargetAuthority inherits just from the authority portion of the TargetSubject (or URI). Or maybe it shouldn't inherit from those at all and it should always be required if you want trust.

Also I now feel just a little bit funny about having TargetSubject in the trust: namespace. Yes, it's used for trust verification, but it also has a certain meaning beyond that. Well that's alright I guess.

Markus

On Fri, May 22, 2009 at 10:30 PM, Will Norris <will@willnorris.com> wrote:

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



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