<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.nfakpe
{mso-style-name:nfakpe;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1434326986;
mso-list-type:hybrid;
mso-list-template-ids:1821251398 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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:-<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>---------<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Concerning, <a
href="http://openid.net/specs/openid-attribute-exchange-1_0.html#fetch_request">http://openid.net/specs/openid-attribute-exchange-1_0.html#fetch_request</a>,
the update URL, and the normative text <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span lang=EN style='font-size:
10.0pt;font-family:"Verdana","sans-serif";color:black'>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.</span><span style='font-size:10.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Would anyone object to revision of the standard to specify that
such session management is an disclosed, standard feature (of, legally, the “finalized
specifications”)?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces@openid.net [mailto:general-bounces@openid.net] <b>On Behalf Of </b>Immad
Akhund<br>
<b>Sent:</b> Friday, March 14, 2008 12:27 PM<br>
<b>To:</b> Martin Atkins<br>
<b>Cc:</b> general@openid.net<br>
<b>Subject:</b> Re: [OpenID] Clickpass: Making OpenId easier<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>HI Martin,<br>
<br>
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 <span
class=nfakpe>Clickpass</span> does before posting and thats much appreciated.
Your two paragraph was probably more succinct then anything we have written.<br>
<br>
To put this into context, we started <span class=nfakpe>Clickpass</span> 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:<o:p></o:p></p>
<div>
<div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p>
<p class=MsoNormal>* I strongly encourage you to implement OpenID 2.0 and use
directed<br>
identity to implement your login button. This will make it easier for<br>
sites to accept your users without entering an explicit partnership with<br>
you.<o:p></o:p></p>
</blockquote>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>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 <span class=nfakpe>Clickpass</span> as an OpenID 2.0
provider and its at the top of my priority list, hopefully we will have
something out soon.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal> * You could do with some minimal instructions at your
site telling<br>
your users how to deal with login forms that are not specifically<br>
<span class=nfakpe>Clickpass</span>-enabled. Unless you're planning to parter
with every RP under<br>
the sun, your users are going to encounter this eventually.<o:p></o:p></p>
</blockquote>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>One of the aims with <span
class=nfakpe>Clickpass</span> 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. <br>
<br>
The last thing to say about the <span class=nfakpe>Clickpass</span> 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.<o:p></o:p></p>
</div>
<p class=MsoNormal>You are correct to separate the enrollment UI as completely
separate to the <span class=nfakpe>Clickpass</span> button. (I am grouping SREG
here).<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<br>
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:<o:p></o:p></p>
</div>
<p class=MsoNormal>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.<br>
<br>
- 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.<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<br>
- 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.<br>
<br>
<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'>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. <br>
<br>
Thanks,<br>
<span style='color:#888888'><br>
Immad</span><o:p></o:p></p>
<div>
<p class=MsoNormal>On Fri, Mar 14, 2008 at 1:55 AM, Martin Atkins <<a
href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>> wrote:<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>Immad Akhund wrote:<br>
> Hi,<br>
><br>
> I am Immad, CTO of Clickpass. We just launched today, and I would love<br>
> to get feedback from you guys. I am sure many of you would have already<br>
> seen it, but if you haven't this is Clickpas;<br>
><br>
> <a href="http://www.clickpass.com" target="_blank">http://www.clickpass.com</a>
(tc:<br>
> <a
href="http://www.techcrunch.com/2008/03/11/clickpass-could-change-the-way-you-surf-the-web/"
target="_blank">http://www.techcrunch.com/2008/03/11/clickpass-could-change-the-way-you-surf-the-web/</a>)<br>
><o:p></o:p></p>
</div>
<p class=MsoNormal>Hi Immad,<br>
<br>
I actually spent some time looking at Clickpass yesterday, though I<br>
hadn't yet seen this thread so instead I posted what I think in<br>
retrospect is an overly-emotional blog entry[1].<br>
<br>
I'll restate some of my main concerns here more succinctly.<br>
<br>
As far as I can tell, you actually have two basically-separate products:<br>
an OpenID 1.1 provider, and some reusable enrollment UI.<br>
<br>
Regarding the OpenID Provider:<br>
<br>
* I strongly encourage you to implement OpenID 2.0 and use directed<br>
identity to implement your login button. This will make it easier for<br>
sites to accept your users without entering an explicit partnership with<br>
you.<br>
<br>
* I also encourage you to implement the Simple Registration Extension<br>
so that sites do not have to create a special-case endpoint in order to<br>
give your users a good enrollment experience. Many sites already have<br>
the machinery in place to support SREG; you can, of course, still<br>
support your proprietary registration protocol for sites that do not<br>
implement SREG.<br>
<br>
* You could do with some minimal instructions at your site telling<br>
your users how to deal with login forms that are not specifically<br>
Clickpass-enabled. Unless you're planning to parter with every RP under<br>
the sun, your users are going to encounter this eventually.<br>
<br>
Regarding the enrollment UI:<br>
<br>
* PLEASE find a way to do the account linking thing that doesn't<br>
involve asking users to enter their RP credentials on *your* domain.<br>
<br>
[1] <a href="http://www.apparently.me.uk/13547.html" target="_blank">http://www.apparently.me.uk/13547.html</a><o:p></o:p></p>
<div>
<div>
<p class=MsoNormal><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><o:p></o:p></p>
</div>
</div>
</div>
<p class=MsoNormal><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 <o:p></o:p></p>
</div>
</div>
</body>
</html>