[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] trust profiles for XRD
On Thu, Dec 18, 2008 at 7:11 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote: > > > 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. So how does this work? >> >> 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]