[OpenID] Clickpass: Making OpenId easier

[Martin Atkins]

Immad Akhund wrote:
> I think we are getting somewhere now. I completely agree, I would love 
> to make it so the experience would site completely within SREG or 
> attribute exchange, and I think it is possible.
> 
> But it can't be done the way you describe. There is one purpose to the 
> additional redirect that Clickpass does.
> 
> I think it would help to think about it by considering from a users 
> perspectives there are three paths on openid authentication.
> 
> 1. User has an openid account at RP and wants to login.
> 2. User has a non-openid account at RP and wants to merge.
> 3. User has no account at RP and wants to signup.
> 
> To make a smooth experience clickpass needs to know exactly which path 
> the user wants to take, we don't want to ask the user to signup if they 
> already have an account. In the case of 2/3 we can just ask the user. 
> But the case of 1 is not catered for in OpenID protocols. The last 
> openid redirect to the RP must happen before the RP knows the full 
> openid identifier for the user and verify whether there account already 
> exists or not. And if it doesn't then they redirect to us.
> 
> I think that key point adds a lot of complication. Do you think I am 
> missing something?

This is a very good point and I believe that you are correct that this 
is currently a weak point in the SREG flow.

Currently, the directed identity flow leaves the OP responsible for 
"remembering" which sites have been signed into previously and what 
identifier was used on those sites. This clearly has a few issues, however:
  * No existing provider I know of actually does this. They just show 
the SREG fields every time.
  * It makes it more difficult for users to switch providers.

> Here is the solution that I have been thinking through in my head and 
> what I will implement soon. It will sit better within SREG but its not 
> perfect.
> 
> (cp=clickpass)
> 
> 1. User enters openid at RP. (standard)
> 2. RP redirects to CP (standard)
> 3. If openid is verified, CP shows no intermediate screens and redirects 
> to RP (standard)
> 4. RP checks if user has an account if not it redrects to CP.
> 5. At CP if user wants to signup then CP begins standard OpenID 
> procedure *again* but this time with the intent to send additional SREG 
> fields, that the user concented to (standard.. ish)

This looks like it'd work, but of course it does not work with current 
practice by other providers. With the above flow on LiveJournal (for 
example), the user will be prompted to approve the OpenID request twice, 
and neither request will result in registration fields because 
LiveJournal doesn't currently support SREG.

Having pondered this a bit, I now agree with you that in order to give a 
good user experience it's useful to get the RP involved between the 
successful authentication and the presentation of the SREG UI.

I think with just some minor additions to SREG we can support your above 
flow in a way that does not create a suboptimal flow on existing 
implementations. The extension involves an extra flag on the initial 
request indicating that the RP would like to do a delayed enrollment. If 
the OP supports delayed enrollment, it'll completely ignore the 
traditional SREG request fields and return a flag acknowledging that it 
supports delayed enrollment.

At this point the RP must check its records as in your step four, and if 
the identifier is not known the user is then asked if he wishes to 
create a new account or associate with an existing one. This'll look a 
lot like Clickpass's initial enrollment page, but is provided by the RP 
rather than the OP. If the user elects to create a new account, a new 
OpenID authentication request is sent to the OP with another flag set 
indicating that this request is for delayed enrollment, for which the OP 
must present only the SREG UI.

The "bind to existing account" step is, in my scheme, handled by the RP 
without the OP's interation. This seems acceptable, because in this case 
the RP does not need SREG information from the OP.

I've attached what might be the ugliest flowchart in the history of 
flowcharts showing the above flow graphically.

Of course, sites making use of the Clickpass enrollment UI will redirect 
to the appropriate Clickpass URLs at the points where the RP would 
normally present UI. Non-Clickpass RPs would be free to present their 
own UI, however.

If Clickpass recieves an initial request that does not contain the 
delayed enrollment request flag but does contain SREG request fields, it 
should present the registration UI immediately to support legacy RPs 
that do not do delayed enrollment.

An RP must make a decision on how to support legacy OPs without delayed 
enrollment support. The two options are:
  * Include no SREG request fields in the initial request, and then 
present a local enrollment UI if the OP does not indicate delayed 
enrollment support. This is the most likely option, since RPs will 
presumably already have such a UI to deal with OPs that do not support 
SREG at all.
  * Include all of the required SREG request fields in the initial 
request, thus allowing legacy OPs to return the registration data but 
with the caveat that the OP will present its SREG UI even to 
already-enrolled users. Non-legacy OPs will see the delayed enrollment 
request flag and will ignore the rest of the SREG fields.

Does this seem like a workable protocol flow to you?

If you're interested in fleshing something like this out into a full 
spec, we could continue this discussion on the "specs" mailing list.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: SREG Delayed Enrollment.png
Type: image/png
Size: 41893 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080319/4f1f1593/attachment-0002.png>