Securing HTML vs securing HTTP

[Kevin Turner]

On Sun, 2006-01-22 at 09:59 -0800, Jens Alfke wrote:
> That's a lot of stuff I have to trust. Now, it's very unlikely that a  
> release version of an open-source project like Drupal would contain  
> malicious code.

There's a pretty straightforward way to address this concern.  If you
don't believe the code that generates your dynamic web page is
trustworthy enough for your identity, don't use it.  Instead of putting
your identity URL at http://mooseyard.com/Jens/ , why not
http://mooseyard.com/o , where "o" is a static page?  Personally, I find
little utility in having the identifier I authenticate by as being
precisely the same as the URL for my blog.

If you don't trust code, don't use it.  Run other code, run less code,
or trust a third party to provide this service for you.  Attempting to
make a protocol like this trustworthy in a totally insecure environment
is probably not a productive exercise.

But there is a point here I think is important: While I would like
OpenID to be as widespread as possible, it's probably true that not
every web application out there should be an OpenID *server*.  I wrote
consumer support for MoinMoin, and someone requested server
functionality as well, to facilitate some InterWiki operations.  But
having just worked with their authentication code, I don't believe
that's a good idea.  It's not exactly what I would call
security-conscious.  Given MoinMoin's history as a wiki that only gained
access control midway through its life, this is quite understandable and
probably acceptable.  For a wiki.  Just not for a global authentication
system.

So I'm glad to hear that you're being discriminating in where you deploy
your OpenID hosting.

Cheers,

 - Kevin
   openidenabled.com