[OpenID] Security/featureset at odds?

Peter Williams pwilliams at rapattoni.com
Sat Aug 2 02:48:47 UTC 2008


As i see it there is precious little difference (semantically) between openid websso and the earlier/other generations. If anything, openid is lacking (in the trust arena), on account of its purist adherence to the uci model.

To be positive, openid does have some deployment advantages! These are the potential of xri discovery (and its implied trust modeling apparatus) and the easy of integration of urls. By mandating https, it overcomes most objections to its lack of protocol handshake design features. Sreg and ax are minor variants of the saml push/pull attribute concept (tho certain outsourcing elements of ax-based syndication of values between rps are "novel"). The pape stuff is so-so.

Your comments about rights to buddy list x means rights to influence buddy list y  simply lost me. I hadn't seen anything in the openid concept that came down to buddy list "synchronization" (as a side effect of the websso or trust relationship that is implied by openid).


-----Original Message-----
From: SitG Admin <sysadmin at shadowsinthegarden.com>
Sent: Friday, August 01, 2008 6:50 PM
To: general at openid.net <general at openid.net>
Subject: [OpenID] Security/featureset at odds?


I tried thinking of concrete examples as Nat requested, but it was
difficult to work on the details because, once I had the loosest idea
of what a usecase was, my thoughts were overwhelmingly along the
lines of "Our security model sucks."

The current network model seems to be 3, at most 4, steps; usernode
to multiuser (typically a large site offering services such as
homepage or E-mail) node to usernode, possibly routing through
another multiuser node that the 2nd usernode is connected to the
internet through. Every user is communicating with 1 other user (at a
time) or 1 multiuser, re-authenticating to each.

SSO promises to solve this, letting users authenticate in the same
way without giving up their credentials to every other node. But
aren't we effectively endangering this by creating a network model
where RP nodes and OP nodes can talk to one another without a user
necessarily being involved? When actions such as "add my new Friends
from site1 to my Friends at site2" (and all the access privileges
such changes entail) can be performed by a single node that is either
compromised, or deceived into thinking an attacker is the legitimate
user by *another* compromised node, is there any difference?

Two thoughts on this:

1) It's important to focus on the benefits that OpenID can offer
*besides* SSO, and to develop them. It's especially important to not
push SSO so hard that we distance OpenID from those who *want* to
have multiple passwords required, per service, for additional
security.

2) We should put together a list of differences, however minor, that
OpenID might make in how the current flow of information on the web
goes. Then we can properly analyze the potential implications they
have for security instead of trying to guess ahead (and losing face
over the disaster when we fail to guess ahead).

All of this may be elaborated upon, in a more coherent manner, when I
have had Food ;)

-Shade
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general



More information about the general mailing list