First, the trailing slash issue.  Yes, this was moved deliberately because 
there were some problems where the 
trust root included the trailing slash, but the return_to URL was lacking it.  
I figured the most sure fire way of 
handing this is to make the trust root NOT have the trailing slash, which will 
cover return_to URLs both with 
and without it.  When you say that redirecting from /wordpress to /wordpress/ 
"is not allowed", what are you 
referring to?  There is nothing in the spec that forbids this.  On the 
contrary, OpenID 2.0 says "Relying Parties 
SHOULD use the Yadis protocol to publish their valid return_to URLs."  Part of 
Yadis is following redirects when 
getting the XRDS document.

Regarding your second problem, are you trying to login to WordPress using some 
other OpenID, or are you 
trying to WordPress as your OpenID for logging in somewhere else?  Where does 
OpenID4Java fit in all this?  I 
take it you're using OpenID4Java for the other party (either provider or 
consumer)?  Does the WordPress 
plugin work when you try different [providers/consumers] ?

Sorry for not being clear enough.

I am using OpenID4Java for my OpenID provider.

I am trying to login with an id from this openid4java provider. I can login 
with a 
wordpress provided openID like [user].wordpress.com.

I got it to work by changing _createCheckAuthRequest in Consumer.php; however, 
I am 
not sure which side effects I am likely to encounter by doing this.

    function _createCheckAuthRequest($message)
    {
        $signed = $message->getArg(Auth_OpenID_OPENID_NS, 'signed');

        if ($signed) {
            foreach (explode(',', $signed) as $k) {
                $value = $message->getAliasedArg($k);
                if ($value === null) {
                    //hack to get it working return null;
                }

i like this