Identity & DAO Membership

Status quo, assumptions

Membership is a very strong mental framework that has been underestimated while designing the product. The most commonly asked question after onboarding is How do I add someone to my DAO?

Right now our answer to this question is just assign them some tokens. Using the Token Manager one can assign tokens that can be transferred or not, and limit the maximum amount of tokens one account can own. Even though tokens and the Token Manager provide the right data structure for modelling membership, it is becoming clear that we still haven’t solved the problem from a product perspective.

Membership can mean different things in different types of organizations, while for a ‘capitalist corporation’ holding some tokens is an intuitive way of being a member of the organization (equivalent to a shareholder, with tokens represent voting and economic rights), in other contexts such as being a board member or having a recovery key, the token analogy is harder to grasp.

In the first release of the new Aragon client (v0.5) we decided to implement a very simple identity system building on ENS, that currently allows users (there is no UI for this yet, but it is doable at the EVM level) and DAOs to claim a name (a subdomain of aragonid.eth) that can be used as an alias for an Ethereum address (but just as a one way mapping: name → address). One of the reasons for choosing ENS, is that it supports attaching metadata to names and two way mappings (name ↔ address) can be created using reverse name resolution.

The following are the assumptions or user stories that the rest of this proposal builds upon:

  • DAO creators want to add members to their DAO.
  • Members of the organization want to differentiate other members as individuals or entities, not as hexadecimal characters that are hard to remember.
  • Users don’t want to be tied to one particular way to identify themselves, and different users want to identify themselves using different identity providers.
  • A DAO wants to have its own unique identity as an organization, so it can be identified when interacting with other DAOs/systems/protocols.

Aragon ID v2: ENS Metadata & Identity providers

Background:

An Ethereum account can only have one valid two-way mapping to an ENS name. The associated identity to this name is the Core Identity of the account (even though strictly the identity is associated to the name and not the address). The Core Identity of an account is fully controlled by the account owner, and is fully self-sovereign, and thanks to the two-way mapping, it is possible to fetch the Core Identity of an account from its Ethereum address.

However, an account can have any number of one-way mappings (name → address), and these other names can have their own identity metadata. All these other identities that an account can have are Contextual Identities. Two caveats about contextual identities under this design: a contextual identity is not necessarily set by the owner (it can be a claim from someone else about that account) and it is hard to fetch all the contextual identities of an account, but the user can always identify themselves with one of these names.

Just owning a name on a certain subdomain can signal group membership, for example all Aragon One employees could be given a [name].a1.aragonid.eth name. Owning an address that resolves from that subdomain already means being an A1 team member, and apart from their Core Identity, their employment Contextual Identity could be just related to being part of the team (role, location, working hours…)

Using the TEXT field in the standard ENS resolver, each name can have some metadata attached to it. The name owner (not necessarily the account that the name resolves to) can add some information for a particular key or identifier.

These are two different proposals for implementing multiple identity providers with different tradeoffs:

  1. Using different text metadata keys for different providers (e.g."identity.brightid", "identity.iden3"…) and its value being the provider specific data. This implementation would make identity harder to consume (as it would involve performing a bunch of calls checking if the user uses any of the providers) and allows for potentially conflicting information as someone could be using multiple providers at the same time.
    A ‘default provider’ key could store what identity provider is preferred by the user. It would make identity consumption easier, at the expense of store one extra field of data on-chain.
  2. Using a constant key ("identity") and have its value be a bytes array of arbitrary length, with a prefix identifying the identity provider followed by provider specific data (an IPFS hash, a URL, a Keybase proof). Identity is very cheap to consume, but would require storing an extra 2 bytes on chain (shouldn’t be an extra cost for most blobs that would already be longer than 32 bytes).

DAO Membership

Membership should be a core level primitive in Aragon DAOs. Being a member of a DAO wouldn’t necessarily grant members any economic or governance rights, but interfaces could be built so the Voting app could use membership as its governance base and a Membership forwarder or oracle could be created so permissions can be assigned to members.

The ability to add members and at the same time giving them an ENS name (e.g. jorge.aragonone.eth) linked to the membership is a good way to have humanly readable names in organizations, even if the members haven’t created a profile themselves yet.

Membership to an organization shouldn’t be transferable, but unfortunately it is impossible to ensure that someone won’t transfer their identity (if rather than holding your identity in a EOA it is held in a smart account type contract). Making membership non-transferable will definitely raise the barrier for members to trade their membership/identity, but given that it is impossible to effectively protect against this (at the contract level at least, a subjective oracle could be used to penalize members that sell their membership) it is unclear whether we should claim and make membership non-transferable.

