Kintera runs the web presence (a CRM system, essentially) for many grassroots and politically-oriented organizations. This is a great start - OpenID is well suited for dealing with the many-username/password problem that especially afflicts net-enabled grassroots activists.
Because local grassroots organizations are usually independent and operate "bottom up", a grassroots activist usually visits several web sites on a regular basis in the course of their political activities, many of which require authentication. A great example of such a site is PrecintCaptains.org - setup by the Democratic Party grassroots here in California to generate and manage contact lists for Democratic grassroots activists. Many people using this site are also members of the State Democratic Party Central Committee, or of a local Democratic club. Each of these roles requires a separate login and password, managed by a separate entity. But why should this be? If the user and the grassroots sites inherently place their trust in the Democratic Party (maybe thats a stretch...), why should that party be trusted as an OpenID ID provider?
I'd really like to see the state parties provide OpenID authentication so that the local organizations can leverage this user base for things like contact management, local blogging, and even fundraising. The state parties are in a unique position to provide this service because they are usually trusted by the local organizations that would rely on their OpenID authentication assertions. And for those organizations not affiliated with the state political parties, other issue organizations, such as environmental organizations, could agree rely on logins from OpenID IDPs run by each other or other common trusted providers. And local groups could also agree to rely on those assertions from the national orgs.
In short, the existing "real-world" relationships between political organizations, large and small, could be leveraged as an answer to the complaint that OpenID makes the relying party place blind trust in the IDP (party to which a user authenticates). This solution may not necessarily be the long term solution for all scenarios, but it could have immediate impact in the near term with relatively little effort on the part of the trusted (IDP) and trusting (RP) organizations involved.
And of course, everyone should be using inames, because its a heck of a lot easier to use than URLs ;-)