Identity Providers: Resolving Addresses to Identities in Aragon

As we were thinking of approaches to show identity information in Aragon, it became clearer and clearer that no single “source of truth” exists. In particular, there are several “identity” services today, including:

Given the myriad of choices available to users, we thought identity resolution might best be handled in a generic and pluggable fashion that was user- and developer-extensible.

Introducing Identity Providers (“Identity Stacks”). See the technical interface draft.

Note that this is orthogonal, but related, to an address actually being a “member” of an organization.

Identity Providers

Note that this is an initial mock up and will likely not represent the finished product.

Users would be able to install (locally and for an organization) custom identity providers that are backed by an external service (e.g. ENS or 3Box). They would pick and choose which ones are enabled, and their resolution priority.

In the example above, the user has installed 3Box, ENS, and BrightID integrations, with their priority moving down from local custom labels to an built-in Identity app, to 3Box, to ENS reverse resolution, to BrightID.

For ease of implementation, Identity Providers are initially “all or nothing”. This means that they are either used completely, or not all at, so a user cannot pick and choose which aspects they’d like to use from each provider (e.g. you cannot choose to use 3Box solely for someone’s profile picture, but resolve their name from ENS). If a provider resolves to metadata, it is used and no more resolutions are performed.

For performance concerns in the client, we may restrict the number of providers that can be enabled at the same time, and may only use the highest-priority provider when rendering an AddressBadge without its popover, i.e. this state:

Degrees of Freedom

This is the most tricky aspect, as we don’t know the full range of information available from identity services. We need help making this generic!

The basic AddressBadge implements a “badge” and “popover” state. The badge itself (see above) can have its icon (defaults to identicon) and text field (defaults to address) changed. The popover starts off as:

But can be extended to (see highlights for changeable aspects):

This is fairly limiting, with only four degrees of freedom:

  • Name
  • Provider type (shown above, is the local custom label)
  • Image
  • Action (and label)

In particular, some identity services can provide aggregated sources (e.g. 3Box and Keybase can provide Facebook, Twitter, LinkedIn, etc.), and with the current degrees, you would need to use a separate identity provider for each source, even though they’re backed by the same service. I find this mostly reasonable, since most people have established preferences of which sources of identity they prefer, but can be a challenge to technically optimize.

We may also need an additional customizable area for putting the most important information related to an identity (e.g. BrightID’s score or a twitter handle).

Custom Actions

Of particular difficulty is the customizable action in the popover. We really need help making this generic enough!

The initial implementation of an Identity Provider, custom local labels, only involves a trip to localStorage or an indexedDB database in the browser. As such, it’s fairly easy for the Aragon client to know how to render input fields as well as apply the modification:

All “Save” does is set that input field’s string to be associated with the address in localStorage or indexedDB.

However, there are at least the following other types of modification actions:

  • An HTTP request
  • An Ethereum transaction
  • A signature from the wallet

And potential inputs:

  • Images
  • Dates
  • Etc.

The easiest way out, which may become the design recommendation, is to simply link to the external service, so that a user would manage their profile from there (or view more of the profile, if it’s not their connected address).

More Technical Details


As apps are in control of rendering AddressBadges, the responsibility of resolving identities is solely on app developers. A pre-built component will likely be available, and the “resolution stack” will be completed from Aragon (so apps are completely agnostic to the providers and don’t need to request which one they’d like to resolve with).

Some of these providers may take longer than others to resolve, and all of it will be done asynchronously, so it may also be necessary to design some sort of loading state in the AddressBadge.

Aragon client

As noted, the client will be responsible for actually resolving and applying the “resolution stack”, and sending the results to apps.

Identity Providers

Given that any installed providers will only be loaded at run-time, and could be made by anybody (potentially malicious), sandboxing is a strict requirement.

As such, I envision these providers to be self-contained packages that are run in isolated WebWorker instances, similar to how app background scripts are run today. These should implement a standard API, for resolving and modifying metadata, that is accessed through the WebWorker.postMessage() API (potentially using @aragon/messenger).

An abstraction like @aragon/client may still be necessary, if they require access to web3; they should only be allowed to read from contracts.

These providers would be published and made available to Aragon clients through an aragonPM instance (again, similar to how apps are published and made available today).


The current IdentityProvider interface includes IdentityProvider.modify() as a generic API to modify an address’ associated metadata.

The return type is particularly difficult to get right, but as an initial thought, we could implement something like:

