Re: [xri] trust profiles for XRD

[Ben Laurie <benl@google.com>]

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?

I don't understand how your methods below defend against this?

>
> 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
>