And the OpenID world reacts.

One can debate whether the set of standards that make up the Open Stack is too large and causes potential implementors and users to shy away from its implementation. I’m not sure.

I claim, however, that a big reason single sign such as OpenID has failed to take off is that its very ease of use is actually its own enemy!

The binding of the potential web site user to the site visited is much weaker when using OpenID, than if the user had created an account and logged in. Without an account, the user becomes a guest, and a web site wants visitors to become anything but just guests. It wants decided, committed users.

The direct mailing business figured this out. Still today, when you decide to join a service, you return one of the postage-free reply cards. But before you mail it, you do something seemingly insane. You stick the bright “YES” sticker onto the empty space where it says “PLACE YES STICKER HERE”.

Why?

Because they make you do that to create in your mind a commitment. A stronger bond. They don’t want you to coast into their service and feel no obligation and just leave. They want the commitment, the guilt, all the good stuff that keeps you there for a while.

OpenID provides the opposite. When I log into a site using OpenID, I am a tourist, a perpetual guest. I easily slip in, browse around, check things out, and leave. Nothing there to keep me. Nothing to make a mental commitment to the site.

(And if the site first lets me log in with OpenID and then makes me create an account, then it just plainly sucks, and I will never go there again. Only solution is to never accept OpenID in the first place.)

This is a real problem that seems to not be discussed much. I’m not sure it is solvable with any single sign on.

Nico claims

“The beauty is that Google did not even have to force a button or any branding on relying party web sites,”

which is in itself true, but what he skips is that the relying party has to amend how it processes discovery on given user identifiers. So either way, the RP has to do extra work. Nothing is free.

Nico continues

“The choice of identifier alone will make it easier for consumers to choose Google over FaceBook,”

but that only makes sense right now. The Facebook platform already is a de facto email network. It only takes FB a little bit of work to provide external email identifiers like alice@facebook.com, and whatever work has been done for @gmail addresses now works for FB, too, providing there is some sanity to the discovery phase.

And FB can do this without providing any external email services for their users at all.

It will be interesting to see what happens.

Source: Google's Smart OpenID Move (http://blogs.verisign.com/innovation/2008/11/googles_smart_openid_move.php)

Unfortunately, relying parties have to go through a lot of extra work logging people in and merging existing user accounts.

OpenID is already quite difficult to enable as it is, and now relying parties have to implement several new API calls.

Neither of these APIs seem to have been openly discussed and it’s not clear how they were designed. Is there a public security analysis? Why are high-value parameters such as “I agree to the terms of service” sent in the clear and unsigned?

Clickpass is a promising idea, but my advice to an RP would be to hold off implementing it until the protocol has had some time in the open.

As a result, it seems it was hacked in a day and thousands of user names and passwords (from all walks of life) are now in the wild. Some people can’t resist a challenge apparently.

Lars Olofsson shows some interesting statistics about password choices and lengths, linked from Flashback.

What does this mean for an OpenID user?

Do your due diligence.

OpenID can provide tremendous value for its users, but all OpenID providers are not equal. Look at how they make you log in. Ask them how they store your data and about internal and external processes. Ask about how they keep your data private and secure. Make sure you know how they handle your usage trails.

And choose providers well.

One of the pain points with OpenID is that it’s quite hard to implement it as a customer. If you’re a small business with a home-grown web site, it’s a daunting task, despite excellent write-ups and a number of excellent software components.

Mom and Pop needs a simpler way of adding OpenID to their site. An identity proxy service that takes care of all OpenID magic with a simple API that customers hand the received the OpenID identifier to and get the equivalence of a yes/no back from the API?

I think the browser redirects, return addresses and trust roots (realms) could be properly handled as per the protocol.

Hmmm….. Anyone interested? ;)

Passwords In The Cloud

Let’s say you want to store your usernames and passwords somewhere on the internet, but you want to make sure that they cannot be misused. And you think OpenID is not right (for whatever reason).

Passwords in the Cloud (pitc) is a simple approach to solving the problem. It requires participation by the sites you log into, just like OpenID.

pitc has not had any real security analysis, so don’t start deploying it just yet ;)

A few observations what’s not cool:

• Trying to get preferential treatment by using Yahoo!-specific OpenID login buttons. This effectively shuts out other OpenID providers.

• Claiming “Yahoo! worked closely with the OpenID foundation and community to finalize [OpenID 2.0] in December 2007” when Yahoo! was notably absent from OpenID 2.0 specification work.

In all, though, a giant leap forward and a crucial test whether the protocol is strong enough. It will be an interesting February!

1. The need to identify yourself with a URL.
2. The redirection from the Relying Party to the OpenId Provider and back.
3. The need to state identity and actually log in to a site.

A previous entry explains why I don’t like the two first aspects above.

Below I outline a suggestion how to avoid these flaws while still using OpenID protocol messages. I want to accomplish a continuous and automatic identification to websites. There should be no reason for you to state identity and have to log in. A site should be able to automatically detect who you are.

