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. <br><br>But it can't be done the way you describe. There is one purpose to the additional redirect that Clickpass does.<br>
<br>I think it would help to think about it by considering from a users 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 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.<br>
<br>I think that key point adds a lot of complication. Do you think I am missing something?<br><br>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.<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 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 procedure *again* but this time with the intent to send additional SREG fields, that the user concented to (standard.. ish)<br><br>Its not great and the 3 further redirect at number 5 are a killer. I would love your thoughts on whether it could be simplified. I am missing out merging because that adds unnecessary complication.<br>
<br>So with this procedure only 4 is sitting in non-standard space. 4 is basically a declaration from the RP to the OP that the identifier they are given does not have an account on there service. <br><br>Thanks for your input Martin,<br>
<br>Immad<br><br><div class="gmail_quote">On Sat, Mar 15, 2008 at 6:15 AM, 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>
><br>
> - On SREG. I am actually looking at a way of doing signup using SREG for<br>
> Plaxo. The reason we avoided it, was that it didn't quite make sense to<br>
> ask the user to send that information until we actually know they want<br>
> to signup for the service and the way SREG was working on other<br>
> providers was confusing to users. Will let you know when we have a<br>
> better solution for this.<br>
><br>
<br>
</div>I believe that the standard SREG flow is actually equivalent from an<br>
end-user perspective if we ignore your "attach to an existing account"<br>
feature for a moment.<br>
<br>
Your flow:<br>
* User logs in at RP (either by clicking your button or by entering<br>
the identifier manually)<br>
* User is asked whether they want to create an account at the RP site<br>
and pass some personal information.<br>
* You send the user's SREG information to the RP.<br>
<br>
(note here that I'm skipping out any of your steps that are actually<br>
just redirects, since the user doesn't "see" those.)<br>
<br>
SREG flow:<br>
* User logs in at RP (either by clicking your button or by entering<br>
the identifier manually)<br>
* User is asked whether they want to create an account at the RP site<br>
and pass some personal information.<br>
* You send the user's SREG information to the RP.<br>
<br>
The only difference between these two flows is that your implementation<br>
does several additional redirects between the user's login initiation<br>
and the enrollment form. You won't be sending the user's information to<br>
the RP until the form is submitted on your enrollment page either way.<br>
The user remains in control, and you can do this in both 1.1 and 2.0<br>
transactions. This also requires no unusual callback endpoints at the<br>
RP, and users of other providers will see the SREG UI presented by their<br>
provider, rather than your custom UI.<br>
<br>
Now, if we throw your "attach to an existing account" UI into the mix<br>
then things get a little more interesting. However, you can still do<br>
this at the point where the SREG UI traditionally appears in the<br>
process, and then do your proprietary callback behind the scenes to<br>
create the user account before returning to the OP's endpoint as normal.<br>
The SREG response can be ommitted in this case.<br>
<br>
I gather that you need some sort of identifier in the request for the RP<br>
site's account on your system in order to enable the "attach to an<br>
existing account" functionality; you might consider supporting an<br>
alternative using the OpenID 2.0 extension mechanism, thus allowing RPs<br>
to make use of your full enrollment UI while avoiding the extra<br>
round-trips between Clickpass and the RP.<br>
<br>
This would just be some additional (optional) arguments in the initial<br>
request to your OP:<br>
openid.ns.clickpass=http://example.com/clickpass-extension<br>
openid.clickpass.site_key=Q3hPeoFgTb<br>
or something to that effect. This is, I admit, where we enter the realm<br>
of "not possible in OpenID 1.1", but your existing flow will presumably<br>
continue to work for 1.1 RPs while making things a little more efficient<br>
for 2.0 RPs. (fewer HTTP requests means less latency percieved by the<br>
user, and less data transfer expense for both you and the RP site.)<br>
<br>
Let me also add that although I may have presented my views thus far in<br>
a needlessly negative light, I do like what you're trying to do and I<br>
think your interface is one of the most straightforward I've seen. I<br>
only wish to point out what I percieve to be some of the suboptimal<br>
implementation details in your design, which I think you can fix without<br>
negatively-impacting the user experience and with benefits to you, to<br>
RPs and to end-users.<br>
<div><div></div><div class="Wj3C7c"><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>
</div></div></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