<br>I think that approach is exactly right and makes a lot of sense to me.<br><br>We can talk more on the specs list and get the details figured out. <br><br>We am excited about this approach and its definitely something Clickpass would prefer and support.<br>
<br>Regards,<br>Immad<br><br><div class="gmail_quote">On Wed, Mar 19, 2008 at 1:44 PM, Martin Atkins <<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Immad Akhund wrote:<br>
> I think we are getting somewhere now. I completely agree, I would love<br>
> to make it so the experience would site completely within SREG or<br>
> attribute exchange, and I think it is possible.<br>
><br>
> But it can't be done the way you describe. There is one purpose to the<br>
> additional redirect that Clickpass does.<br>
><br>
> I think it would help to think about it by considering from a users<br>
> perspectives there are three paths on openid authentication.<br>
><br>
> 1. User has an openid account at RP and wants to login.<br>
> 2. User has a non-openid account at RP and wants to merge.<br>
> 3. User has no account at RP and wants to signup.<br>
><br>
> To make a smooth experience clickpass needs to know exactly which path<br>
> the user wants to take, we don't want to ask the user to signup if they<br>
> already have an account. In the case of 2/3 we can just ask the user.<br>
> But the case of 1 is not catered for in OpenID protocols. The last<br>
> openid redirect to the RP must happen before the RP knows the full<br>
> openid identifier for the user and verify whether there account already<br>
> exists or not. And if it doesn't then they redirect to us.<br>
><br>
> I think that key point adds a lot of complication. Do you think I am<br>
> missing something?<br>
<br>
</div>This is a very good point and I believe that you are correct that this<br>
is currently a weak point in the SREG flow.<br>
<br>
Currently, the directed identity flow leaves the OP responsible for<br>
"remembering" which sites have been signed into previously and what<br>
identifier was used on those sites. This clearly has a few issues, however:<br>
* No existing provider I know of actually does this. They just show<br>
the SREG fields every time.<br>
* It makes it more difficult for users to switch providers.<br>
<div class="Ih2E3d"><br>
> Here is the solution that I have been thinking through in my head and<br>
> what I will implement soon. It will sit better within SREG but its not<br>
> perfect.<br>
><br>
> (cp=clickpass)<br>
><br>
> 1. User enters openid at RP. (standard)<br>
> 2. RP redirects to CP (standard)<br>
> 3. If openid is verified, CP shows no intermediate screens and redirects<br>
> to RP (standard)<br>
> 4. RP checks if user has an account if not it redrects to CP.<br>
> 5. At CP if user wants to signup then CP begins standard OpenID<br>
> procedure *again* but this time with the intent to send additional SREG<br>
> fields, that the user concented to (standard.. ish)<br>
<br>
</div>This looks like it'd work, but of course it does not work with current<br>
practice by other providers. With the above flow on LiveJournal (for<br>
example), the user will be prompted to approve the OpenID request twice,<br>
and neither request will result in registration fields because<br>
LiveJournal doesn't currently support SREG.<br>
<br>
Having pondered this a bit, I now agree with you that in order to give a<br>
good user experience it's useful to get the RP involved between the<br>
successful authentication and the presentation of the SREG UI.<br>
<br>
I think with just some minor additions to SREG we can support your above<br>
flow in a way that does not create a suboptimal flow on existing<br>
implementations. The extension involves an extra flag on the initial<br>
request indicating that the RP would like to do a delayed enrollment. If<br>
the OP supports delayed enrollment, it'll completely ignore the<br>
traditional SREG request fields and return a flag acknowledging that it<br>
supports delayed enrollment.<br>
<br>
At this point the RP must check its records as in your step four, and if<br>
the identifier is not known the user is then asked if he wishes to<br>
create a new account or associate with an existing one. This'll look a<br>
lot like Clickpass's initial enrollment page, but is provided by the RP<br>
rather than the OP. If the user elects to create a new account, a new<br>
OpenID authentication request is sent to the OP with another flag set<br>
indicating that this request is for delayed enrollment, for which the OP<br>
must present only the SREG UI.<br>
<br>
The "bind to existing account" step is, in my scheme, handled by the RP<br>
without the OP's interation. This seems acceptable, because in this case<br>
the RP does not need SREG information from the OP.<br>
<br>
I've attached what might be the ugliest flowchart in the history of<br>
flowcharts showing the above flow graphically.<br>
<br>
Of course, sites making use of the Clickpass enrollment UI will redirect<br>
to the appropriate Clickpass URLs at the points where the RP would<br>
normally present UI. Non-Clickpass RPs would be free to present their<br>
own UI, however.<br>
<br>
If Clickpass recieves an initial request that does not contain the<br>
delayed enrollment request flag but does contain SREG request fields, it<br>
should present the registration UI immediately to support legacy RPs<br>
that do not do delayed enrollment.<br>
<br>
An RP must make a decision on how to support legacy OPs without delayed<br>
enrollment support. The two options are:<br>
* Include no SREG request fields in the initial request, and then<br>
present a local enrollment UI if the OP does not indicate delayed<br>
enrollment support. This is the most likely option, since RPs will<br>
presumably already have such a UI to deal with OPs that do not support<br>
SREG at all.<br>
* Include all of the required SREG request fields in the initial<br>
request, thus allowing legacy OPs to return the registration data but<br>
with the caveat that the OP will present its SREG UI even to<br>
already-enrolled users. Non-legacy OPs will see the delayed enrollment<br>
request flag and will ignore the rest of the SREG fields.<br>
<br>
Does this seem like a workable protocol flow to you?<br>
<br>
If you're interested in fleshing something like this out into a full<br>
spec, we could continue this discussion on the "specs" mailing list.<br>
<br>
<br>
<br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Cell: +1 617 460 7271<br>Skype: i.akhund<br>Blog: <a href="http://immadsnewworld.com">http://immadsnewworld.com</a><br><br>Clickpass, CTO