[OpenID] Clickpass: Making OpenId easier

Wed Mar 19 19:57:15 UTC 2008

Hi Peter,

Sorry for the delayed response.

I think one of the strengths of OpenID is its simplicity and its probably
not the right time to jump in and try to extend the standards to cover
account linking and sign-up.

Also the standardized solution would have to be more complex in order to
avoid the issue we have of asking users for there usernames/password for
third party services on the OP domain.

Having said that we would love it if this process was partially or fully
standardized and would support and take part in any process that tries to do
that if the OpenID community is in favor of it. As we were discussing, it
can be made to use SREG better, and maybe further discussion and
experimentation will help us find a better system.

In terms of your suggestion, I don't quite understand what you mean by
"subscription-based RPs" and quite a few of the other terms you use. It is
probably more constructive to meet up and discuss things in person and I am
sure we would be happy to work with you.

Thanks,
Immad

On Mon, Mar 17, 2008 at 11:08 PM, Peter Williams <pwilliams at rapattoni.com>
wrote:

>  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
>
> _______________________________________________
> 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/22717b30/attachment-0002.htm>