Search
Tweets
Blogroll
Powered by Squarespace
« Yahoo! and OpenID | Main | Capistrano and deprec »
Wednesday
Jan022008

Continuous OpenID

I like the idea of OpenID, but there are a few annoying and dangerous aspects of OpenID that I don’t like:

  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.

Reader Comments (10)

What happens if you want to change OP but keep the same identity? Is there an alternative to OpenID's Delegation that wouldn't require participation by my old OP, e.g. they go broke or otherwise disappear from the web.
January 8, 2008 | Unregistered CommenterSam Hasler
Hi Sam

Good question. My idea was really to come up with something simpler (from the RP point of view) while still leveraging existing OpenID protocol implementations. (The protocol idea can
be significantly simplified if we're not using OpenID.)

That said, I don't think there is a difference when you want to change your OP. You'd just point the User-Agent (the browser) to another OP. Do I misunderstand your concern?

Do you think the current OpenID delegation model is broken?
January 8, 2008 | Registered CommenterHans
how would a consumer (RP) know that my identity at a new OP is the same as my identity at the old OP without some from of delegation?

I use delegation currently so that I can switch OPs whenever I want with no need to manually inform all the RPs I use (apart from the usual auth requests when I first login with the new OP because it doesn't yet know about any RPs).

Without delegation I'd either have to rely on logging into my accounts at RPs using something other than my OpenID (so we're back to remembering lots of passwords or every site knowing what my usual password is) and them allowing me change my OpenID to something else, or more likely I'd have to create a new account at every site I use.
January 9, 2008 | Unregistered CommenterSam Hasler
Sam,

In 'continuous OpenID' step 1, you pick whatever OP you want
to use, and then reference that OP in step 3. The RP then contacts the OP in step 4. So you can easily change OP.

For true delegation, you're right, there is currently
a step missing, but how about:

Step 2, an optional "openid.a.identity" name/value pair could contain your identity, and then the identifiers coming back in the authn call in step 4 would reflect that. Would that work?


January 10, 2008 | Registered CommenterHans
Hi;

Nice sugesstion.

Anyway I think, all three aspects you try to address with this approach is solved in SeatBelt plugin for FireFox.

Thanks & regards.
- Prabath

January 10, 2008 | Unregistered CommenterPrabath Siriwardena
Hi Prabath.

The seatbelt plugin is a nice utility and it does great good, but it doesn't solve any of my listed issues with current OpenID usage.

Even with Seatbelt installed, you still need to:

1) identify with a URL,
2) have the browser do RP redirection, and
3) explicitly state identity and manually log in to the site.

Hans
January 10, 2008 | Registered CommenterHans
Con:
OP requires a plain-text password store.

What about services such as http://openid.xmpp.za.net and http://xmppid.net that don't require a fixed password? (They use one-time passwords)
January 12, 2008 | Unregistered CommenterNorman Rasmussen
Norman:

Thanks for the links.

I'm not sure if I understand. There is no requirement for an OP plain text store. Step 2 authn_msg can easily contain an OTP.

I agree some limitations exist in terms of visual style logins, like what http://passpack.com or http://myvidoop.com use.

However, if you remove the main OpenID phishing vulnerabilities those solutions are not really needed.
January 12, 2008 | Registered CommenterHans
Just came back to this (via your comment to "Gears Future APIs: OpenID and OAuth") and on re-reading the following:

"A site should be able to automatically detect who you are."

It struck me that if that were the case it would be a big privacy concern. Would people really want advertisers or governments to be able to track their web usage? I suspect that there would be a significant proportion of the population that would be up in arms if this was the case.

Consider, Google is already having to explain why it's holding on to website logs that contain IP addresses. If every http request identified the user uniquely the EU would be starting up an investigation quicker than you can say Microsoft.
March 20, 2008 | Unregistered CommenterSam Hasler
Sam: You're right it is a privacy concern if the protocol identifies you in left and right!

In step E) above I envision the presence of a white list where the user tells the browser where to automatically login.
March 20, 2008 | Registered CommenterHans

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.