<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Martin Atkins wrote:<br>
<blockquote cite="midehn2n8$sp1$1@sea.gmane.org" type="cite">
<pre wrap="">The more I read your replies the more I get the impression that you
don't really understand the OpenID protocol flow. In particular, thue
"username/password pair" is OUT OF SCOPE FOR OPENID. How the IdP
authenticates the user, whether by username/password, a cookie, SSL
client cert, or even just "I know this client is on the same LAN as me",
is NOT SPECIFIED by OpenID. What *is* specified by OpenID is how the IdP
communicates the positive assertion back to the RP.
</pre>
</blockquote>
Well...you seem to be right, that this is not defined in the OpenID
standard, which is really another bad thing and perhaps it's time to
correct this now. If the IPD implements a sloppy authentication
facility (and data storage etc), than the relying parties are going to
suffer from this. The RP can't know, which are the good or bad IDP's
and therefore a standard and rules have to be implement,which define
exactly, what adequate protection of the facility - protection of the
transport protocol and so on, is....<br>
<br>
To implement a fancy protocol is really a cool thing to do, but not
thinking about the implications this may have is gross
negligence...This is here specially the case, because the standard
intends to provide single sing-on, which means, sign-on at your
preferred provider and use it everywhere. Today this are only a few
sites, tomorrow they may be in the thousands...<br>
<br>
So my suggestion is to actually define this things:<br>
<br>
Obviously a user URI and password alone isn't enough. I hear you
saying...oh no...But lets look at this in practical terms: Today I run
forum, which requires to provide a user name and password AND read a
sequence of letters and numbers from an image. Otherwise the forum will
be spamed by thousands of messages, and advertising of you know
what...(Remember that Forums and Blogs are your target audience for
now....)<br>
<br>
So if today such a spamer can get a URI from you, with just a user name
and password, than they will run their robots and create every 10
minutes a new user and post to all the OpenID enabled forums and blogs.
No chance for the forum operator blocking this users quick enough....<br>
<br>
Security on IDP's must be very high and login should preferable consist
of the user URI, a UserID (not the same as the URI identifier) and a
password. If the IDP login facility is protected adequately (i.e.
secure mode, https), then this sounds reasonable secured and I would
be able to to rely on that as an RP. Because the URI seems to be public
property, there must be three different parameters provided in order to
login (Similar to Windows Logon (i.e. Domain, User and Pass). Requiring
to read an image or similar would have to be required at registration.<br>
<br>
Even better would be certificate login, with that certificate stored on
a smart card or eToken. This would give similar or better protection of
the user authentication details, because of the real two-factor
authentication. Not just by chance are commercial providers (such as
Aladdin for example) providing single-sign-on solutions based on this
models....<br>
<br>
As Hans from Verisign pointed out earlier this month, in the future
there will be only serious IDP's providing services for OpenID.
However, if geeks, hackers, spamers and others can setup an OpenID
server, without any requirements, than they will just use it or might
be used by others to harass, spam and more...<br>
<br>
I even would suggest, that OpenID servers would need to register their
servers at the "OpenID Foundation" and provide details of their
facility and/or perform basic checks of this facilities. RP's would
need to check (at first visit and from time to time) with the OpenID
Foundation, if the server is registered and up to date to the required
specifications. <br>
<br>
I'd really like to hear, what the people from Verisign have to say
concerning all this suggestions....At last, I really don't care much
about early adopters, who are willing to risk their web sites and
services for OpenID. I think however, that proper definitions and rules
will accelerate the adoption by much more serious contenders than
LiveJournal....
<blockquote cite="midehn2n8$sp1$1@sea.gmane.org" type="cite">
<pre wrap="">
My take-away from this is that:
* The IdP MUST run an SSL server.
</pre>
</blockquote>
Yes!<br>
<blockquote cite="midehn2n8$sp1$1@sea.gmane.org" type="cite">
<pre wrap=""> * The RP MAY run an SSL server, but OpenID doesn't care either way
* The identity URL SHOULD be on an SSL server, but due to real-world
adoption problems early adopters will probably not use SSL. </pre>
</blockquote>
Who cares about early adopters really? Do you?<br>
<blockquote cite="midehn2n8$sp1$1@sea.gmane.org" type="cite">
<pre wrap="">Moving
forward, reputable IdPs could begin offering SSL-secured identity
URLs for a fee, which would cover costs of supplying a dedicated
IP address to the user, the extra computing power required to do SSL,
and perhaps a bundled SSL certificate. However, we are not yet at
the point where we can get away with mandating this.
</pre>
</blockquote>
There is no need for dedicated IP addresses, separation will be handled
at the scripting server side. Wild card certificates will cover all
URI's. "Extra computing power" because of SSL is a thing of the
nineties....I see fee based services of IDP's in different fields, but
that's another story really...<br>
<br>
<div class="moz-signature">-- <br>
<div><font face="Arial" size="2">Regards</font></div>
<div><font face="Arial" size="2"> </font></div>
<div><font face="Arial" size="2">Signer: Eddy Nigg, StartCom Ltd.</font></div>
<div><font face="Arial" size="2">Phone: +1.213.341.0390</font></div>
</div>
</body>
</html>