[OpenID] Clickpass: Making OpenId easier

Tue Mar 18 06:08:53 UTC 2008

Until users need not at 9am type in their own url or Rapattoni's OP URL
n=6 times for each of the n=6 subscriptions they maintain with an OpenID
RP, my first pilot community has advised me that : openid is rejected.
This is a setback. Its not deterring me yet - as there are solutions
with the standard, I feel.

Rather than whine any more, perhaps I should make a campaign for
standards adoption by subscription-based RPs (in the AX area). Technical
info follows. I'd love to see clikpass support me in an endeavour such
as the following:-

---------

Concerning,
http://openid.net/specs/openid-attribute-exchange-1_0.html#fetch_request
, the update URL, and the normative text 

The relying party may include transaction data encoded in the URL such
that it contains enough information to match the attribute information
to the identity subject. Additional information may be encoded in the
URL by the relying party as necessary.

Application of update URL requires that an end-user be in interactive
control of the fetch_response, performing update. And, the semantics of
any positive authentication is such that an RP is surely entitled to
also create a user session on one or more services in the RP's trust
realm.

If we set a convention that an AX-supporting RP does register an update
URL and noting the user is in control of "updating attributes", does
anyone object to an RP also creating user sessions?

Would anyone object to revision of the standard to specify that such
session management is an disclosed, standard feature (of, legally, the
"finalized specifications")?

I'm tempted to define a AX attribute called "givemesessions=true" that a
user may release to indicate the desire to obtain a session on the RP's
choice of  landing page/service, once the attribute update process has
concluded.

To allow the use of (SAML2-style) SP affiliation groups, givemesessions
in namespace X, Y and Z (one per SP-affiliation group) can have meaning
only to those RPs licensed to use the particular AX namespace X (or Y,
or Z) - allowing for federated trust models to be imposed on subsets of
openid-capable endpoints. Namespace identifier generation procedures may
also leverage public-key cryptographic names, to authorize, control and
enforce access to one or more SP-affiliation groups, obviously.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Immad Akhund
Sent: Friday, March 14, 2008 12:27 PM
To: Martin Atkins
Cc: general at openid.net
Subject: Re: [OpenID] Clickpass: Making OpenId easier

HI Martin,

I read your blog post this morning, and I thought it was thoughtful and
to the point. You have obviously taken time out to fully understand what
Clickpass does before posting and thats much appreciated. Your two
paragraph was probably more succinct then anything we have written.

To put this into context, we started Clickpass in June (before OpenID
2.0), and with the main purpose of making OpenID a more user friendly
experience, while keeping within the standard as much as possible. So to
answer your concerns:

	* I strongly encourage you to implement OpenID 2.0 and use
directed
	identity to implement your login button. This will make it
easier for
	sites to accept your users without entering an explicit
partnership with
	you.

We started before OpenID 2.0 was launched, also we weren't sure how fast
it  would get adopted and there are definitely some frameworks where the
libraries are still not in place. Having said that I am really keen to
implement Clickpass as an OpenID 2.0 provider and its at the top of my
priority list, hopefully we will have something out soon.

	  * You could do with some minimal instructions at your site
telling
	your users how to deal with login forms that are not
specifically
	Clickpass-enabled. Unless you're planning to parter with every
RP under
	the sun, your users are going to encounter this eventually.

One of the aims with Clickpass was to try to get normal people to use
OpenID without them needing to understand how it works. I think once we
enable OpenID 2.0 we will definitely add more user education on how it
can be used at other RPs, so point taken. 

The last thing to say about the Clickpass button is that the idea was
very much to allow people to use whatever OpenID they want to use with
it, or let us manage there various OpenIDs at sites. We have had a lot
of people tell us that its a good solution, and we have shown it a lot
of people, even people who don't know OpenID and they have been very
happy with the experience.

You are correct to separate the enrollment UI as completely separate to
the Clickpass button. (I am grouping SREG here).

Firstly I completely agree, our solution is not ideal. Ideally I would
prefer to not ask user for their passwords to third party services and
ideally I would like to use SREG. And We are working on coming up
solutions to this. But firstly why we did it this way:

Most significant RPs have existing user accounts, even new ones that
role out will most likely keep username/password systems in place, but
what we found was that RPs dont deal with merging and signing up well at
all. This puts off people trying OpenID. If you try out how Plaxo or
Magnolia (two of the better implemented versions) do it and imagine
going through that procedure without knowing in-depth what OpenID is you
will see our point.

- This led us to make the merge screen. Again ideally we would like to
not be asking for usernames/passwords for third parties, but this was
the quickest and simplest way of doing it, most users are already
trained by facebook and other services so we didn't think we would be
making a big dent in that process. I think we can probably come up with
a better solution in the future using OAuth.

- 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 think we can do better at explaining some of these decisions on our
website, and we will be launching a blog today to help. I hope we can
continue to adapt and come up with more satisfying ways of achieving
ease of use. I would love to hear more feedback from you and what other
ideas you might have. 

Thanks,

Immad

On Fri, Mar 14, 2008 at 1:55 AM, Martin Atkins <mart at degeneration.co.uk>
wrote:

Immad Akhund wrote:
> Hi,
>
> I am Immad, CTO of Clickpass. We just launched today, and I would love
> to get feedback from you guys. I am sure many of you would have
already
> seen it, but if you haven't this is Clickpas;
>
> http://www.clickpass.com  (tc:
>
http://www.techcrunch.com/2008/03/11/clickpass-could-change-the-way-you-
surf-the-web/)
>

Hi Immad,

I actually spent some time looking at Clickpass yesterday, though I
hadn't yet seen this thread so instead I posted what I think in
retrospect is an overly-emotional blog entry[1].

I'll restate some of my main concerns here more succinctly.

As far as I can tell, you actually have two basically-separate products:
an OpenID 1.1 provider, and some reusable enrollment UI.

Regarding the OpenID Provider:

 * I strongly encourage you to implement OpenID 2.0 and use directed
identity to implement your login button. This will make it easier for
sites to accept your users without entering an explicit partnership with
you.

 * I also encourage you to implement the Simple Registration Extension
so that sites do not have to create a special-case endpoint in order to
give your users a good enrollment experience. Many sites already have
the machinery in place to support SREG; you can, of course, still
support your proprietary registration protocol for sites that do not
implement SREG.

 * You could do with some minimal instructions at your site telling
your users how to deal with login forms that are not specifically
Clickpass-enabled. Unless you're planning to parter with every RP under
the sun, your users are going to encounter this eventually.

Regarding the enrollment UI:

 * PLEASE find a way to do the account linking thing that doesn't
involve asking users to enter their RP credentials on *your* domain.

[1] http://www.apparently.me.uk/13547.html

_______________________________________________
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/20080317/50809f16/attachment-0002.htm>