[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] trust profiles for XRD
On Wed, Dec 17, 2008 at 7:23 AM, George Fletcher <george.fletcher@corp.aol.com> wrote: > 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? Currently, RP outsourcing does not work well. The 'trust profile' for OpenID currently is to match the authority of the return_to URL and the domain, and prevent redirects from happening by discovery at the realm. The current proposal could allow the realm to delegate to a return_to URL with a different authority, enabling outsourcing securely. To give a concrete example: JanRain hosts change.gov return_to URLs at change.rpxnow.com/... ; This requires them to set the realm in requests to change.rpxnow.com. That is a broken user experience and basically avoids addressing any of the trust issues (which remain, only have been outsourced to the party less likely to have the means to make an informed judgment, namely the user). JanRain has no good options here. However, if change.gov were to delegate with a signed XRD the location of the return_to URL as https://change.rpxnow.gov, then JanRain could set realm=http://change.gov; return_to=https://change.rpxnow.com, and the user experience at the OP would be to approve to sign in at change.gov, while being redirected (temporarily) to change.rpxnow.com for OP response-processing. > > 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 > > > --------------------------------------------------------------------- > 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 > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]