[OpenID] Backwards Compatibility

[SitG Admin]

>I would like to see us come together to create a unit test API so 
>that tests can be more automated.

You take that end, I'll take this end? API's are nice as a layer of 
abstraction covering up the messy internals (of an object), how to do 
them as a layer of transparency to make what's going on inside *more* 
apparent to learning developers?

>However tests like checking that the OP is prompting you with 
>a reasonable dialog in response to a AX attribute request can never 
>be entirely automated.

I was thinking of presenting dialog boxes from the OP for 'auditing' 
mode, where, instead of asking the user to authenticate, the user 
would be shown a page describing, step by step, how the URL was 
separated out into component values, and what would then be *done* 
with those values - but the values to be encoded for return would be 
placed in *input* (text) fields before the user, fully editable (also 
allowing developers to test for suspected vulnerabilities). Scripting 
on the page could enable the user to perform functions right there in 
their browser, such as calculating the hash for a string.

All those values would then be sent to the OP when the user was done 
looking through them, and the OP would print out a string (and link) 
of all those values for the user to inspect and copy into their 
address bar. (Involving a second page is important not just because 
the user might have scripting (which could probably make it happen) 
enabled, but because the user might not *trust* those scripts - so, 
of course, the hash calculations should *not* be automatic, there 
would be a button to do so and the relevant formulae would be printed 
out right beside it, so users could employ their own calculating 
methods if desired.) The signature would be done OP-side, 
appropriately keeping that private key out of the hands of the user, 
who could verify that it decoded to the expected value with the 
public key using another button on the second page. Of course, if the 
user changed any of the values from their default (expected) state, 
the OP might refuse to sign, and the *user* would have to supply a 
private key on their end to determine what value they would send in 
the "signature" field (or just send the hash itself, or an empty 
string) before seeing how the RP responded to this.

-Shade