OpenID status update

[Brad Fitzpatrick]

Update on OpenID status.  No real focus... I'll bounce all over.
Apologies in advance for the length.

LiveJournal consumer support: functionally complete.  Any OpenID user can
login to LiveJournal (using the code in cvs, not yet on livejournal.com)
and leave comments and read friends-only posts (so yes, OpenID users can
be befriended).  They can also add their own friends, be banned, trusted,
read, filtered, etc.  They're just a stripped-down LJ account that isn't
in the namespace and doesn't have access to their own journal and a lot of
the features.  In the future we'll be picking up their RSS/Atom feed and
start syndicating it onto the site, so when they're befriended,
LiveJournal's "friend's page" aggregator shows their entries.  Likewise
with FOAF/userpic being sucked/resized into their profile.

LiveJournal server support: rewrote it today to use Net::OpenID::Server,
and checked it into cvs.  Not yet live. Previously I'd done it all
piecemeal before there was a library.  (the current live version is that
ugly version, which is why it never went into cvs)

TypeKey server support: functionally complete.  I don't control the
release cycle, so I have no clue when it'll go live, though.  But I logged
into my local LiveJournal install using my local TypeKey install, so
that's exciting.  To clarify: the TypeKey service will speak both TypeKey
protocol (1.0 and 1.1) and OpenID.

Movable Type server support: Brad Choate had made an MT plugin to make any
MT install be an identity server, and it was done before
Net::OpenID::Server.  Today he ported it to Net::OpenID::Server and was
able to login to my local LJ box.

I was also able to login to my dev box using my DeadJournal account, and
render the head icon like a little skull, like DeadJournal does. (this
isn't OpenID-specific: OpenID consumers can do whatever they please,
UI-wise)

So I've scratched my itch: TypeKey, Movable Type, DeadJournal, and
LiveJournal can all play together.  It's not live yet, but I know it
works.  Ideally more sites will start using OpenID, but that's outside my
world of influence.

The cool thing about all 3 of LJ, TypeKey, and Movable Type server support
is that they're barely any code.  If we change some small details about
the protocol, it's almost no work to update the apps.

Yeah... yay libraries, yay code-reuse, I know.  But what's more exciting
is that we now have those libraries.  Java and (almost?) PHP
consumers/servers are working.  Get some Python and Ruby and pretty much
everybody should be happy.

Which brings me to protocol changes: I'm not going to pretend to be a
security/crypto expert, so I'm going to give you all a couple weeks to
come to general agreement (and/or convince me) about what changes need to
be made to the protocol.

Let me lay out my requirements:

-- it should be practical.  The phishing stuff sucks, I agree, but
   it's not a war I want to fight.  Telling users to use bookmarks or
   type URLs... just not going to happen.  Clients are starting to get
   smarter:  Thunderbird has some anti-phishing stuff built-in.  Expect
   more from Firefox extensions and IE7, coming out soon.  This is an
   industry problem, not exclusively ours.  (though Paul, I do
   recognize how worse it is for OpenID... perhaps I'll make a
   bookmarklet for LiveJournal users to use... select some text, click
   bookmarklet, get logged in... but that's an issue each identity
   server has to decide to care about or not)

-- The overall flow of the protocol must remain the same.  For
   instance, the checkid_immediate vs. checkid_setup distinction must
   stay.  (the checkid_immediate is key for "AJAX" consumers)

-- If we need to add expiry, multiple/named public keys, that's fine.

-- DSA's fine: it can be checked relatively easily in any language
   with big integer support.  Easy consumer support is what I mostly
   care about.  Server support can be a little more invasive when it
   comes to libraries and such.  For instance, I don't care how
   fast/easy it is to generate keypairs doing large integer primality
   testing in Pure Perl/Ruby/PHP/etc.  People can generate their keys
   on their desktop/server with other programs and upload them:

      openssl dsaparam -outform PEM -out openid.param -genkey 1024
      openssl dsa -in openid.param -pubout -out openid-public.pem
      openssl dsa -in openid.param         -out openid-private.pem
      rm openid.param

-- No encryption in the core.  We'll need to use RSA to do credential
   passing later for things like passing "AtomAPI_posting_rights"
   credentials to sites like flickr, but that's an extension ABOVE
   OpenID.  The OpenID core is dumb and simple and I don't want to
   encumber its exportability/legality by throwing encryption into the
   mix.  The great thing about DSA is that it can only sign, so more
   governments (presumably) don't mind it.  And it's easier to check
   than RSA signatures, I've heard?  No clue.  But no RSA or
   encryption in the core, just to be safe.

-- I don't like the idea of things being passed along in the clear
   anywhere.  Even if we're all right that it's easier to actively interfere
   than sniff, look how much we've all been arguing over it.  Could
   OpenID be respected/accepted if it had such an obvious hole, even if it
   wasn't practically a problem?  I doubt it.  I think people would spread
   the FUD, warranted or not.  I'd rather do DSA "right", however that is.
   (Paul, I'm all ears!)

-- Diffie-Hellman for shared-secret exchange gets consumers to the
   point that they're already doing bigint stuff, so why not DSA?
   Sure, the later steps are easier in HMAC-SHA1 (just some SHA1s, not
   the Base64/ASN1/PEM decoding), but it only needs to be done once
   per language, and it's already been done for Perl, Java, and PHP,
   so I don't think it's that hard.

I don't want to be rash, but I am the most impatient guy you'll likely
ever meet.  I want to put this out there and let people start enjoying
it, but I recognize Paul and others' concerns that this might become a
defacto standard before we have time to change it, so I do want help in
doing this right.

So... I'm not going to put it live on LiveJournal.com for a bit.  But
when I say "a bit", I really do mean a bit.

I don't have the necessary crypto background to do this on my own, and
all my code/work is essentially done at this point, so I'm doing all I
can to not push this live on LiveJournal /tonight/.

If you care about me fixing something in OpenID, think practically and
let me know what the easiest things to add/change are to make it more
secure.  I don't want this to turn into a never-ending discussion, a
bloated spec, or something it's not (bank-grade security).

To repeat:

-- I'm ignoring the phishing problems, unless something trivially
   obvious/easy is proposed that puts no burden on users.

-- I think DSA is easiest going forward, since secrets in the clear doesn't
   look good on paper.  But perhaps it's okay to send them in the clear,
   and the answer is that identity servers that care can use https?  And
   it's up to each identity server to choose their security level? If so,
   I need details/URLs of how to do the HMAC-SHA1 work so I can think it
   out more.  The only reason I'm even considering HMAC-SHA1 instead of
   DSA (or DSA "done right") is that it'll potentially be easier on
   programmers doing consumers/servers.  But I'm also torn seeing that it
   isn't that hard and only needs to be done once.

In the next couple days I'll fill my time working on the website and a
list of implementation guidelines for both consumers and servers,
naming/numbering each thing to look out for, and making a validation tool
that takes a zip/tarball and greps the code for comments indicating the
declared conformance/recognition of each issue.

So we'll be able to take some-ruby-openid-consumer-0.5.0.tar.gz, run
the analyzer, and it'd find in the source comments like:

  // OpenID-AmbigLoop: NA - we don't ack external URLs

Or:

  # OpenID-NoDoubleColon: ACK
  # OpenID-KeepExistingURLArgs: ACK

Then it'd show a report of all currently-documented best practices for
either a consumer or server and how many of those a given library
declares that it handles, or says aren't applicable (with optional
notes why).

Programmers can put these all over the code, or just in one master
file.  All the best practices will then be documented on the website.

In conclusion: how do you guys all want this project managed?  It's
easy for me to a dick/dictator and say no to feature-creep that
doesn't belong in OpenID, but it's a lot harder for me to do so when
it comes to security issues, since I know I'm out of my league.  Any
ideas?  If not, I'll default to sitting back and watching the list and
just hoping I choose right in the end.  But if alternative management
styles are known to be effective, I'm all ears.

Thanks for reading...

- Brad