Re: [xri] trust profiles for XRD

[George Fletcher <george.fletcher@corp.aol.com>]

Just to make sure I understand... the <ProviderID> element is only 
needed if the resource URL != the CanonicalID in the deployment scheme 
(meaning in most cases that the CanonicalID is not a URL).  Otherwise, 
wouldn't normal delegation work for the OpenID RP outsourcing case?

As an aside, I think OpenID 2.x needs to specify a way for the realm 
(aka trust root) presented to the user to be different from the 
return_to URL as long as the trusted delegation path is valid.

--

OpenID RP site http://openidrp.example.com want to outsource it's OpenID 
RP logic to http://rpsaas.example.biz.

XRD for http://openidrp.example.com (or could be in /site-meta if 
/site-meta is signed)

<XRD>
     <CanonicalID>http://openidrp.example.com</CanonicalID>
     <Service priority="0">
        <Type>http://specs.openid.net/auth/2.0/rp</Type>
        <URI>https://rpsaas.example.biz/openidrp</URI>
     </Service>
     <Signature ...>
     </Signature>
</XRD>

XRD for https://rpsaas.example.biz

<XRD>
     <CanonicalID>https://rpsaas.example.biz/openidrp</CanonicalID>
     <Service priority="0">
        <Type>http://specs.openid.net/auth/2.0/return_to</Type>
        <URI>https://rpsaas.example.biz/openidrp</URI>
     </Service>
     <Signature ...>
     </Signature>
</XRD>

Trust root discovery would follow the XRD "chain" to find the resource 
with the "http://specs.openid.net/auth/2.0/return_to"; "Service". If that 
resource matches the return_to URL then this is trusted delegation of 
OpenID RP functionality.

Thanks,
George


Nat Sakimura wrote:
>
> Thanks Brian for the write up.
>
> I have added comments to the wiki.
>
> Basically, it is kind of unfortunate, in addition to what George has
> pointed out, if we consider the case of domain owner change into the
> scope, it breaks.
>
> For the OpenID RP outsourcing, there can be two alternatives, IMHO.
>
> Method 1:
> Write <ProviderID> in the outsourcing party's XRD/Service element. The
> XRD itself is signed, so it is authoritative.
> Then OP can go fetch the XRD of the outsourced party from the endpoint
> described in the outsourcing party's XRD/Service and verify the
> outsourced party's XRD/CanonicalID matches outsourcing party's
> XRD/Service/ProviderID. Outsourced party's XRD integrity has to be
> checked also with the cert associated with it.
>
> Method 2:
> Outsourcing party over-signes the outsourcer's XRD. I.e., Outsourcing
> party retrieves the signed XRD of the outsourcer and adds delegation
> statement and its own XRD location and signes it all.
> This looks simpler, but the downside is that outsource gets constrained
> on the service endpoint configurations, which may not be desirable from
> a service provider's point of view.
>
> =nat
>
> George Fletcher wrote:
> > Thoughts regarding the trust profile based on HTTP authority...
> >
> > Resource name to document binding...
> > * I think that the XRD will have to maintain the URL fragment (at least
> > in the OpenID case because it's the fragment that uniquely identifies
> > "alice". While there can only be one "http://www.example.com/alice"; at
> > any one point in time, there could be multiple "alice"'s over time. So
> > this would only affect caching related issues. The RP will need to know
> > whether this XRD relates to the same "alice" as they've seen before.
> >  
> > * In OpenID it should be OK for the resource
> > http://www.example.com/alice to match the CanonicalID of
> > http://www.example.com/alice#12345 (this is what happens today in OpenID
> > 2), but not OK for the resource http://www.example.com/alice#12345 to
> > match the CanonicalID http://www.example.com/alice.
> >
> > I like the overall trust profiles framework. If OpenID has specific
> > requirements to the bindings, does that imply a unique OpenID trust
> > profile? or can we put this requirements in the OpenID 2.x spec? I've
> > been thinking that the trusted delegation capabilities could solve some
> > of the realm and return_to matching problems that are incurred if an RP
> > wants to outsource it's OpenID support to a 3rd party. Basically, the
> > XRD served by the RP would indicate that all OpenID RP services are
> > hosted by another party on another domain. The realm (trust root) shown
> > to the user can then match the RP's domain while the actual return_to
> > URL is on a completely different domain. Trusted delegation makes 
> this "ok".
> >
> > Thanks,
> > George
> >
> > Brian Eaton wrote:
> >  
> >> Hi folks -
> >>
> >> I've written up some notes on trust profiles for XRD discovery:
> >>
> >> http://wiki.oasis-open.org/xri/XrdOne/TrustProfiles
> >>
> >> I've also written up a no security trust profile roughly equivalent to
> >> what OpenID does today:
> >>
> >>     http://wiki.oasis-open.org/xri/XrdOne/TrustProfileNoTrust
> >>
> >> ... and a second trust profile based on HTTP authority:
> >>
> >>     http://wiki.oasis-open.org/xri/XrdOne/TrustProfileHttpAuthority
> >>
> >> There are some disconnects between the work flow that Eran has been
> >> describing, the trusted discovery workflow that I put on the wiki last
> >> week, and these example trust profiles.  I think resolving those
> >> disconnects is a good work item for this week.
> >>
> >> Constructive criticism of the overall trust profile framework would be
> >> really useful.
> >>
> >> Additional comments on whether the http authority trust profile could
> >> be modified so as to be suitable for Bob's use cases would be great.
> >>
> >> A detailed description of the "one cert per identity" trust profile
> >> would be useful as well, to see whether it fits into the trust profile
> >> framework I wrote up, and to figure out how the trust profile
> >> framework needs tweaking so that it can fit.
> >>
> >> Cheers,
> >> Brian
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >>
> >>
> >>    
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >  
>
> ---------------------------------------------------------------------
> 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
>

-- 
Chief Architect                   AIM:  gffletch
Identity Services                 Work: george.fletcher@corp.aol.com
AOL LLC                           Home: gffletch@aol.com
Mobile: +1-703-462-3494           
Office: +1-703-265-2544           Blog: http://practicalid.blogspot.com