Opening an architecture

[David Hilvert]

On Sun, 22 Nov 2009 12:18:07 -0500
Michael Allan <mike at zelea.com> wrote:

> I'm floating this as a kind of architectural "kite", just for
> discussion.  I scraped together some rough sketches of 4 frameworks,
> with non-technical commentary for each.  The frameworks are:
> 
>   1. Registration
>   2. Differencing
>   3. Classification
>   4. Autocasting

Should vote tallying and collecting in general be considered a separate
framework (or are you including it within Classification)?

...
> 1. Registration framework
> -------------------------
> 
> A registration framework is for identifying users and authenticating
> them as voters.  The framework below is already partly designed and
> implemented, as a pre-alpha prototype.^[2]
> 
>     http://zelea.com/project/edo/registration-network.png
> 
> What the sketch above says is that different locales (X Region, Y
> City, and so forth) are responsible for maintaining their own voter
> registers.  They can also choose their own software for this purpose,
> from any supplier.  Each supplier's "local voter register" component
> is plug compatible with those of other suppliers, so they all work
> together in a coordinated fashion.  Coordination is necessary so that
> voters can register at the local level, and be authenticated just
> once, yet vote in all polls (local, federal, and so forth).
> 
>     http://zelea.com/project/edo/registration-framework.png
> 
> Not only the voter registers are plug compatible, but also the voting
> engines.  (That's what the diagram above says.)  So X Region might be
> using a Liquid Feedback engine, while Y City is using a Votorola
> engine and Z City is using both - some polls being voted in one
> engine, some in the other.  Eventually the voters might settle on a
> single engine for general use.  In any case, they will always have the
> choice of trying out new engines, whenever they appear.

Would it be possible to make use of or integrate with OpenID?

http://en.wikipedia.org/wiki/OpenID