I've looked at a few of these, and I'm definitely interested, but I don't think it really applies on the smaller scale I'm thinking of. By centralizing the logins between applications it would allow us to use a single signon framework (without heroic effort), because it would only require updating one login method. But I don't think a single signon framework would be an expedient way to deal with the simpler problem of taking out authentication from individual web applications. I'm really looking for some minimal and logical language-independent authentication protocol -- which is why I'd like to use HTTP/CGI's conventions of $REMOTE_USER and the 401 response code. (And of course 403 Forbidden for permission denied -- unlike Zope with its wildly inappropriate use of 401 for permission denied.) Really the only reason I want it to be "logical" is because I feel that's a sign that the interface is going to continue to make sense in the future. And I hate implementing crufty workarounds, and I certainly hate modifying third-party products to add crufty workarounds, so it's psychological as well ;) No matter what this is going to require modifying other people's packages.
One thing to note with the technique I present is that it doesn't involve password anywhere, unlike many authentication systems. This property would be essential to using something like single signon, among other authentication methods, and I think it's a sign that it provides proper separation of responsibilities.