[OpenID] Clickpass: Making OpenId easier

Wed Mar 19 21:47:44 UTC 2008

I think that approach is exactly right and makes a lot of sense to me.

We can talk more on the specs list and get the details figured out.

We am excited about this approach and its definitely something Clickpass
would prefer and support.

Regards,
Immad

On Wed, Mar 19, 2008 at 1:44 PM, Martin Atkins <mart at degeneration.co.uk>
wrote:

> 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.
>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>

-- 
Cell: +1 617 460 7271
Skype: i.akhund
Blog: http://immadsnewworld.com

Clickpass, CTO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080319/a507c657/attachment-0002.htm>