Wallets as gatekeepers

Atlas
1

I most likely have a limited view on the current state of the ecosystem, but from what I’ve researched so far, it seems most dapps rely on users already having access to a wallet in order to interact with the product/service.

Even the majority of identity solutions in the space assume that as a user, you already have a wallet that allows you to mint some soulbound NFT, to go through a proof of personhood process or to build a social graph that allows you to recover access to said wallet.

When it comes to digital identity primitives, I assume that the private keys and by extension the secret recovery phrases generated with the majority of these wallets that act as web3 gatekeepers, are foundational, as least as a concept to the self sovereign identity that emerges.

Which means that we should think of the registration details as the “birth certificate” on top of which all the rest of our identifiers will be built on.

By “birth certificate” I don’t really mean that 12 random words should reflect the most basic digital identity of our real-verse self, but rather that whatever we end up generating through that registration process, will act as a “central” point of authority, or a central point of “digital will”.

I like the fact that “access control” is part of the conversation, because it does point to the fact that identity really boils down to will, and how that will is propagated, delegated.

The blocker with this state is that there seem to be 2 different paths forward:

  1. kick the can down the road, hoping someone else solves the 12 random words dilema
  2. develop some fringe approaches (biometrics mostly ie WorldCoin, Humanode etc) that raise some pertinent privacy concerns

I am curious how does the Intuition community approach this topic.

4 Likes
2

Great topic @gxg!

We’re using account abstraction & ERC-4337 to handle some of these concerns; I think account abstraction generally is at least one path forward towards alleviating some the current issues surrounding identity/wallet management.

On the point of a “birth certificate” - this is something we have been noodling on A LOT. To your point - controllership, recovery mechanisms, etc. are all “birth certificate”-type things; but we are also trying to figure out - what else should be included on the “birth certificate” of an entity? What base, immutable fields are required to delineate one entity/concept from another? Should these fields change based on Entity Type (i.e., should this be different for a Person vs an Organization)? Is there some standard set of fields we should ALWAYS include for everything, so that we can have certainty that we are referencing the proper “thing” when using its URI?

3 Likes
3

It makes me think of how when working in a production line, we used to build identifiers for different production parts depending on what lane they were produced, which process, what time etc.

It was usually a string of numbers, the first one identifying the type of the part, and based on that, different numbers in the sequence would be interpreted differently.

This will also be a great structure to make sure we have clear distinctions between “human accounts” and “bot accounts”.

I’d say that for an effective interoperability, we will need some standard fields that are always required no matter the type of the “thing”. At least one field actually, to make that distinction clear, ie “you are now interacting with a human/org/AI/etc”

I have to think about this some more.

However, I’ve spent the last few years mostly focused on end-user experience, and when I think of a new person joining this new “multiverse”, one of those standard fields required for a human would be the unique identifier onto which they will be able to tie any and all other identifiers.

This would be a private setting, to ensure decoupling, with the person having the ability to surrender that privacy through some time-sensitive, incentivised, mechanism.

Besides that initial uniqueness, any other attribute should be optional up to a required interaction. Ie. I don’t even have to input my real name, unless I really want to interact with a KYC service, at which point, a new field would be “unlocked” and “required”.

In any case, I think having this Atlas space where the community can come together and figure this stuff is better than any single point I’m making here.

4 Likes
4

Agreed on all points.

In any case, I think having this Atlas space where the community can come together and figure this stuff is better than any single point I’m making here.

:handshake: :handshake: :handshake:

2 Likes
5

Love this framing, I’ve long thought about decentralized identity as a gradient where on the left side is anonymity and on the right side is sovereign identity. As you move from left to right you lose freedom to do whatever you want but you gain utility (ie crossing international borders or opening accounts with municipalities). Along the gradient are other identity service providers (schools, institutions, etc) which unlock moderate forms of utility.

IMO, so long as the state does not intend to surveil, there is the hope that we can apply technologies, like zero knowledge proofs, to maintain anonymity while still preserving sovereign level utility - I considered this the idealized state and the idealized relationship between an individual and the state.

6 Likes
6

Really interesting thought here around the distinguishing of the entity represented, wether its an individuals, org, or AI etc. At the identifier level, we can apply to the same standards like you mention to enable interoperability across the ecosystems and applications. Then on top of these identifiers you can attest or issue verifiable claims about the entity which help those interacting with the entity represented by the identifier.

This enables varying levels of understanding of the type of entity you are interacting with (real v bot etc.). Being able to identify what type of entity is represented by an identifier is an open problem within the identity space, like you said there are various approaches for Proof of Personhood or other ways to distinguish.

Decentralized identifiers exist as a part of the decentralized identity tool, which help to enable higher level concepts of decentralized identity such as reputation and trust when used in tandem with attestations or verifiable claims.

Identifiers
Contributions online are linked to some identifier, on Twitter your have your username, or Lens it is a ERC721 within Ethereum entities are represented by an Ethereum Address. Beyond Ethereum, there is the concept of decentralized identifiers, with the most prominent and adopted standard the DIDs (Decentralized Identifiers (DIDs) v1.0).

So step 1, is having common ways to represent entities with associated decentralized identifiers which then enables identity & reputation forming data to accrue on top.

Selective Disclosure
What you alude to which sharing certain information is getting at a concept of “Selective Disclosure” (Selectively Disclosed Verifiable Credentials | by Julian Voelkel | 51nodes | Medium), which gives users the ability to share varying degrees of information depending on the service or interaction.

5 Likes