[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] trust profiles for XRD
Ben Laurie wrote: > On Wed, Dec 17, 2008 at 11:20 AM, Nat Sakimura <n-sakimura@nri.co.jp> 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. >> > > Surely any signing scheme breaks if the owner of the signing authority > can change? > In a long run, a signing authority of the XRD and the owner of the domain does not have to match. Sining authority for my XRD that has my CanonicalID is me even if I lose the authority over the domain. > I don't understand how your methods below defend against this? > > Below is a different topic. It is about the secure delegation, but let me go on. >> 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. >> In this scenario, CanonicalIDs are not a normal URI. Think of it as DCE name in X.509. Let A be the name. Then the Subject of the X.509 matches A. This A is stable over the time and will never be reassigned to another party. Now, the XRD of A also has this as the CanonicalID. Thus, by inspecting the signature over XRD and A's cert, it will be proven that this XRD is authoritative as A's XRD. Let this XRD be called as A-XRD. A-XRD has a service element in which he wants to delegate to an outsourcer whose DCE name is B. Then for this service, A-XRD/Service/ProbiderID will be B, and this is authoritative. When B-XRD is retrived, one can find B as the CanonicalID and the signature can be verified so B-XRD is authoritative for B. By tracking this chain, the service consumer will be sure that A delegated one of his service to B. >> 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 >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]