[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