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

[Manger, James H]

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091027/4b0be83c/attachment.htm>