Registration framework

[Michael Allan]

Martin wrote:
> Well, that registrar is also just an organisation - so theres no
> real difference.

That's not always the case.  What if the registrar's a single person
who just volunteers for the job?  My next-door neighbour might post a
list of everyone on our street, so we can all vote in local polls.
She likes to organize things, but she's not an organization. ;^)

> [b] Still to exchange votes between systems you'd need to make the
> global guarantee that no voters can register multiple times by
> registering with different registrars/organisations which seems
> pretty hard. ...
>
> [a] I think this is the biggie. If I can register on two engines
> under different names / or under the same name and the systems do
> not recognize that I am the same person, I get two votes. -> bad.
>
> Or I may have misunderstood you.

Para [a] is maybe a misunderstanding; [b] raises a problem I didn't
forsee.

[a] The distinction between user registration and voter registration
is important.  A voting engine can have 10 different *user*
registrations (userid u0, u1... u9).  At most one of these (say u3) is
authenticated in the voter register, and present in the voter list.
The others are barred from voting or (same effect) the votes are
discounted.

Ditto for an image vote.  It's valid to mirror the vote regardless of
userid (u0, u1... u9), but the image only counts if the userid is on
the voter list.  (If the engine has no concept of a discounted vote,
then it can reject the image.  In which case, I guess the autocaster
has to worry about it.)

[b] You say that sock puppets could emerge from a combination of two
registration lists (like two organizations) in an OR eligibility test
(members of club X OR club Y can vote).  True.  I guess we have to
prevent that with AND.  The problem's a little more general too (can
be sock puppets in single list, and that's OK, if we use AND).  So I
added to this to the use cases, etc:

  http://t.zelea.com/wiki/User:Mike-ZeleaCom/Registration_framework

Terms
-----
  tight

      (of a registration list) Asserting a 1:1 mapping of personal
      identifiers to persons.  Asserting that no registrant is a
      personator or sock-puppet.

      (of a registration property) A property from a tight
      registration list.

  loose

      Not tight. Offering no assurance in regard to personators or
      sock-puppets.

Requirement: Tightness is specified
-----------------------------------

  Each registration list specifies whether it is tight or loose, such
  that voting engines may enforce tightness in in voter eligibility
  tests.

Use case: Voter eligibility tests
---------------------------------

  The eligibility of a voter is determined by one or more of the
  voter's registration properties. In the simplest case, eligibility
  depends on a single tight property (T):

   (1)  T

  In all other cases, it depends on an intersection involving a tight
  property. A loose property (L) cannot stand alone as an eligibility
  test:

   (2)  L     wrong!

  Property L might be membership in an organization, for example, that
  cannot guard its member roles against multiple accounts per
  person. In order to eliminate duplicate memberships, L must be
  intersected with a tight property (T), such as primary residence:

   (3)  L & T

  Note that a union of two tight properties is not itself tight.

   (4)  T1 | T2     wrong!

  Properties T1 and T2 might be memberships in separate organizations,
  for example. Though each can assert a 1:1 mapping of personal
  identifiers to persons, a single person might employ different
  identifiers between the two. To prevent that person from receiving
  two votes, the test must intersect with a third tight property:

   (5)  ( T1 | T2 )  &  T3

I'm not happy with this, yet. (4) is actually correct when T1 and T2
are from the same register.  Instead of binary logic, I should maybe
be using set theory, and ruling on list/bag unions and intersections.

> The thing is, if nobody is really against OpenID - I would say that
> we go forward with it as the base of the authentication of the
> voters. ...  This could also be easily extended later with OAuth to
> authenticate third party applications to the voter application for
> specific tasks. ...  What do you think?

For short-term implementation, I say go for the easiest solution that
works.  For long-term design, go for the ideal that makes the world a
better place. ;^)  Best of all, do both in parallel.

For user auth, OpenID and OAuth are OK.  No question, they're already
designed.

For voter auth, why not post your registration lists on the Web?  The
voting engines can fetch them, and do their stuff.  (Just a quick
hack, pending a proper design.)

OpenID for voter auth?  OK for a Pirate's quick fix.  But it doesn't
meet the general, long-haul requirements.  It assumes users are always
logging in where their registration data is consumed (not true in all
cases).  It assumes downgrades of registration status can wait until
the next login.  It offers no easy way for users to independently
verify the registration lists, and thus the results.  It works only
for Web interfaces, not for email, telephone, sneaker-net in 3rd world
countries, and others just around the corner.

-- 
Michael Allan

Toronto, +1 647-436-4521
http://zelea.com/