However Membership is implemented, it should expose an ERC20 compliant interface for some getters (name, symbol, totalSupply and balanceOf(address)), to make integration with existing Voting apps easier.

Implementation proposals

Background: Aragon v0.6 (w/ Aragon ID v1)

1. Membership app (aragonOS 4 friendly)

Pros:

  • Cleaner architecture, Membership app is a standard aOS forwarder

Cons:

  • Migration for v0.6 DAOs would be non-trivial in order to re-use the ENS name and issue sub-names[1]
  • Identity of the DAO would need to be set through the Membership app(s)
  • Dubious scalability for big organizations with nested groups (possible technically but the experience would be clunky)

[1]: It would likely require resetting subdomains of aragonid.eth with a multisig intervention. It could be done fairly trustlessly (verifying receiver of the ownership over the name is an app of the DAO). This would set a dangerous precedent, so in case we decide for this route we should also remove this power from the multisig and make the registrar trustless, as the Aragon ID readme explains.

2. Membership in Kernel (DAO Stacks)

Pros:

  • Improved scalability and usability of big orgs using nested DAOs
  • Child DAOs could inherit[1] some aspects from the parent DAO and the parent DAO could have complete control[2] over its child DAOs, but they could have independent ACLs

Cons:

  • By baking Membership in the Kernel we would be enforcing an opinionated Membership model
  • Other systems built with aragonOS may not need a core concept of Membership
  • Technical cost would be 2-3x the cost of the previous proposal

[1]: Inheritance for example in the case of app versioning: a child DAO that uses the same Voting version as the parent DAO wouldn’t need to have it stored in its own (child) Kernel, but just rely on its parent DAO for upgrades to the Voting app.

[2]: A parent DAO agent app could have ‘root permissions’ in all its child DAOs, so the parent DAO could have complete control over them.

4 Likes

Change to “Making membership non-transferable will definitely raise the barrier”

1 Like

Should be “at the same time give them”

Brightid doesn’t require writing to an ENS text record. Instead it uses a smart contract to link addresses of users to brightid scores under a “context.” The creator of a “context” defines which brightID nodes are authorized to act as oracles regarding brightid scores (and therefore submit signed scores). Anyone can use the smart contract to look up an address under a context and retrieve its score. The score is the likelihood that the address represents a unique human being in the context.

So you can think of brightid as a way to link (through an EOA) a stamp of uniqueness to a set of personal data stored in ENS, essentially saying “The person represented by this profile is a unique human being in this context.”

In doing this, brightid does not expose the brightid public key, only a score, so there is no way this link can be used to “out” a brightid user in a different context or application.

Instead of making memberships non-transferable, re-frame the problem and limit the number of memberships of each person in a context to one.

In other words, if a membership has a low brightid score, it can be viewed as an indication that this is a secondary or duplicate membership.

1 Like

I think this "meta" properties should be particular to the identity provider. For instance, you could use BrightID, which tries to ensure uniqueness of identities, so it's harder to transfer identity unless you do it to a "new" user (but then you could always give him your private key). Another identity provider could require some sort of KYC (yes, sorry) like you have to prove it with your real world passport, fingerprint or whatever. But I think all those kind of properties should be part of each particular provider.

Besides, you could want to change your EOA because you lost your private key (so the owner of the domain should change it) or for any other private reason, like it was compromised, or I was using Metamask and now I bought a Ledger, etc. So I think it should be transferable unless the provider’s protocol forbids it.

What’s the use case for this? Would this child DAO have members? Would they be controlled then by the parent DAO members? I imagine (almost) the opposite: a child DAO is a member of parent DAO, and (partially, proportional to its share of whatever governance it has) controls it. For instance, if I have a “personal DAO”, which is child to (member of) another DAO, I wouldn’t want it controlled by it. I guess this control would at least be optional. I don’t quite understand why this “DAO submission” depends on the identity implementation, but I guess I’m missing something here.

1 Like

This is one of the reasons that I support having all identity and membership handled in the app layer - where it is right now. For one DAO, Membership might mean that the Jeremy BrightID and the Jeremy UportID are members of the Jeremy DAO, and therefore the Jeremy DAO controls them. For another DAO, Membership might mean that Jeremy and Griff are members of the DAC, and therefore we have votes for what the DAC decides to do.

