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.
Benefits:
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?
| Attachment | Size |
|---|---|
| Picture 1.png | 41.23 KB |
| Picture 2.png | 44.35 KB |
| Picture 3.png | 39.63 KB |