[OpenID] user centric delegation vs portability: LRDD : competing threats: the consumer's fear hypothesis

[John Bradley]

James,

If a site say IBM uses site-meta to map URL's to XRD there is nothing  
to stop them from giving an individual edit access to the XRD so they  
can map there services to wherever they like.

It makes it harder to have an exception for hosting a single XRD  
someplace else.

They can use link headers if they want to allow users to host there  
XRD at arbitrary locations.

However they would still need to sign the XRD if the subject is there  
URI and they are not using host-meta to delegate.

host-meta is about controlling where the XRD are and not about  
controlling the OP.
They are related but separate issues.

John B.

On 2009-10-27, at 4:09 AM, Manger, James H wrote:

> Dirk,
>
> If a company gives total control of the contents of a set of URIs to  
> staff members, then also wants to use those same URIs as controlled  
> security-sensitive OpenID identifiers… then that is a disconnect  
> that I doubt host-meta can or should try to paper over. Does any  
> company do this?
> If a company wants to control the OP it is trivial to offer official  
> OpenID URIs for staff where staff have no control over their page  
> (perhaps with the exception of a photo or blog link). Isn’t this how  
> most major public OPs work today? It is well suited to entering  
> “staff.example.com” at RPs, instead of a longer actual OpenID URI  
> (say, staff.example.com/12345678).
>
> >> It is probably more convenient for host-meta to be able to  
> provide a default OP,
> >> which can be overwritten for some special URIs.
> > You can do that under my proposal: You don't specify the OP in the  
> host-meta.
> > You use the Link-HTTP-header to point to the "default" XRD for  
> most URIs
> > (which in turn points to the "default" OP). You have some sort of  
> process in which
> > that Link-header can be set to point to a non-default XRD,
> > which then points to a non-default OP. If a company/web site wants  
> to do that, that's up to them.
>
> Sure, you can do it by ditching host-meta and doing something a bit  
> more complicated. It will be painful if a site starts with host-meta  
> for all; then wants 1 exception; so they have to ditch host-meta and  
> switch to Link headers for everyone. In other words you have to be  
> absolutely sure you will never want any exceptions if you choose the  
> host-meta option (and it has priority).
>
> The scenarios where a high-priority host-meta helps security seem  
> rarer than the scenarios where a low-priority host-meta aids  
> deployment, maintains user-centricity (and is more backwards  
> compatible with existing OpenID)… but perhaps I still like URIs as  
> identifier too much ;-)
>
> James Manger
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091027/12509802/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2468 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091027/12509802/attachment-0001.bin>