OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] trust profiles for XRD


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]