In this suggestion suggestion:

• The User-Agent shares a secret with the OP.

• There are no User-Agent browser redirections.

• No change to the OpenID protocol messages. Existing OpenID libraries should work.

The protocol

The protocol uses OpenID messages and one new identification message sent by the User-Agent to the Relying Party.

1. User-Agent association

User-Agent negotiates a secret with the OpenID Provider using a standard OpenID Associate request.

2. User-Agent authentication

The User-Agent then authenticates its user to the OP by sending an OpenID authentication request.

User-Agent calculates an authentication message authn_msg. The format depends on the authentication mechanism used. For username and password, the protocol HMAC-signs the password using the MAC key from step 1. and creates

  authn_msg = HMAC(password) + username

The request message becomes:

  openid.ns=http://specs.openid.net/auth/2.0
  openid.mode=checkid_immediate
  openid.assoc_handle=[association handle from step 1.]
  openid.realm=[any valid url, not used]
  openid.ns.a=http://example.com/continuous_openid
  openid.a.authn_msg=[see above]

Since we don’t add openid.return_to to the request, we don’t expect a response. The OP makes a note whether the given assoc_handle has been used in a successful authentication, and if so for which user.

3. Identification message

(This is the only non-OpenID message.)

The User-Agent calculates an identification message id_msg and sends it via HTTP header to the url that the user visits. This message contains a timestamp with a nonce, ts, as defined by OpenID specification.

The protocol HMAC-signs the user’s identity (username), url and timestamp with the MAC key from step 1. To this signature, the protocol adds the same values in the clear, as well as the OP url:

  id_msg = HMAC(id, url, ts) + id + url + ts + OP

4. RP OpenID Authentication

The website (Relying party, RP) receives and parses id_msg and constructs an OpenID authentication message:

  openid.ns=http://specs.openid.net/auth/2.0
  openid.mode=checkid_immediate
  openid.return_to=[where RP wants the response]
  openid.ns.a=http://example.com/continuous_openid
  openid.a.id_msg=[id_msg as received]

The RP sends this message to the OP referenced in the id_msg.

The response is a normal OpenID assertion, including identity and claimed_identity, with the added fields (part of the response’s signature):

  openid.ns.a=http://example.com/continuous_openid
  openid.a.id_verified=["yes" or "no"]

“Yes” means id_msg was OK, “no” means it wasn’t. The RP should treat a negative assertion response equal to id_verified containing “no”. (The RP should also check signature on the response assertion, as per the OpenID spec unless it uses its own association handle).

5. That’s it

The RP now knows whether the user is authenticated to the OP in and can immediately tailor its pages to the user. Note that the user never had to enter an OpenID identifier, nor were there any browser redirects.

Example user experience:

A. Start web browser.

B. Browser plug-in asks for OP + username + password which the user enters.

C. Browser plug-in performs steps 1 and 2 above.

D. User enters a URL.

E. Browser plug-in checks if it knows whether user wants to automatically identify to the website. If not, it asks if user what to do.

F. If user agrees to identify, plug-in performs step 3 above.

G. Website detects presence of HTTP header and parses it, then decides whether to accept stated OP, and if so, asks OP to verify user in step 4 above.

H. OP receives authentication request and processes it. OP checks that timestamp and identity are acceptable and whether the identity is successfully logged in (step 2 above), and if so, OP knows which shared secret to use to verify the HMAC signature in the id_msg.

Then OP returns “no” or “yes” plus identity if everything checks out.

I. Website returns content tailored for user.

Analysis

There are pros and cons with this approach.

Pros:

• User logs in once, via the User Agent, to her OP.
• No more entering a URL as identity. No more entering an identity on every website.
• OpenID phishing problems go away since there are no redirects back to the OP.

Cons:

• Needs a plug-in; doesn’t work with existing browsers. [rebuttal: the current OpenID phishing problems seem to force use of added functionality such as plug-ins or protocol support into the browser]

This is just a rough first draft. Any and all input welcome.

1. Naming myself http://commented.org or =hans is just wrong. I am not a URL. I am a free man. URLs describe resources, not people. URLs are ugly.

2. OpenID requires the browser to redirect the user back and forth between sites. This is just an ugly user experience. Ping-pong is best played on a table.

3. The attribute exchange functionality is overkill. Relying parties want to use OpenID to authenticate the user and little else.

So, how do you solve it? You can solve it by a mechanism that

1. Allows the user to choose any username the user wants at any site, and never have any clashes with users on the system, including those with the same username!

2. Allows the relying party to directly check your credentials with an identity service with no risk of the credentials being reused be man in the middle attacks.

3. Only serves to authenticate the user. After all, I will not store my payment info in the cloud, and is it really that difficult to re-enter your nickname or email address when you establish a new relying party account?

With those simple solutions, you don’t need URLs to label people, you don’t need to put the end-user at risk of obvious MITM attacks, and you don’t need to depend on browser and transport security to bail you out.

The VeriSign official blog has more info.