[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] XRD Signing and Trust
You apply the template and end up with a URI. From there all the rules are the same. EHL > -----Original Message----- > From: Will Norris [mailto:will@willnorris.com] > Sent: Friday, May 22, 2009 1:31 PM > To: XRI TC > Subject: Re: [xri] XRD Signing and Trust > > > 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]