[OpenID] The complexity of OpenID, and imperfect RPs

[SitG Admin]

At 9:46 AM -0700 7/30/08, Andrew Arnott wrote:
>how to assure users that the right things are happening behind the 
>scenes at the RP so that he/she can trust the site.

Short of having some trusted third party audit the hardware, you're 
probably stuck with asking them for greater transparency in their 
implementation. I wrote a proposal for this back in April:
http://openid.net/pipermail/general/2008-April/004533.html

At 7:52 AM +1000 7/31/08, Shane B Weeden wrote:
>I would really like to see and contribute to a bunch of published 
>test cases which describe and expose common vulnerabilities and 
>implementation issues.

Some of these are already out there, just scattered instead of all 
gathered (or even linked to) in one place.

>What I am talking about is test cases or at least a guide/FAQ which 
>describes scenarios that expose common problems.

Snorri may have started to do some work on that, after making a 
similar suggestion in late May:
http://openid.net/pipermail/general/2008-May/004891.html
Following that thread through the next couple of messages, it seems 
that there was a reason this wasn't done back then. Johannes, how 
went the ongoing discussions?

At 11:00 AM +0100 7/31/08, James Tindall wrote:
>I suspect there will always be some developers who want to roll their
>own and so perhaps what's also needed is better documentation to help
>these developers write cleaner and more secure implimentations.

I could see a "proof-of-concept" implementation being done, not 
intended for real-life use cases but made to document its own 
processes at every step of the way; an *ideal* implementation, one 
that didn't make compromises for practical necessity or the desires 
of its developers. This would give a good baseline for variations 
from.

>A check list of common security
>vulnerabilities to test for would also be very usefull.

I'd like to have a testing OP and testing RP, actually, each with 
more than one site and more than one IP available from which to work; 
upon request, they would actually try out known attacks, acting as a 
hostile party with the permission (and active participation) of the 
developer.

-Shade