RFC: OpenID roadmap

alex_b's picture

Based on an email conversation I had with Darren, Evgeny, Aron Novak and Walkah I pulled together this roadmap for advanced OpenID features (attribute exchange, provider, etc).

The goal is to reduce the overall number of modules involved in deploying OpenID attribute exchange features, to expand on existing content profile integration, to remove dependencies on modules that are not used in all use cases and to push changes into OpenID and OpenID Provider where it makes sense.

This is the initial situation (April 9, 2009). There is fully functional support for OpenID authentication and attribute exchange on client and server. The multitude of modules is not ideal, given their small size it should be easy to consolidate them.

Proposed changes in step 1:

  • OpenID provider AX and OpenID provider SREG depend on Persona, Persona is therefore mandatory. Reverse this dependency so that provider implementations with content profile instead of persona are possible. For AX this is already done: http://drupal.org/node/399746, for SREG I just opened a ticket: http://drupal.org/node/430332
  • Expand upon openid_cp_field to make it an OpenID/Content Profile integration module with a mapping UI for both client and server. Currently OpenID CP Field and OpenID client AX do both content profile mapping -> duplicate functionality. This change will make it worthwhile to expand on the UI for mapping and it will remove content profile integration from OpenID client AX which will prepare the ground for Step 2. Patch in queue: http://drupal.org/node/428932

Proposed changes in step 2:

  • After step 1 OpenID client AX, OpenID provider AX and OpenID provider SREG are going to be very small API modules that can easily be rolled into OpenID and OpenID provider.


These two steps would bring us from 7 modules in the set down to 4 modules, they would reduce the number of [edit: contrib ]modules to deploy on an OpenID provider from 5 to 3.

Additionally, dependencies between modules would be cleaned up and content_profile-only implementations would be possible.

I'd love to get Step 1 out of the way as soon as possible and I think that there is basic agreement on Step 1 changes.

If there is agreement on Step 2 we could start working on it as soon as Step 1 patches are committed. Id' suggest to create a Drupal 6 2.x branch for OpenID provider and a Drupal 6 1.x branch for OpenID module to prevent existing deployments from breaking.

What are your thoughts?

Picture 1.png41.23 KB
Picture 2.png44.35 KB
Picture 3.png39.63 KB


OpenID Core Module will they allow updates

darren.ferguson's picture

Alex, i like the roadmap it certainly puts into perspective the number of modules we would need and also it does make sense to consolidate them.

OpenID Provider i think definitely should have the 6.2.x branch for it however for OpenID since it is a core module will we be able to branch that out for 6.x or will that have to wait until Drupal 7?

Regarding the final version i believe the openid client ax module can probably be re-named too openid_rp and this will support Attribute Exchange extension for the core module and also support the simple registration and the pertinent schema definitions we need. This way people will not think it is just for attribute exchange (thoughts?)

CP Module i definitely like the idea we discussed on it being on both the client (RP) side and the provider side and i think the client ax module as it stands will need the functionality for updating the content profiles removed from it and put into the content profile module. On a whole i think the roadmap definitely goes a long way to what we wanted for the modules and definitely will help with the OpenID portion for the community.

Darren Ferguson

Darren Ferguson

Rather OpenID 6.x than an intermediary module

alex_b's picture

Darren, thank you for your feedback.

"OpenID Provider i think definitely should have the 6.2.x branch for it however for OpenID since it is a core module will we be able to branch that out for 6.x or will that have to wait until Drupal 7?"

We should be able to roll an OpenID 6.x module with AX support. This is an alternative to keeping OpenID Client AX separate in Drupal 6, so it is a 0 in our module number equation: In both scenarios the user has to download a module and install it in order to enable AX support. In the case of an OpenID 6.x module it would be the OpenID module, in the case of keeping OpenID client AX (or RP) for 6 it would be the client module. However, rolling OpenID Client AX into OpenID in 6 gives us valuable feedback from the field for a solid Drupal 7 solution.

The OpenID namespace is free for 6.x : dropping OpenID 6.x module with AX support into sites/all/modules or sites/[site]/modules would replace the core module's functionality without any headaches.

Does this make sense?


Alex, Yes that does make

darren.ferguson's picture


Yes that does make sense, i was concerned regarding the drupal 6 branch for core module however what you say above removes my fears, if people want to use this functionality they need to download this branch created for it, sounds good to me. Will James provide us CVS access to create the 6.x version off the current core module?

Darren Ferguson

Darren Ferguson

couple quick notes

HongPong's picture

