I like the idea of OpenID, but there are a few annoying and dangerous aspects of OpenID that I don’t like:
- The need to identify yourself with a URL.
- The redirection from the Relying Party to the OpenId Provider and back.
- 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 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
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
The response is a normal OpenID assertion, including
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"]
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
Then OP returns “no” or “yes” plus identity if everything checks out.
I. Website returns content tailored for user.
There are pros and cons with this approach.
- 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.
- 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.