Multi-Address Identity Contracts

I'm looking to build an 'identity' contract that can house multiple ethereum addresses in a list. The list of addresses would comprise the only legitimate sources of the 'identity'. Practically, this would probably be used for allowing multiple devices to share a common identity without resorting to sharing a private key, as each device could hold an address from the list. For adding/removing addresses, I'm thinking that a simple voting scheme would suffice -- something that requires a 50% vote in favor of a device to be added/removed.

Thinking about the practical applications of having an identity management/identity device list contract brought up some other possibly useful features, a simple permission system, and a lifespan for addresses.

Users may want some less-trusted devices to be part of the 'identity', part of the list, but not trust the device to edit the identity. Having a simple permission system could allow the device to partake in the application using the identity list, yet not be able to add and remove extra addresses.

A lifespan feature would allow the creation of a temporary address in the list, that 'dies' and is removed from the list once dead. In the situations where a user foresees being away from a trusted device, yet still wants to use the identity, they could create an address to be temporarily added to the list. Specifically, the case I had in mind is: a user resorting to using a normal, untrusted browser to interface with an ethereum-powered application, using a brainwallet/password-generated address. Having this necessarily-exposed address only temporarily permitted allows the user to mitigate the exposure of the identity.

Anywho, I wrote up a version of this idea as a contract.
(I already see that an address that has permission to vote to add/remove can wreak havoc by overwriting the data of other addresses.)

If anyone has any ideas on multi-address identity contracts, I'd love to hear them.


  • mids106mids106 Member Posts: 188 ✭✭✭
    Nice one, I especially like your header comments in the contract!
  • rabbitrabbit Member Posts: 15 ✭✭
    I've been experimenting with identity on ethereum. Your approach is similar to something I was doing before I started experimenting with identity claims which came up exactly because I began venturing into how permissions might work. I'm just starting the process of documenting my approach, if this is something you're into I would love to get feedback.

    The basic idea is to generalize a language for identity claims modeled after certificates. This would allow an identity to make any arbitrary claim so long as there is a contract available to understand how to handle and accept it. Once you have that in place it's a matter of defining the kinds of statements you want to make and building libraries to support them (ie: "This is a session address and expires in 6 hours", "This is an admin address and requires 2 days to remove", etc)
  • wemeetagainwemeetagain Member Posts: 30
    @rabbit Intriguing, I'd love to see more when you're ready.
    How would one use this in a contract to handle permissions? Would the contract just store the permission data and the permission data parsing contract address? Does an identity claim system return a true/false approved/denied?
Sign In or Register to comment.