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

Peter Williams home_pw at msn.com
Tue Oct 27 18:59:43 UTC 2009


One thing we might recognize as a community that there are now three
sub-communities messaging on openid (and 1.5 years ago there was only one -
and it had a typical evangelist-phase tone). 

 

Certain potential adoptees (as an industry) almost bought into the message
of 1.5 years ago (the paradigm shift of user centric content, delegation
operated by parties other than OPs, user portability, correlation of ids
with content left at a hundred RPs, .) as a reason to pick openid SSO over
SAML SSO, etc). That message is now "almost" being repudiated. Perhaps folks
remember when there was the notion that ancien security was out, and nuveau
"identity" was in? Anyone who thought in the memes of "security" was not
going to get "identity" in the web2.0 era (despite I&A being one of the
staples of any "corporate" security program). Within a year, things reverted
somewhat to normal (focusing on the CISO's needs and the standard governance
points).

 

1.       There is the google message - making openid into a solid piece of
enterprise middleware that can facilitate app outsourcing by enterprises to
cloud providers - and thence link enterprises to consumers/subscribers.
Instead of ws-federation redirect URI or ws-trust, do openid redirects. Let
host-meta el al do for app domains what sts metadata would otherwise do when
orchestrating the proxying of w-security/ws-trust communications through a
value-adding SOA cloud provider.

 

2.       There is the relic of the social network message - making openid
into a trust fabric for the public space (accessing even .gov under that
community's paranoid privacy practices). These web2.5 memes address long
term social issues around privacy policies and the fundamental TTP trust
relationship megaportals have with consumers. (This whole issue set
recaptures the moment of VeriSign birth to my mind, in a earlier era.)
Today, this is perhaps most obviously represented by LiveID - the public
portal of half a billion users (where I'm trying to distinguish the LiveID
pitch from the Azure group's pitch, just within the Microsoft's own
storyline)

 

3.       There is the continuing message from several sources - derived from
the SUN/Concordia message of about 2 years ago -that  openid is forever a
lightweight SSO (in comparison to SAML2). It is as yet  technically
"unfinished" and cannot be legitimately applied yet to anything of any
sensitivity or criticality -- until "elementary" technical and governance
issues have been addressed (see above). Half the time this comes across as
the old SAML vendor community attempting to invoke market delaying tactics
(bad! on them), and half the time it seems to be about the SAML technical
folk re-invigorating their community for a multi-protocol world that can
share the stage with openid and ws-fed [and perhaps even foaf+ssl] (good! on
them).

 

Ive never been before to a internet identity workshop, which I hope to do
next week. I'm hoping it will somehow address the changing of the message on
user centric'ness in identity systems. I don't believe it's something than
can simply be spun away.

 

 

 

From: Dirk Balfanz [mailto:balfanz at google.com] 
Sent: Monday, October 26, 2009 1:51 PM
To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] user centric delegation vs portability: LRDD :
competing threats: the consumer's fear hypothesis

 

Hi Peter, 

 

thanks for your thoughtful response. 

 

As I see it, provider-independent identities are merely a means to an end.
They shouldn't be the one-and-only litmus test applied to single sign-on
solutions.

 

To me, what's important is that users can get quickly to a personalized
experience across the web. That is - when I see a new web site, and it
promises a useful service (which requires an account), I can immediately
start using it. With just a few clicks, I can tell the service who I am,
connect it to other services I use that it needs data from, etc.

 

I like the idea of provider-independent identities. It is one (although not
the only) way to allow me to continue to use said service even when/if I
leave my identity provider. However, that's but one of many considerations
we need to make. If the only technical solution we can come up with is one
that (1) features provider-independent identities and (2) increases hurdles
to personalized web content (e.g., is too difficult to use by the majority
of users), I have to admit I would start looking into whether relaxing
requirement (1) could possibly help with problem (2) (not saying that
currently OpenID falls into this category - just illustrating my
priorities). 

 

It's true that I am a bit nervous, from a security point-of-view, about the
delegation model used by OpenID today. As OpenID moves into the mainstream,
I'm worried that a single "defacing" attack (i.e., one in which an attacker
alters the content served from a certain server) can move the identity
provider for a whole DNS domain to some machine under the control of an
attacker. 

 

