[OpenID] Clickpass: Making OpenId easier

Martin Atkins mart at degeneration.co.uk
Sat Mar 15 06:15:32 PDT 2008


Immad Akhund wrote:
> 
> - On SREG. I am actually looking at a way of doing signup using SREG for 
> Plaxo. The reason we avoided it, was that it didn't quite make sense to 
> ask the user to send that information until we actually know they want 
> to signup for the service and the way SREG was working on other 
> providers was confusing to users. Will let you know when we have a 
> better solution for this.
> 

I believe that the standard SREG flow is actually equivalent from an 
end-user perspective if we ignore your "attach to an existing account" 
feature for a moment.

Your flow:
  * User logs in at RP (either by clicking your button or by entering 
the identifier manually)
  * User is asked whether they want to create an account at the RP site 
and pass some personal information.
  * You send the user's SREG information to the RP.

(note here that I'm skipping out any of your steps that are actually 
just redirects, since the user doesn't "see" those.)

SREG flow:
  * User logs in at RP (either by clicking your button or by entering 
the identifier manually)
  * User is asked whether they want to create an account at the RP site 
and pass some personal information.
  * You send the user's SREG information to the RP.

The only difference between these two flows is that your implementation 
does several additional redirects between the user's login initiation 
and the enrollment form. You won't be sending the user's information to 
the RP until the form is submitted on your enrollment page either way. 
The user remains in control, and you can do this in both 1.1 and 2.0 
transactions. This also requires no unusual callback endpoints at the 
RP, and users of other providers will see the SREG UI presented by their 
provider, rather than your custom UI.

Now, if we throw your "attach to an existing account" UI into the mix 
then things get a little more interesting. However, you can still do 
this at the point where the SREG UI traditionally appears in the 
process, and then do your proprietary callback behind the scenes to 
create the user account before returning to the OP's endpoint as normal. 
The SREG response can be ommitted in this case.

I gather that you need some sort of identifier in the request for the RP 
site's account on your system in order to enable the "attach to an 
existing account" functionality; you might consider supporting an 
alternative using the OpenID 2.0 extension mechanism, thus allowing RPs 
to make use of your full enrollment UI while avoiding the extra 
round-trips between Clickpass and the RP.

This would just be some additional (optional) arguments in the initial 
request to your OP:
     openid.ns.clickpass=http://example.com/clickpass-extension
     openid.clickpass.site_key=Q3hPeoFgTb
or something to that effect. This is, I admit, where we enter the realm 
of "not possible in OpenID 1.1", but your existing flow will presumably 
continue to work for 1.1 RPs while making things a little more efficient 
for 2.0 RPs. (fewer HTTP requests means less latency percieved by the 
user, and less data transfer expense for both you and the RP site.)

Let me also add that although I may have presented my views thus far in 
a needlessly negative light, I do like what you're trying to do and I 
think your interface is one of the most straightforward I've seen. I 
only wish to point out what I percieve to be some of the suboptimal 
implementation details in your design, which I think you can fix without 
negatively-impacting the user experience and with benefits to you, to 
RPs and to end-users.



More information about the general mailing list