[OpenID] user centric delegation vs portability: LRDD : competing threats: the consumer's fear hypothesis
Dirk Balfanz
balfanz at google.com
Tue Oct 27 01:55:53 UTC 2009
On Mon, Oct 26, 2009 at 4:28 PM, Manger, James H <
James.H.Manger at team.telstra.com> wrote:
> Dirk,
>
>
>
> I don’t think your IBM example is a very convincing argument for host-meta
> to take precedence over an actual OpenID URI. Listing an OP in host-meta may
> be a bit easier for an IBM IT admin than preventing links to OPs from other
> URIs — but the latter is quite feasible (rules in the page editing tool;
> filter in web server; validator on page changes; background script to look
> in the file system for this specific situation…). Even a non-technical
> corporate policy saying staff must not specify another OP goes some way to
> meeting the objective.
>
I agree with all you're saying: having a policy might go "some way",
background scripts looking for bad OPs in people's web pages can also catch
problems, etc. Still, these would seem like work-arounds to a buggy spec to
me, one in which an organization that otherwise can control what its users
are doing down to very minute details (enforce anti-virus software on
people's machines, for example) can suddenly not do this for a very
security-sensitive issue (its users' identity provider). I would consider a
spec in which users _had_ to rely on some admin to configure this for them
also broken, for what it's worth. Like I said, we should try and address
both use cases.
> 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.
Dirk.
> Most OpenID URIs on a host don’t specify an OP so they fallback to
> host-meta, but a few can use a different OP (for non-humans, for
> contractors, for testing, for migrating to a new OP implementation, for
> staff with a different hardware login token…).
>
>
>
>
>
> *James Manger*
> James.H.Manger at team.telstra.com
> Identity and security team — Chief Technology Office — Telstra
>
>
>
> *From:* openid-general-bounces at lists.openid.net [mailto:
> openid-general-bounces at lists.openid.net] *On Behalf Of *Dirk Balfanz
> *Sent:* Tuesday, 27 October 2009 7:51 AM
> *To:* Peter Williams
> *Cc:* general at openid.net
> *Subject:* Re: [OpenID] user centric delegation vs portability: LRDD :
> competing threats: the consumer's fear hypothesis
>
>
>
> …If you have your own domain, you can pick (and change) your identity
> provider. But if you're one of 300,000 IBM employees, there are certain
> things you can't pick about your work account - you can't pick your email
> provider, you can't pick your calendaring software, and you can't presumably
> pick your identity provider - professionals at IBM who get paid to worry
> about this stuff will pick one for you that they are reasonably sure will
> not, say, put into jeopardy the 401k accounts of the combined IBM workforce
> (because, hypothetically speaking, IBM uses OpenID to log their employees
> into fidelity.com).
>
>
>
> We need a single sign-on solution for the Web that works both for
> Blogger/Facebook/consumer use case as well as the IBM use case.
>
>
> Dirk.
>
> _______________________________________________
> 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/20091026/5653414f/attachment-0001.htm>
More information about the general
mailing list