return {
  type: 'success | transaction | signature',
  data: 'transaction data | signature data'

With the assumption that any HTTP requests are able to be completed within the WebWorker itself.


As a user, I want to be able to use ENS names to identify individual users and Aragon organizations. I like ENS because it is a relatively widely-adopted standard for Ethereum-wide naming, and it works fairly well. If an address has an ENS name, I want to see the name before I see an address. When I click on the name, I want to see a minimal profile of the user or organization, containing for example a non-unique name like Jane Doe, a short biography, and a link to an external website (like a twitter profile).

It seems such a system could be built today if we have a way to resolve ENS names to a profile, for example a 3Box profile. From that profile, users could then add fields that link out to additional profiles and information. I used an external website as an example above, but a user could also link to their Keybase profile, their BrightID, and any other resources that provide additional context. Two-way verification could be used to establish secure pairing between these external resources and this profile.

The system as described in the OP seems too complicated from my perspective as a user. Too many choices and I don’t really understand the implications of each choice. The UX should be dead simple. Register a name, if you don’t already have one. Create a profile, if you don’t already have one. Done.


Just my two cents here but in your proposal @light it means any kind of metadata resolution [linked twitter account, keybase account, etc.] would be somehow delegated to 3Box. I really like 3Box but this would also mean that the ability for Aragon apps to provide / make use of other metadata would entirely rely on 3Box will to integrate these metadata as a part of their solution.

I think it may end up being a problem, right ?

I used 3Box as an example, not too opinionated on what tool is actually used. If the profile solution is based on open standards, is decentralized and portable to prevent vendor lock-in, and doesn’t lead to a confusing UX then I’m open to whatever works. I’m not a developer, just a user sharing what I want from whatever profile solution is used.

The solution could just be a mapping of an ENS name to a json blob on IPFS containing a Person schema with all the info the app needs to render a profile - this is approximately what Blockstack does for their user profiles, and works reasonably well. Where the profile assets are stored and how to ensure uptime is of course an open question. Blockstack punts on this by letting the user pick their own storage provider, and plugging into those using a “storage driver” system. Users can pick to store their profile assets on AWS, Dropbox, Google Drive, their own server, and IPFS, and it’s up to the user to ensure that those assets remain available online. I like this system and think it’d be cool if something similar existed for Ethereum. With this kind of system the json file could be modified by the user to add whatever new information an app wants to store in the profile, then apps would just render the profile from the fields relevant to that app.

@adamstallard if BrightID is used as an identity provider, would the user only be able to see the name/avatar/score for their connections alone, or is there going to be a way for a BrightID to have “organization” membership, which shares the name/avatar/score with everyone in that organization?

I like the solution presented because as of today, no data standard exists yet for identities, and there are multiple use cases beyond being an individual as far as what an Ethereum address can represent.

This solution provides the greatest flexibility. After it is implemented, we can also have better data on what providers are more commonly used (I assume we may have to do interviews to gain this insight since there isn’t tracking software?).

Some other thoughts:
It may be useful to allow a DAO to have a default/recommended ordering for the identity providers. This makes members of the DAO have to think less about customizing the priorities – they can just focus on loading up the json – although I wish that could be automated in some way as well, by a DAO linking a github directory like “” and it looks for the json and loads it into their browser’s db. But that’s a bit beyond my head if that’s possible.

I’m wondering if the identity sources for an individual should be managed via the Identity app - so for example, you can “extend” your identity to include a 3box profile and BrightID score? I’m not sure if this helps, performance wise.

Hmm this is one point that I think may deliver a sub-par UX – we are going through all of this trouble to have multiple identity providers, but to actually fully make use of the feature, you have to click on the badge to render the alternate data?

If we go this route, do you think there can also be a some kind of global “pull” option, where it checks all sources, populates the badges displayed on the apps, and stores in the cache or something?

I’m actually leaning toward not including custom actions in the popover for the case of simplicity – I think it may be overkill. I assume the primary use case is that a DAO maintains a json file on Github that contains the mappings. The user downloads the json, and loads it up into Aragon. For DAOs with > 10 members, I really don’t know if I can see editing addresses with a popover really scaling.

I hadn’t thought of using brightid as a way to import profiles into Aragon, just the score.

We have a way to show brightid scores verified by the brightid network linked to ethereum addresses without exposing the brightid public keys. So all you see is someone’s score, i.e. whether or not brightid thinks they’re a unique human.

It adds that uniqueness score to their Aragon profile, which might contain other profile information from other sources. Since the brightid public key is never exposed, an individual can prove their uniqueness while remaining pseudonymous–or if they choose to give out personal information, it won’t be linked to their brightid public key, only to the score.

1 Like

Awesome discussion!! And very timely as I’m currently specking out work for Autark’s profiles. Let’s make sure we’re in-sync about our identity related work to avoid redundancy or conflicting solutions. Does a call sometime this week makes more sense for this discussion?

Here’s how I had been thinking about approaching this problem.

Instead of making different identity/profile options mutually exclusive, we could choose a “base” profile solution that integrates and aggregates information from other identities/profiles. We were leaning towards making 3box our “base”, and integrating information from LinkedIn and other Aragon related statistics (or allowing a user to enter information manually). This list of integrations could grow over time to include other identities like GitHub, Facebook, ENS, BrightID, and/or custom labels (although I haven’t looked at how we would incorporate brightID information yet @adamstallard ). The downside here is that the user might have to “refresh” their integrations to see their profile repopulate with any new, updated information (rather than listening for changes - a “nice to have”).

@osarrouy fantastic point - but with a user’s permission we can write to their 3box profile, so we wouldn’t need to rely on 3box’s built-in integrations. I made sure this is possible by building an “integrate linkedin to your 3box” proof of concept app here.

@sohkai This relates to your proposal in a few different ways:

(1) It helps with the challenge of building a generic UI/UX - instead of trying to support multiple identity providers (all with their own data standards) at the same time, we can standardize the “base” solution according to open standards (like When integrating information from non-standardized sources (like LinkedIn), we can simply reformat the data before storing in the “base” profile. All of this, without creating another profile solution (because we’re simply adding to the user’s “base” profile) and allowing us to provide a familiar UI/UX. Cc @stellarmagnet @light
(2) We can programmatically create 3box profiles - so if an address “does not resolve” to a profile, we could create one for the user. This is better for the community, and gives us some leverage to ask 3box to contribute where we need them (like supporting certain integrations for us and helping with formatting their data according to open standards like
(3) It would seem to reduce a lot of complexity for the Aragon.resolveAddressIdentity method because we only need to fetch data from one “base” profile.
(4) Not sure about this, but would it remove the need for the Aragon.modifyAddressIdentity method? You could modify your Aragon identity in the Aragon profiles app, which is simply modifying your 3box. (we could also abstract this logic into its own module, which Aragon could use to create a modify address identity method).


I haven’t done much work with ENS, but it seems like your proposed solution would be quite easy to pull off because we would just ask you (the user) if you’d like to integrate your ENS name, if yes, we pull that information and store it as your “name” in 3box.

Blockstack punts on this by letting the user pick their own storage provider, and plugging into those using a “storage driver” system. Users can pick to store their profile assets on AWS, Dropbox, Google Drive, their own server, and IPFS, and it’s up to the user to ensure that those assets remain available online.

Personally I think this is a “nice to have”. Not to mention, a user could already do this using 3box and IPFS filestore (but they would need to be technically savvy).

Does this make sense to people? What are the other downsides to this approach? If you like your original proposal better, how can we work together and save time for both of us?

1 Like


My thinking here has been that there should be one “first class” Ethereum-native profile that users either create or bring with them during onboarding, and that profile can then link out to or pull data from other profiles like BrightID, Keybase, Twitter, LinkedIn, etc, if those profiles contain important/relevant contextual information. Your proposal sounds similar to what I’m looking for in a profile solution, so it has a preliminary :+1: from me!

I haven’t done much work with ENS, but it seems like your proposed solution would be quite easy to pull off because we would just ask you (the user) if you’d like to integrate your ENS name, if yes, we pull that information and store it as your “name” in 3box.

I think a tight link would be nice (necessary, even) in that I should be able to use someone’s ENS name to securely look up their profile. With this, we could effectively build a decentralized Keybase-like system where names securely map to crypto keys and other identity metadata. This should be possible using ENS’s Public Resolver tool (discussion and tutorial thread here). Without this tight link, I’m not sure how we would be able to resolve the name to the profile in a decentralized, secure, “trust-minimized” way.

A challenge that arises is that of data mutability. Let’s say we link the ENS name to the profile using the IPFS hash of the profile. When the profile changes, the hash changes, and so an on-chain transaction to update the ENS resolver will need to be made each time the profile is modified and saved. This puts heavy load on the blockchain and becomes quite expensive over time.

What we would do to solve this (and I am borrowing from the Blockstack design whole cloth here) is to create a layer of indirection where the ENS name is linked to an immutable URI that points to a “zone file” and this zone file is just a json blob that contains two important pieces of information: a crypto public key and a mutable URI that points to the profile data. This mutable URI could be for example an HTTPS URL or an IPNS hash.

The profile rendering tool would then use the ENS name to look up the zone file, and use the zone file to look up the profile data, and ensure the validity of the profile data by making sure it is signed by the public key referenced in the zone file. Whenever the profile is updated, the mutable URI doesn’t have to change, so the zone file doesn’t change, and no on-chain tx is necessary to update the ENS mapping.

(This blog post, and the first graphic featured, explains how this works in more detail.)

It’d be cool if Ethereum had a native, scalable profile system that worked like this. But it doesn’t! So now we get to build it (or help 3Box build it) :slight_smile:

I just spoke with @stellarmagnet and better understand how our work on profiles/identity fits into this discussion - our profiles should be an additional provider option for the user to choose from. @sohkai, I’ll think more about how to expose the profile information in an easy way. Let me know if you have a preferred way of “receiving” that information and in what standard / form.

@light, I’m going to take a backseat in the discussion about “whether or not to allow a user to choose from one of multiple identity providers” - I’m not working on Aragon/client and also not a UX expert :). But thanks for the detailed explanation, I really dig your idea! Here some of my thoughts to consider after reading a little deeper into ENS and your proposal:

  • the mutable data issue can be solved by IPNS or (presumably) 3box’s root store. FWIW, managing IPNS keys presents challenges of its own.
  • agree that choosing from a list of identity providers is complicated, but I feel like forcing a user to register an ENS domain to get started with a profile also seems complicated. (Although maybe that’s not what you’re suggesting or there’s another way around this). Afaik, there’s an auction process for buying any name, which obviously takes time, effort, thought, and money. Supporting this part programmatically from within Aragon would take dev time.

As a user you wouldn’t really notice though. We could set sensitive defaults in terms of identity providers, so it would just lookup addresses in different providers and show you their names and avatars and any other relevant info

Users can register a subdomain, as they already do when first creating an Aragon organization, which can be “free” and “instant” (costing only gas and taking only as much time as it takes for the registration tx to be mined).

I strongly believe that there should be at least one Ethereum-native ID/name/profile solution, and all off-chain centralized ID solutions should be secondary to that. This doesn’t exist yet, but we’re getting close.

And the only secure “universal” way to bind names to addresses on Ethereum right now is with ENS, that’s why I think it’s an important component of any solution we ultimately come up with.

I watched Blockstack struggle with the user profile and ID challenge for years. What they’ve landed on is a really well-architected system that answers a lot of the questions we’re asking. We could save a lot of time by learning from their years spent working on this problem and applying it to the Ethereum context. We can start with something a bit more stripped down than their full system, just so we have something working in the near term, and then iterate towards a more comprehensive solution like they have today and make it the standard for Ethereum user profiles.

This is the UX I want:

Register a name, if you don’t already have one. Create a profile, if you don’t already have one. Done.

I just don’t see how the system described in the OP gets us that, and why it needs to be any more complicated than that. Implementing something like what I’ve been describing could get us there though.

1 Like

My take would be the following:

  1. Create a solution that enables multiple identity providers to exist
  2. Pick one that works really well and has great UX (my pick is 3Box)
  3. Embed their client-side app into the Aragon app
  4. Done

The risk that I see if we want to take on identity all by ourselves, is that we end up having to take on another huge part of the stack. So I’d rather have providers and just let them plug into the app, so we outsource getting identity right to them

1 Like

Yes I’d also much prefer this part of the stack be taken on by someone else. Using centralized identity systems is a severe compromise imo, but 3Box is close enough to being Ethereum-native and decentralized that it might be the best fit in the short term. I myself could wait for a fully decentralized Ethereum-native solution to work, but given the urgency others have placed on this issue I thought I’d offer suggestions for something that’s not a total centralized cop-out that will also work in the short term.

I saw you comment on a tweet about Bloom earlier today. Out of curiosity, is there any chance it will be considered as a solution for solving this problem?

I’m personally interested in a more simple ID/profile solution than what Bloom has, which seems geared towards providing a credit score specifically. But there may be some components there that can be re-used. It’s really up to the people who will be integrating whatever profile system is chosen / built to decide (and I’m not one of those people).

1 Like