Re: [xri] trust profiles for XRD

[Nat Sakimura <n-sakimura@nri.co.jp>]

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