This is decidedly below your level but i'll chime in anyhow. 1) What does 'ax' stand for? sorry :-D

2) in the grand scheme of things it seems like OpenID has not been advancing like it should and instead the corporate Google and Facebook logins are becoming ascendant. This is really unfortunate.

However from what i gather of the proposal above, the new OpenID implementation would allow drupal sites to serve up logins for other websites (i.e. is that the purpose of this module http://drupal.org/project/openid_provider ?) It would be nice to get the doc here rewritten so some fool like me, coming in cold, grasps what is going on (both on the openid_provider page and the RFC).

This could potentially be huge & breakup & decentralize the impending Google/Facebook lockout, however it seems not very lucid/approachable to someone who hasn't been following along already :-)
That's all, thanks for the marvelous work!

To reply to your

darren.ferguson's picture

To reply to your questions

  1. AX = Attribute Exchange and allows OpenID too send requested attributes i.e. name, email, home page etc too the calling (relying party)

  2. The purpose of the new implementation is to compliment the openid provider and also core openid module and add the relevant pieces of the puzzle in order to make Drupal's implementation correct to the standards that are out there. Once this road map is completed there will be complete documentation on what actually Drupal will be able too do with all of the information above.

Darren Ferguson

Darren Ferguson

Ongoing work document

alex_b's picture

For the record, you can find the work document for ongoing patches according to this RFC here: http://groups.drupal.org/node/21357


Link to d.o. roadmap

alex_b's picture

Link to d.o. roadmap: http://drupal.org/node/329493 (to be updated)

Works with any OpenID AX site?

mErilainen's picture

Should this module combo work with any OpenID account which is supporting AX attributes? There are some instructions how to get started with these modules here http://groups.drupal.org/node/24033, but there is only mentioned how to exchange profile information between two Drupal sites.

Does anyone know which OpenID provider supports AX attributes? I made an account to myopenid.com, but they support only SREG. I would like to use this account for testing. My goal is to use non-Drupal OpenID provider for AX attributes and create a Drupal installation as client.

OpenID a 'Trojan backdoor'?

ClearXS's picture

I WON'T use OpenID for some reasons (but Swekey instead). Nevertheless, this is positive feedback, because maybe something can be changed about OpenID to make it more secure for who needs security.

For Independent Media Centers, activists and some other users, it's not allowed to pass info (IP and other data) about users on to third parties.

An OpenID server could be abused to break into a Drupal installation. Like I have a Yahoo account and once-upon-a-time I've made an OpenID there, so if I enable the OpenID module of my site, then the ones that run Yahoo (British Royalty, secret service & their allies) could easily get into my account? Even with some securities; a chain is as strong as the weakest member; so one member with some privileges could infringe security for the whole site. Some users can have a very weak password on a third party server and I have no control over that, but causes a security infringement for the site and all its users.

So maybe its possible to -optionally, or by default to start with- cut off all OpenID servers and then specify which server(s) is(/are) allowed ONLY. Also a build-in control with permissions about what data exactly is or can be exchanged. And the same security for obligated complex passwords..?

Theoretically I'm thinking about a secure OpenID authentication site that could be used for activists, but then all other entrances and data communication must be possible to be excluded (on such servers: no-ip_log). If that would be(come) possible with OpenID, then it needs to work together with Swekey USB key hardware authentication, at least for the user roles with more permissions.

"so if I enable the OpenID

giorgio79's picture

"so if I enable the OpenID module of my site, then the ones that run Yahoo (British Royalty, secret service & their allies) could easily get into my account? Even with some securities; a chain is as strong as the weakest member; "

Maybe the entire web in general is not for you then since the internet was made by the US Army... :)

****Me and Drupal :)****
Clickbank IPN - Sell online or create a membership site with the largest affiliate network!
Review Critical - One of my sites

niccolox's picture

hi all

the original work by Alex has been continued and changed in scope

OmniAuth OpenID Single Signon - OpenID - Single Signon Lives (Sorta)

the out-dated but sophisticated OSSO (OpenID Simple (Not Single) Sign On) solution on github from Development Seed has been reworked and there are now two modules in sandbox and two install profiles thanks to http://drupal.org/user/359937 xamanu who is working on an installation profile called OmniAuth OpenID Single Signon

the Central American Drupal meetup just happened and there is a presentation in Spanish about this

the sandboxed modules

drush make http://gitorious.org/openid_sso/makefiles/blobs/raw/master/osso_provider...
drush make http://gitorious.org/openid_sso/makefiles/blobs/raw/master/osso_relying_ax.make