One thing that might be helpful would be the ability to assign an instance name that shows up in the ui when there are multiple instances of an app in the ui. I don’t think there should be any in-kernel validation for this though - the app itself should handle it.

Jeremy BrightID and the Jeremy UportID are members of the Jeremy DAO, and therefore the Jeremy DAO controls them

What would be the use case for this? I think of multiple identities for the same person as an important consideration but handled at the identity layer. A DAO is meant to let its stakeholders manage an organization, so a DAO for a single individual seems unnecessarily recursive?

More generally, I think membership is extremely central to basically all durable organizations and I’m struggling to come up with real use cases where the opinionated membership model would not apply or be restrictive. Ephemeral organizations like events may look different, but every other org type I can come up with that is likely to be compatible with the DAO in kernel model.

One assumption I’m making on that is that governance in the parent DAO could, in some cases, be not just via individuals in the DAO (and child DAOs) directly, but through the child DAOs (aka a form of federated voting & governance).

Individual DAOs enable security features like multi factor authentication and credential recovery, entirely under the control of the user. This isn’t an organization in any sense, but it will still use DAO code. Assuming that all DAOs are going to be organizations limits the uses based on a naming decision.

That’s a good point. I don’t think we should make membership non-transferable, even if there is a risk that memberships will become publicly traded.

This is a super interesting re-framing of the problem, I love it! Let’s think more about it :smiley:

It isn’t super related, but kind of got down the rabbit hole while thinking about sub-groups in a DAO

I think assuming that is quite safe, as the O in DAO literally means organization.

But anyway, even if the concept of membership doesn’t apply to all the usecases for Aragon you may be thinking about, I think we need to take the discussion to the data structure level. Is a list of unique addresses with equal rights to do something in the DAO (that may or may not be named with subdomains) a generic enough need that justifies adding it to the Kernel?

The research I have been doing these past two weeks makes me side with Yes more than No.

1 Like

I appreciate all the architectural and theoretical planning here, but at the moment, the lack of nicknames is a big usability issue.

I suggest you add nicknames for addresses that are stored in the DAO’s contract and can be modified by a vote. Would only really affect the frontend. Simplest possible solution, while you figure out how to integrate ENS and the child DAOs or whatever else. Does this already exist and I don’t know about it?

These designs look great btw: https://github.com/aragon/design/issues/5

Seeing 40 character random strings everywhere is a huge usability issue and would be easy to fix in a simple way. We have implemented nicknames in our app, but the random strings are everywhere else in the interface.

Here is the code that does our nicknames:

  struct User {
    address ethAddr;
    bytes16 nick;
  }
3 Likes

Agree! A quick and basic solution could provide a lot of value short-term. I noticed that The Planning Suite had to implement an “Address Book” that is just a mapping between addresses and human readable names as well. cc @Quazia @stellarmagnet

1 Like

From OP:

In the first release of the new Aragon client (v0.5) we decided to implement a very simple identity system building on ENS, that currently allows users (there is no UI for this yet, but it is doable at the EVM level) and DAOs to claim a name (a subdomain of aragonid.eth ) that can be used as an alias for an Ethereum address (but just as a one way mapping: name → address).

What’s the user experience like for a user to get the ENS name? This solution makes technical sense, but I’m afraid the UI would be a lot more complicated than for setting a simple nickname in a mapping stored by the DAO. It’s certainly doable, but I’d be worried that refining the UX on this, and programming the more complicated process will lead to more delays on getting nicknames at all.

Along that train of thought, is there some simple interface defined for the Aragon frontend code to look up a mapping on chain or in ipfs and populate nicknames? We could have it look at our mapping and this would solve the problem. This would be a good interface to standardize no matter the underlying system.

@jtremback this is the Address Book app that Luke mentioned which is in the works. Hoping to have it done in our Github in the next few days or so. Would love to chat more in our session tomorrow to see if it meets your needs. For the mappings to reflect in all of the Aragon apps, I assume they would have to be forked. This isn’t exactly for managing an individual identity, but technically any person should be able to add themselves to the address book. And indeed since it’s an Aragon app, the Voting app can control modifications, additions, etc.

We built it so we can have an “Address” dropdown in our apps, and it would pull in the list of entries from the Address Book. This is useful for when you are sending transactions to the same people/entities/projects over and over again (I know the Identity app would solve this for individuals, but it won’t solve it for some external person or entity not in the DAO)

2 Likes

Yeah, the main limitation right now is that any UI you want to leverage the Address Book needs to know the address of the app. Our current solution is to just initialize the app contract with that address for any app that needs the name->address mapping accessible in the UI.

