Visit liqd.de

OpenID Voter Register Extensions

From LiquidDemocracy

Note: This page should be written in English to have a reference for communications with the standardizing group at axschema.org

This document is an attempt to create a common standard for communicating organizational membership and status of an OpenID end user to a relying party. Specifically, the availability of voting rights to the user in implementations of Liquid Democracy will be communicated via this schema extension.

Contents

[edit] Context

The Piratenpartei party is currently evaluating the adoption of various online voting and discussion tools in order to allow online participation of all party members in various decision-making processes. Since the Piratenpartei is both a strong supporter of open standards and a distributed organization (due to the German federal system, membership is managed by 16 state party offices), OpenID will be used for party members to authenticate with any online voting system. In this scenario, the party state offices and state secretaries (Generalsekretäre) will serve as OpenID providers (OPs), the voting systems will be consumers, i.e. relying parties (RPs).

[edit] OpenID Attribute

A cryptographic signature will be exchanged using OpenID Attribute Exchange 1.0. AX Attributes can be requested by the RP during verification of the user's authentication. While AX attributed can be requested both as an optional or a required value, the membership attribute shall always be considered optional.

The following AX attribute will be used:

URL: http://schema.liqd.de/membership/signed/
Label: SignedMembership
Description: A signed proof of membership. 
Formatting: http://www.w3.org/2001/XMLSchema#string

Note: The more specific Web of Trust XML namespace could be used here, but I'm not sure of the merits and of its compatibility with OpenID AX.

[edit] Signature Format

The signature will be a cryptographic hash of the user's email address. (While the signature could also contain the name, OpenID URL or membership ID of the user, the email address seems like a sufficiently unique key, without requiring disclosure of the membership ID to the RP.)

The signature will be a generic GnuPG/PGP signature, generated by a GPG key of sufficient length. The signature will be delivered in an ASCII-armoured format. All party office keys will be uploaded to public keyservers, including the MIT keyserver and a protected Wiki page will be created to link to the keyserver entries. The keys should additionally be signed by CACert users, verifying the state party secretaries identity.

[edit] Example

-----BEGIN PGP SIGNATURE-----
Version: GnuPG vX.X.X (GNU/Linux)
    
iEYEARECAAYFAjdYCQoACgkQJ9S6ULt1dqz6IwCfQ7wP6i/i8HhbcOSKF4ELyQB1
oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k
=y6kj
-----END PGP SIGNATURE-----

[edit] OP Requirements

The OP software will need to be a modified OpenID provider. The necessary private key will have to be stored on the OP server and will be used by the OP to create the cryptographic signature when asked to do so by the RP.

  • Add references to compliant servers or patches here.

[edit] RP Requirements

The RP will have to import all valid state party public keys and request signature validation using GPG. Additionally, the RP will have to issue an AX request for both the SignedMembership property and the user's email address in order to verify the signature's integrity.

[edit] RP Participation

The following implementors will join this effort: