[OpenID] OpenID in India - What stops you from using OpenID?

[Snorri]

Dear Shade,

I open soon a WIKI to create a FAQ with all this
questions/arguments/benefits/marketing texts...

You're welcome!

Thanks

-Snorri

-----Message d'origine-----
De : SitG Admin [mailto:sysadmin at shadowsinthegarden.com] 
Envoyé : jeudi 26 juin 2008 08:38
À : Snorri
Cc : general at openid.net
Objet : Re: [OpenID] OpenID in India - What stops you from using OpenID?

>If you use one OpenID account to go to two hundred sites, the thief 
>who steals your OpenID credentials gains access to any of the 200 
>sites.

It's worse than this, actually. Unless the OP specifically *prevents* 
it, you can go to *any* OpenID-supporting site, even one other than 
one of the 200 you were previously accessing! And if they've gained 
access to your credentials with the OP, they may have also gained 
access to whatever authorization mechanism you were using to say 
"Yes, it's okay to add another site to the list."

This goes together with privacy issues; do you *want* the OP to keep 
track of sites you've logged into before, and how recently, even if 
only to display to "you"? Because, keep in mind, if the RP the thief 
has logged into *is* respecting your privacy, they probably *won't* 
publish a list of users that have logged in with OpenID - and if the 
privileges gained thereby have resulted which are not archived by 
Google, you may *never* find out. On the other hand, a thief who 
steals your OP credentials may be able to find out where you've been 
in the past.

>2)     Privacy issue - With open ID the identity provider can track 
>all your login and usage history. This in itself is a grave concern 
>for internet users. XeQure architecture is different and it does not 
>control the way user moves on a third party website.

Neither does OpenID - nor does OpenID track usage. It tracks login, 
but what the user does on that site afterward is not transmitted to 
the OP (though it may use checkid_immediate for some actions, which 
*could* track *some* uses).

>3)     No Patent -Open ID is a free framework (without any patent ), 
>which can be implemented by anyone (even hackers and phishers), this 
>makes it very vulnerable for hackers and users tend to have limited 
>trust in such applications. No wonder the user base is still very 
>low for it.

Uh. What about, oh, ANY open-source software, then?

Consider: there is NO power which can prevent hackers or phishers 
from implementing a "patented" technology. This is not the function 
of a patent. There may be legal repercussions to such an 
implementation, but why would this matter to someone who intends to 
break multiple laws anyway?

Yet somehow, none of this has managed to effectively limit the trust 
users have in such applications, OR render those applications more 
vulnerable to hackers - indeed, open-source applications tend to be 
LESS vulnerable to hackers, because the mechanisms are open to peer 
review and peer repair, instead of using proprietary standards and 
relying on "security through obscurity".

>It has many steps on each login and it is not a true single click sign on

This may be exaggerated a bit - many of these steps can be executed 
transparently to the user, appearing to be a single invisible 
process. Most of it takes place behind the scenes, just as the user's 
web browser does not print out messages to them every step of the way 
when connecting to other web sites;

- Host unknown: XeQure.com
- Normalizing URL: xequre.com
- Host (xequre.com) not found in DNS cache. Looking up DNS entry.
- Contacting cached DNS server at ##.###.###.##
- Entry not found, receiving IP address for next level DNS server.
- Contacting DNS server at ###.##.###.##
- Entry found, receiving IP address for xequre.com
- Connecting to ###.##.##.### (xequre.com), port 80
- Connection established! Sending GET / HTTP/1.1
- Sending Host: xequre.com
- Newline sent. Awaiting response from xequre.com
- Response received! Redirection header detected.
- Redirecting to xequre.com/main.php
- Host (xequre.com) found in DNS cache.
- Connecting to ###.##.##.### (xequre.com), port 80
- Connection established! Sending GET /home.php HTTP/1.1
- Sending Host: xequre.com
- Newline sent. Awaiting response from xequre.com
- Response received! Unknown Content-Type header: text/php
- Loading page as default Content-Type text/plain
- http-equiv=Content-Type header detected in HTML!
- Reloading page as text/html
- xequre.com response complete! Finish loading page.

I fudged a bit (xequre.com doesn't actually redirect to main.php), 
but it occurs often enough to assume regular users will encounter 
this behavior. Anyway, you get the idea - LOTS can happen "behind the 
scenes" that a user does not need to be aware of, and OpenID does not 
require any special technology; it utilizes the same Redirect 
mechanism that I described above!

>5)     Multiple user account login - What if user has multiple 
>accounts to say Google. He/she will still have to remember all the 
>URIs to login to different accounts. Open ID falls short of a true 
>SSO(Single sign on) to all user accounts.

That's a problem with Google, not with OpenID - consolidation of 
different accounts (uniting them under one Identity^1) is a feature 
that MAY be implemented by each RP, but only at that RP's *option*. 
Technically the OpenID specs do allow you to initiate login from the 
OP side, without starting to log in at the RP, so an OP could offer 
(as one of its own features) a "bookmark" that would get you started 
with logging in at the appropriate account for Google or wherever. 
But whatever SSO you are using, if each of your different accounts 
with Google has a different URI, you'd have to remember all those 
URI's *anyway* - that has nothing to do with OpenID!

Though, since the complaint here *is* "URI" rather than "username", 
we may benefit from a reminder that the user is not required to use a 
different OpenID for each of their Google accounts ;)

^1: And this Identity needn't even be OpenID - if the site wants to 
use an incrementing number to keep track of its users internally, and 
allow the user to designate one account as the "super-user" account 
from which the user can temporarily switch to any other account they 
have on the system, the OpenID login process can easily be hooked 
into this, allowing the user to log into their "super-user" account 
using their regular username/password combination *or* OpenID instead.

-Shade