Registration framework

[Michael Allan]

Hi Martin,

Sorry for the slow reply.

> 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.

> (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?).

In pull autocasting, it looks like user auth will be done only on the
source engine.  The source engine is trusted by the autocaster, and
the autocaster is trusted by the destination engine, so the personal
IDs encoded in the original vote are accepted at face value, as being
authentic.  No second auth is needed.

Do you mean user *identification* method (OpenID, email address)?
This doesn't matter, I guess, because the IDs can be translated using
a pairwise, authenticated list.  If the voting engine lacks its own
pairings, a specialized voter register could provide it.)

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:

  http://t.zelea.com/wiki/User:ThomasvonderElbe_GmxDe/Vote_mirroring#Requirements

> 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.)

> 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.

-- 
Michael Allan

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