Thanks, that looks like a great interface for setting nicknames. My concern is getting those nicknames into the main Aragon interface, in the built-in apps like voting and finance.

Not sure what the status of this is: https://github.com/aragon/design/issues/3

But I think it would be helpful to understand (separate) from the larger issue of profiles/identity architecture what a MVP would look like to get to the point where addresses can be assigned a human readable identifier and then swapped out in the UI if the identifier exists?

Is that something that can be delivered independently (without creating a ton of technical debt)? If so what are the blockers?

Yes, please! This issue is a pretty big blocker for us at Althea. I mean, imagine if a normal web app had everyone’s user names and avatars replaced by database ids. This would be considered a critical bug and fixing it would be an emergency.

We can just barely get by with this issue in one of our test deployments, because the users there are ready for some jank and are being personally guided by my co-founder @DSimpier. There’s no way we can deploy it with the 0xstrings instead of nicknames in our other test deployment.

1 Like

My vote for a short term fix would be to give the rest of the interface the ability to pull an address->nickname mapping from an app (for example that address book app), and use that to populate the interface.

As long as those nicknames can only be changed by a vote or other authorization, this would seem to be as secure as we need.

1 Like

Speaking only as a user and not to the technical details of the proposal, these are my thoughts about what I want for “identity and membership” in Aragon:

ENS

I want my org to have an ENS name, and I want Aragon to recognize my ENS name if the address I’m using to interact with it has a name. If I don’t have a name yet, perhaps the app could offer me a way to register one (either a subdomain of aragonid.eth or a fully-qualified domain name - for the latter it would probably refer me to a dedicated ENS registrar app). I also want to be able to use an ENS name instead of an 0x address in every place possible i.e. “first-class” ENS support.

I agree with @jtremback that first-class ENS support is likely the most urgent need usability-wise. I specifically say ENS because creating our own name system seems like an unnecessary detour.

Aside: Regarding the address book app, I wonder if it wouldn’t be better to store this locally rather than on-chain. This has the benefit of 1) not taking up scarce and expensive blockchain storage 2) not requiring a transaction each time it’s updated and 3) not requiring consensus over the name -> address mapping, since each user gets to create their own address book.

I have a desktop wallet app that has an address book but the labels are stored locally, not on the blockchain. This seems to work well enough. See my idea below about a “roll call” app that might make more sense to do on chain since it isn’t storing any extra data on chain or introducing a new shared resource to govern.

Profiles

It might be interesting for orgs and individual org members to also have a profile that can be seen when you click on the address or ENS name, so you can quickly get more context about who/what you are interacting with. A simple solution could be Ethereum Profiles; storing (relatively) large amounts of data off-chain is a mostly unsolved problem that is currently being punted to centralized hosts like IPFS gateways or AWS. (Swarm incentives when?) Outsourcing this feature to Ethereum Profiles is probably the best solution vs rolling our own (another unnecessary detour imo).

Aside: maybe in the future Ethereum Profiles can also support a standard like ERC-725 so users can make and receive claims, and these claims can be stored in the profile. I imagine this working like an OpenBadges backpack, if not actually using that standard just in a blockchain context (related). This would be a universally beneficial feature for all “social” or “multiplayer” dapps, not just Aragon.

Membership

I think the current way that “membership” can be defined in Aragon works great today and is already intuitive. How do you add someone to your organization? You assign a token to them if you want them to have governance rights, you add them to the payroll if you want to give them a salary, and you assign a permission to them if you want them to have direct power over an action. Seems straightforward to me - I see no need for the membership naming scheme described in the OP.

Maybe a “membership” or “roll call” type app could exist that just pulls from the Token Manager and Payroll apps installed in the org and shows who is a “member” and what apps they’re plugged into e.g. “johndoe.eth - Token Manager, Payroll” similar to the way the Permissions app shows which apps are installed and what permissions each entity has in the org.

4 Likes

IMO, it shouldn’t be looked at as “creating our own name system”. Technically it’s just a mapping of Eth addresses to nicknames. Both us and @stellarmagnet have implemented it in our apps. What’s really neccessary is just the interface between whatever record will be used (be it ENS, or the address book), and the frontend.

ENS could be the most theoretically elegant solution, but I’m concerned that it will add more steps for the user and implementation complexity. Sounds like a lot of work has been done on it already though.

But ultimately, whatever gets some form of usernames implemented most quickly would be great, and I wish we had flagged up this issue months ago.