[OpenID] Is OpenID truly user-centric and OP-independent? (WAS: Bug in OpenID RP implementations)

Wed Jan 14 14:28:50 UTC 2009

I have yet to understand why people assert that type of OAuth comment. I jus don't understand OAUTH well enough, yet.

Given all I know (from the OAUTH spec), data providers can share data with data consumers, once authorized by the user. Though any act of authorization (or "delegated" authorization) requires first an act of authentication (ideally with openid), the two security services are usually designed to be independent.

In the websso world I come from, what Plaxo do is perfectly normal.  They "confirm" using a local procedure the authentication statement in the assertion. That is, they declare that the assertion is not a bearer-class assertion, which would have implicit confirmation. As a consequence of that confirmation model, they confirm locally that the user controls the email identifier delivered via the nice "form fill" function that openid/sreg just performed.

In reality, Plaxo is perform name-federation with the users email identifier to the plaxo account. The verification model is really between the mail/phone provider and Plaxo, not OP and RP. Even if the OP has already performed that very same email confirmation (e.g. myopenid), the UCI model means that Plaxo have no assurance that it was performed, or performed properly. Thus, they do it themselves.

As plaxo is oft-cited as a model openid RP by the protocol-designer class of folk here, I had assumed that this RP-confirmation process was an INTENDED deployment behavior of "model" RPs. I had ASSUMED that It was one of those tradeoffs derived from the UCI  mission - which gives the function of survivability on the one hand, but takes away assurance on the other. One rebuilds assurance by local confirmation, I guessed.

During one-time name-federation to plaxo during (n) openid registration(s() - and providing different openids can introduce different email/phone accounts -  I don't see this as a big deal. If Plaxo as an RP were repeatedly confirming with the email/phone provider, then Id agree - something user-centric is needed  (perhaps OAUTH); as then the email provider becomes a central control/authorization authority - governing the user's ability to talk to plaxo.

From: Andrew Arnott [mailto:andrewarnott at gmail.com]
Sent: Wednesday, January 14, 2009 6:06 AM
To: Peter Williams
Cc: Martin Atkins; OpenID List
Subject: Re: [OpenID] Is OpenID truly user-centric and OP-independent? (WAS: Bug in OpenID RP implementations)

Yes, I wish everyone could follow that model at Plaxo.

But Plaxo would do well to adopt OAuth. I noticed as soon as I created an account just now that they wanted to take my email password<http://blog.nerdbank.net/2008/10/why-oauth-can-be-ignored.html>.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

On Wed, Jan 14, 2009 at 5:51 AM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:

Add a plural s to the word identity.

IN policy language, the goal is surely not attaining "independence" from the communications infrastructure; but achieving "autonomy".

This is nicely seen in the plaxo model for building RPs, where you can bind n openids to the plaxo account. As a user, you can invoke any one of these identification paths. If flicker suspends your account (which they are want to do), there is no downside to you at Plaxo. Survivability is built in, with automatic, dynamic re-routing around the congestion point.

From: general-bounces at openid.net<mailto:general-bounces at openid.net> [mailto:general-bounces at openid.net<mailto:general-bounces at openid.net>] On Behalf Of Andrew Arnott
Sent: Wednesday, January 14, 2009 5:35 AM
To: Martin Atkins

In fact, I've become convinced that there is no way to allow a user to maintain his own OpenID identity independent of any OP or ISP given the profile of a common Internet user today.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090114/e10a7c7c/attachment-0002.htm>