Finally (as John points out), delegation and provider-independent identities
certainly aren't prevented by the proposed OpenID discovery mechanism. Sites
like Blogger or Facebook, etc., could leave it up to their users to pick
(and change) OpenID providers. 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.

 

On Sun, Oct 25, 2009 at 3:57 PM, Peter Williams <home_pw at msn.com> wrote:


I found the writeup at http://hueniverse.com/2009/09/openid-and-lrdd/
convincing, technically. It moved the whole set of technical delegation
issues forward. It told a story. It was well written.

A. It reminded me of what Ping Identity once proposed for
dynamically-sharing SAML metadata between IDPs and (affiliations of) SP:
use a url-factory rule to deduce a URI from a domain name, get metadata from
said URL, and apply https/domain-cert controls to test for a saml entities
authority... to make assertions for that domain name. Optionally, sign the
metadata (much as one optionally signs XRDs). All Pretty obvious stuff
...but effective.

B. It reminded me of the leap forward of myopenid, when hosting outouurced
OPs via OPX (which uses DNS control principles to enable domain admins to
prove the delegated domain is authorizing the outsourcer to speak for it).

C. And, it reminded me of openid2, in that there are various flow fallbacks.
These allows communities to choose different flows (and thereby address
different players issue sets) when delegating and locating providers.

What I didnt like what the bias I heard throughout the writeup - concerning
the criteria I described in C.

Unlike the openid communities traditional mission (empower users, and give
them control over their data and names), there was a fear message at the
heart of it: focus on all that which COULD go wrong. And into that fear
rides the fearless knight on a white horse... the OP.

The fear said, users are easily duped and cannot in any case be trusted to
get it right - unlike the corporate CISO in whom we must trust. (Peter is a
CISO, by the way). Furthermore, we will bias the fallbacks so corporate CIOs
can control, before users control. If this was law, folks just coded their
bias in favor of the CIO and against the user/subscriber - through the
formulation of the legal presumptions.

Now, this bias may well be fine (if your audience is corporate buyers of
outsourced apps, leveraging openid protocols to get login sessions and
attributes). And, perhaps that is who the vendor is pitching its LRPP
technology to .

But, surely, the openid movement more generally needs to be focussed more
widely than only corporate sales -it also has consumer interests to
consider. If it fails here, it will risk falling into the pit that SAML fell
into - and fail to stay current with the larger currents of the web itself.
Historically (in the years before openid challenged SAML), every corporate
SAML link took a year, cost a million, was the bane of the CIO life, and
noone did two if they could avoid it.

Now, as oft associated with the Facebook brand, there are interplays between
the corporate control and consumer rights - particularly over data ownership
and identity control isues. And some mega-brands do better than others in
getting the balance right (and some actively hamper the user when
dis-associating from the brand, once things go sour). Some brands infamously
create explicit exit barriers (preventing you from exporting your contacts
to a file, say, or impose legal controls that limit just who you may (NOT)
choose to also work with).

When considering whether LRPP MAY be right for openid movement, we must
reflect that the openid movement is -or at least WAS - in the middle of
these issues, and took a position. It traditionally allowed for identifier
portablity and data rights. If you were to lose rights of access at an OP
(paypal dumps peter for violating service rule X) ... delegation ensured
that this 1 OP's suspension of Peter made no difference to Peter's private
life and Peter's relationship with RPs (becuase the protocols automatically
fell back on the next OP to which peter had delegated YOUR name). Peter
either could take such pre-cautions, or not - depending on his needs.

What Im hearing in the LRPP story is not consistent with the original openid
user-centric story - targeting social networks (vs corporate application
outsourcing). The fear line seems to be implicitely denying the legitimacy
of user centric identity. In its marketing line, it seems to be saying that:
its far more important for consumers  to be free of fear, than be free of a
provider (when the relationship goes sour).

Interesting changes going on in this movement!







--
View this message in context:
http://www.nabble.com/user-centric-delegation-vs-portability%3A-LRDD-%3A-com
peting-threats%3A-the-consumer%27s-fear-hypothesis-tp26052720p26052720.html
Sent from the OpenID - General mailing list archive at Nabble.com.

_______________________________________________
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/7f99aa47/attachment-0001.htm>


More information about the general mailing list