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


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]