Registration framework

Martin Häcker mhaecker at
Sun Dec 13 06:44:28 EST 2009

Hi Michael,

>> I think the problem could be simplified to the point where we can
>> make an organisation guarantee for its members - then they can vote
>> on their (or even better) on other systems.
> It might be simpler in some cases, but it assumes that the only
> criterion for voter eligibility is membership in an organization.
> Won't that complicate things, in other cases?
> Sometimes too, individuals may want to stand independently, outside of
> organizations - or even in opposition to them - and yet still be able
> to vote.  This is maybe more important to some people than others.
> Another way to simplify the problem is to leave the definition of the
> properties (membership, residence, trust level, and so forth) up to
> the registrar.  Then we developers don't have to worry about it - it's
> all just data in black boxes.

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

Also it's easy to found an organisation (like the the Liqd e.V.) that can take the role of just pledging for people that want to register there.

Then we can get away with just having the plain - an organisation guarantees for its members again.

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.

>> (This actually seems like another concern for vote-mirroring: If how
>> users are authenticated in different ways - it may be wrong to
>> mirror their votes - right?).
> [...]
> Or *voter* authentication method?  I think voter auth doesn't matter
> when mirroring in vote scope (as I define it), but it does matter in
> poll scope:

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.

>> If organizations can do that, then for example the Pirateparty can
>> take a pledge for all its members and they can vote on a all systems
>> that decide to believe in the pledge of the party.
> Yes, I think so.  The more general case is:
>  ... the [registrar] can take a pledge for all its [registrants] and
>  they can vote on all systems that decide to believe in the pledge of
>  the [registrar].


>> Just in the last days we discussed in a phone conference in germany
>> that it might be nice for the Liqd e.V. to run an OpenID server
>> where we could accept CACert certificates or Postident as
>> proof. I think though that an organization taking on this role is
>> probably much easier to implement.
> That could be true.
> It looks like Postident is a way of authenticating residential
> addresses.  I guess you guys are thinking that CACert might be adapted
> for that, too?  (I'll have a look, before coding any more trust
> network stuff.  Thank you.)

Well, CACert works by you getting in touch with somebody who already has a CACert account and proving to him with two id documents that you are you - then you get the account.

Therefore it's a pretty good system to prove that a person is who he claims to be with his CACert account.

>> More general, it should be possible to start with weak
>> authentication and then gradually upgrade the authentication to
>> stronger methods as they become feasible/necessary (as the issues
>> decided get more interesting to fake).
> Yes, probably.  And this could be one more reason for not defining the
> auth methods and so forth (propeller sizes, as Friedrich says) within
> the registration framework.  We just leave all those details for the
> registrars and users to sort out, at the appropriate time.

I like that.

What I would like however is if possible talk more about the propeller sizes of the specific interface tot he registrar - for which I would love to use OpenID (for various reasons, one being that its extensible and has good library support for almost all languages).

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?


More information about the Votorola mailing list