[OpenID] Clickpass: Making OpenId easier

Sat Mar 15 19:51:14 UTC 2008

What's really going on here is surely very, very similar to what happened as RPs moved from SAML1 libraries to SAML2 offloading servers in the SAML variant of websso. That is.. account linking previously performed exclusively by an RP site is slowly being moved into an intermediating server/provider, and into the openid standards arena -- if the procedures are to be standardized for anyone to use.

This seems an entirely natural evolutionary step for openid auth (by analogy with the earlier SAML effort on the same topic). 

RP "affiliation groups" would also fall out of the same move, naturally.

Not that I'm a member with any particular entitlement to be heard, I would certainly support standardization of such a process, in an openid embodiment. Presumably, it would take the form of another extension, allowing for the extra round trip between intermediary and RP during linkup - with appropriate state management.

----------------------

I can no seen reason why we - in our deployment community - would not happily supplement what we already do (below) when working with exclusively openid-enabled RPs. A prototype openid server doing some of the following already got deployed about a week ago, even:-

In our SAML2 "account linking/linkup" deployments leveraging "SP/RP affiliations" - upon first performing linkup to the primary RP in the RP-affiliation group "A", the nominated "lead RP" teaches the intermediary attribute store (CP.affiliation-group=A in the openid scenario) certain facts from the RP's attribute store for the member  (if any, and only if authorized by the end-user). This occurs after the user performs lead-RP local-login -- for the SPECIFIC purposes of (one-time) linkup. On any subsequent interaction, the intermediary account linking agent (CP#A) merges those static "provisioning" attributes with any and all attributes from the upstream OPs, when chaining assertions to any of the RPs in the subgroup of RP's affiliated with affiliation group X, according the pre-agreed merge rules for X (e.g. where X is the specific policy performed by CP#A).

Note: we had to extend our vendor's websso offloading server's product programatically to accomplish this, for **multiple** linked attributes (using the extensiblity points provided for this very purpose). This makes sense, as each RP affiliation group has its own set of  named attributes to be "co-provisioned". This hints that the ideal standard solution in openid protocol suite would perhaps leverage AX, not sreg.

From: Immad Akhund
Sent: Sat 3/15/2008 11:05 AM
To: Martin Atkins
Cc: general at openid.net
Subject: Re: [OpenID] Clickpass: Making OpenId easier

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?

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)

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.

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. 

Thanks for your input Martin,

Immad

On Sat, Mar 15, 2008 at 6:15 AM, Martin Atkins <mart at degeneration.co.uk> wrote:

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.

_______________________________________________
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/20080315/7573c6ae/attachment-0002.htm>