The document provides a summary of the discussion during the Voyager Identity #5 Meeting. Following the summary is the beginning of a proposal that attempts to develop on the DAOIP model in light of the discussion. The proposal points to a different architecture of where the UX of persons/addresses seeking attestation from a DAO are centered, and a finer distinction between on and off chain data sources and their relationship to membership are made.
Â
The proposal development is still in a highly sketched out WIP form, and needs to be more clearly outlined and formulated. The primary focus over the next two days should be to review the summary of the discussion, and leave comments. This document will be relinked in at least two days with a more developed iteration of the proposal development that follows the summary.
Â
To compliment the summary of models discussed in the previous call, this document also outlines five mental models of identity for clarifying the focus and intentions of this WG.
Key Documents:
Summary of Conversation
Proposed Model and Alternative Models
DAO-Level Model
The current spec of DAOIP involves a DAO implementing an extension of the EIP-4842 Membership JSON-LD Schema. This implementation allows a DAO to define membership through a variety of inputs such at NFTs, ERC-20 tokens, Whitelists, Gnosis Safe multi-sigs, etc. Membership is formulated into a member object.
Separate from the DAO generated member object are other DAOs that function as attestation verifiers (i.e. Closer or Station: DAOs that are providing a profile for the DAOs implementing the Membership Schema), which implement at attestation endpoint that can consume member objects and return the list of all the organizations they belong to, including their DAO URI. What is returned is effectively conceived of as a web3 CV.
These DAO attestation verifiers are intended to prevent DAOs from having too much control over the member object. For example, an attestation originating DAO could change the off-chain member object, effectively no longer registering an address as belonging to the membership of the DAO. DAO attestation verifiers would track the history of member objects from attestation originating DAOs as a way of recording past/historic attestation.
There are questions around whether there should be additional expectations set for attestation verifiers besides hosting an attestation endpoint (particularly since they may be handling PII).
This overall model is a DAO-level form of member attestation and attestation verification that redundantly records membership at the level of off-chain data (JSON-LD objects).
P2P Models
During the discussion in the VI#5 meeting, this model of a top-level DAO classification of membership based around DAO attestation and verification was raised in contrast to peer-to-peer attestation, where peers function as the Schelling point in attesting to some form of data (in the case of the conversation: contribution data, though this could potentially include membership / member objects).
Integrative Platform as Interface Model
In addition to the DAO level model and the p2p model, there are also experiments by collab.land that are exploring role-/platform(discord)-based VC issuance. This experiment is using the discord handle, not an address, though in many cases collabl.land has access to a user’s address through their token permissioning system, and could thus conceivably also issue the same VC to an Ethereum address. They can also support peer to peer attestation. For example: a user makes a statement on a discord and 10 people give it a thumbs up emoji which could generate some other form of attestation.
In this model, the platform becomes the interface through which the bot functions like an oracle and issues VCs. This requires some level of trust in relation to the bot (note that there have been recent hacks of collab.land). The next phase in this experiment would involve having everyone in a discord trigger an event and have this attestation signed by their keys, which would eliminate the need for the bot as the intermediary.
Regardless of the model, we need DAOs to consume the information (the VCs) that are being generated in order to build reputation models, otherwise the VCs themselves are meaningless.
In regards to p2p attestation, DisCo is thinking about this, more in the “civil schemas” direction.
We should have Ese and Evin speak about this during one of the WG meetings
In addition to all of the above, and especially in the context of p2p attestation, the question of proof of humanity (PoH) is raised in the context of BrightID. It is unclear how this standard relates to PoH social attestation.
Reflections on the Proposed and Alternative Models
Mendez is thinking that the membership and the identity might evolve independent of each other. I think the implication of this is that the WG is less focused on identity than it is on representations of membership objects, though this question of the level of abstraction that membership resides at is raised in the following discussion.
Aaron: The attestation model, and the idea of standardizing attestation is interesting, but outside of discovery, it isn’t clear what use cases there are for this information. The reason this is the case is because each DAO defines membership differently from each other (this is in part their autonomous nature at play). Being able to request an attestation from a protocol though is an interesting thing to standardize. For Govrn to be able to request an attestation from Closer has a value. Question: is there a standard for attestation GIVES and attestation REQUESTS?
Cent: what role does more regular attestation and expiry play in this attestation give and requests question?
Rouven: There are usually two alternatives here. One is to have regular expiry times, say every two weeks or every month for something like employment. Depending on the usecase, we could issue something on a daily, monthly, yearly basis. You can also, as an individual, go to your employer and ask to be confirmed today (this could be done through a contract).
Mendes: Would this remove the need for any revocation at all? I’m thinking of the scenario where a user can have multiple identities, and either us, a third party, or the user itself can issue a zkproof saying I have a third identity that you don’t know about, and there is proof that I own this token, so give me access to this DAO.
Discussion of Membership and Use Cases
Josh: We should take a step back and approach this membership question directly, focusing on specific use cases.
Prapion: Potentially a role-based model. This was previously discussed in the collab.land integrative platform as interface model.
Aaron: My hypothesis is that the only difference between DAO protocols is going to be how we define membership. IF you look at any DAO tool, the key difference is how they are defining membership and what you can do with that membership.
Membership Distinctions
Josh: Membership can be thought of in two distinct ways.
The meaning membership according to the contract itself, and
the notion of membership that a DAO might chose to publish externally
Are we trying to target the first or second form of membership? That is, are we trying to offer insight into the underlying nature of the DAO itself and how it structures membership (tokens, voting permissions, etc.), or are we try to accommodate a one off attestation saying that this person has participated with us and here is a more bespoke description of what the DAO’s attestation means?
Prapion: The answer to this question depends on our purpose. If the purpose is to get some clarification on a person, membership at the level of the DAO’s structure is enough. If I want to know if I can trust the person in some sort of affairs, then I want to know both about the DAO’s structure and what the DAO thinks about that person.
Josh: My vision of success in this is: DAOs are incentivized to integrate and use this standard for listing DAO-attested membership in away that is seamless and easy to do.
Aaron: If that is what success looks like, then this track that the WG is on is fine. However, I don’t think that DAO discoverability is the problem that DAOs face. People are not not joining DAOs because they can’t discover them; they aren’t joining DAOs because DAOs have problems working, and DAOs are failing to provide value.
Mendes: It isn’t up to us to determine what membership is for a DAO, which is why having the descriptive membership field is important. What companies and protocols can do at most is attest that that requirement is bad.
Aaron: Someone could have access to a dWork board, access to a Closer space, voting rights at DAOHaus, and access to a Govern instance of contributions. Each of these are layers in the circle of what you are, as a member. This means that membership is an interdependent aggregation of access and permissions with DAOs.
identity is limited to correlated data within a single system
ignores the consequences of common identifications across different systems for the sake of simplicity and feature management
also ignores how that data came to be, what is done with it, and how it is governed
focused on bits and bytes and no on processes involved
Â
Relationship
identity emerging through interactions and relationsips with others
identity is not defined in isolation, but in the relationships we have
Ubuntu: I am because we are
Q: How is this person related?
“Are you now, or have you ever been, a member of the communist party?”
relationships often hold true across context when our physical traits do not
“Relationships are given and earned through interactions with others, never to be fully perceived by any one observer, never to be fully known or captures at any point in time.”
this model most directly embraces the fundamental fluidity of identity
more p2p
Â
Capability
identity in terms of an individual’s actual capability to perform some task
including their physical ability now, in the past, or in the future
inevitable approach for anyone in an emergency
Q: What can the subject actually do?
Capabilities combine both the ability and the will to execute
identity’s capability is a test of one’s willingness and ability to take action
in the context of DAOs, what use s past history of ability without a metric of willingness?
sometimes you may need something so much that it is less important that someone is licensed to than it is that they are able to do what is needed
this model has some parallel with the blockchain space, take this example:
ultimately, a capability is only verifiable by testing it, and even then that test may prove valid only in a highly specific context
Â
Intersections of Mental Models: Patterns and Pitfalls
Intersection between Space-time and Attribute
Conversation typically leads to these two questions:
What are the minimum attributes to identify a particular (physical) individual?, and
Given the data we have, how can we identify particular individuals?
Naive implementations leave to oversampling, aka surveillance
Can also lead to overconfidence in conclusions abut a physical person based on attributes stored in a database, aka tyranny of data
official record indicating someone is dead, when clearly they are not
subsidies people need to live are denied as a result of errors in the Aadhaar identity service
intersects when a capability implies a relationship or vice versa
this seems like the position/contradiction this WG is working through
similar to caste systems such as european aristocracy
familial relationships are suitable indicators of ability to perform certain societal roles
mythical example (which DAOs are not immune to): King Arthur’s ability to remove the sword from the stone proved his lineage and right to govern the kingdom
capability re-established relationship with kingdom
Â
Intersection between Presentation and Relationship
identity does not belong to one entity alone
it is built on the perception the observer has of the subject
moving beyond bilateral interactions to societal engagements, social norms dictate what information share is expected, conventional, and allowed
these both enable and restrict freedom of presentation
self-asserting information may be enough for certain types of data, but not others
this is where truth based on the assertion of known actors is important
information is projected from the source, filtered and presented by the holder, and interpreted through the lens of the relying party
no one party is in sole control of the meaning
architecture of verifiable credentials
see this flow:
Â
Issuer (I) = Subject
Receiver
Verifier (V) = Relying Party
DAO or P2P consensus = I
Creates and stores a DID for a VC
The I request may or may not need to verify the identity of R
A DAO may be an I and/or a V that issues VC and receives VPs (verified presentations)
A persona presents, in data, information about a subject, as presented by that subject to others
This is a subset of information that a subject could present (and independent of what may have been recorded about the subject)
This is an attribute-centric vehicle for presenting identity information
Neither the totality of the subject’s information, nor
the only data known about them
An individual may present different persona in different context, sharing different information with difference recipients (verifiers) at different times
(This seems like one reason to valorize capability in so far as it is possible, since that information is not as deleterious in terms of omission. It is cumulative.)
Self-asserted claims are at this intersection
presenting an attribute of their own authority
Â
Intersection between Attribute and Relationship
we interpret data differently based on the relationship we have with its source
social constructs shape the way entities deal with matters of fact
for example: how time is handled differs depending on where you originally come from
matchmaking services try to create relationships between individuals based on their affinity as measured by their common attributes
data analytics do something similar when evaluating known attributes of individuals to seek out patterns and relationships
sometimes data is used to infer a common group dynamics related to life events, buying patterns, or explicit relationships
Â
Notes and Brainstorming on Developments to the Current DAOIP Proposed Model
Based on the discussion above, the following are some suggested developments and guiding principles that attempt to take one step back from membership towards a minimum verification of affiliation (MVA) based on interaction with a standardized contract that checks data, and if verified is added to the equivalent of a member object.
The data submitted/read would include on-chain data pertinent to access-based assets (NFTs, Tokens, Transactions, etc.) that must satisfy only a minimum amount of criterial across a broad range of DAO structures (distinction #1 from above). Beyond meeting this on-chain based minimum verifiable affiliation, the data submitter would also be able to submit finer details of interaction with a DAO for verification, with the data working in a mutable off-chain self-sovereign identity model with per-DAO permissions set by the submitter of the data using something like DIDs, potentially in conjunction with a tool such as Ceramic.
The developments here attempt to highlight both the individual’s UX as well as DAOs’ use cases and implementations.
Remember that this is only a first pass stream of conscious that needs to be reviewed and refined before being subject to any serious scrutiny. Please check again in at least three days for a more developed version of the following outline.
Â
UX Principles
I want the ability to issue a claim to some activity as recognized across DAOs through a standard spec.
I want to be able to relate some activity tied to data that I own in a sovereign manner (thus on-chain) with the activities recognized by a DAO which is emiting a DAO URI.
I want to be able to have control over what data I hold in my data set (think Solid Pod, or DID) is exposed to other DAOs that have adopted the EIP-4842 and Voyager Identity standards.
I want to interact with a DAO that regularly checks the data I expose to their standard and verifies that the data still confers attestation of data validity.
I want a clearly defined Minimum Verifiable Affiliation that keeps me in a DAO’s registry of known identities.
I want this MVA to be something that other DAOs provide a pathway (or gateway) to recognition.
This might be a standardized contract that DAOs can implement that would allow individuals to submit their MVAs to their DAO
I want to be able to decide which aspects of my data I reveal to a DAO upon interaction with their contract
A DAO might use this MVA to infer fundamentals about an address
This could be inclusive enough to include protocols that have interacted with DAOs in a productive manner
Â
I assume that individuals have multiple addresses, that they are composed of an address space
I want to be able to create a dedicated DID that is able to incorporate multiple on-chain addresses
I want to be able to submit multiple addresses to this contract to demonstra
Â
“The membership list is being provided by the DAO through the DAO URI”
How does the DAO build this membership list?
This should be self-submitting, from the user, not through the DAO
The DAO should have a standard in place for people to verify that they meet some minimum requirements to be included in their membership
The question then becomes:
Since DAOs do not have a standardized approach towards membership recognition, what would be a necessary threshold for a DAO to recognize an address as belonging to this list?
Minimum affiliation gives an interested reviewer of a DAO’s membership the ability to filter for a specific DAO
The user would then be able to expose additional data that further details their degree of involvement with the DAO, such as:
Have they interacted with their sorcecred program?
When was the last interaction?
This information can be used by custom contract that the DAO makes that extends the MVA context and is able to account for off-chain data?
This would give a DAO the ability to have a base affiliation criteria, say, the DAO wants to know if you have an affiliation with Radicle:
From there, depending on what information the user permitted to be emitted when the DAO calls their DID, the DAO is able to make finer refinements in terms of admittance into the DAO
The question though is, how is that additional, non-verified data, verified through attestation?
The standard that a DAO implements as a contract that an address can interact with should be able to account for the broad range of information that DAOs might want to query
That information should not be stored on-chain though, and the user/address should only be given a basic MVA in return after interacting with the contract. Because the standard is broad, a DAO can then query any given member, and based on what information they decided to expose, be able to use that information in a way that makes sense for how they define membership.
This allows DAOs to automatically add member URIs that include DIDs that members are able to edit off-chain
Both the DAO and the User are able to revoke permissions based on
a) how much information the user wants to emit, and
b) how compliant the data emitted from the user is with the DAO’s standard for defining MVA
Again, this gives the user control over how much information they share, they are self submitting to the DAO standard, and any toher DAO is able to queery that information on a DAO by DAO basis to see the information that the user is emitting via their DID (perhaps something like ceramic with vision control and history of changes?)
It is possible to have some type of relationship to Poster such that any time a user make a change to their DID, that information gets sent to the DAO contract for reverification, and propagates across the network of DAOs that are dependent on the information being emitted by that DAO.
How would offboarding/forced-removal work in this case?
Perhaps the DID is primarily for storing off-chain information, almost like private metadata that the use gets to chose to emit,
And the on-chain information is what ultimately has the potential to automatically revoke MVA with a DAO.
This means that other DAOs should not make use of the MVA as the sole index for membership in their DAO, and that they should either require some metadata be exposed through the DID (which the use controls), or use the MVA as a means of granting or sending some on-chain element that affords them MVA with their DAO.
I want to be able to issue multiple DIDs, one for each time I interact with a DAO MVA contract such that I am only choosing to emit the information I want to emit for that specific DAO.
Â
Contract for intaking/verifying address submission
Reads from the DID based on the permissions granted to the DAO by the DID holder
If the on chain information conforms to the DAO MVA standard, then
the DID with the permissions that the user set for that specific DAO is consumed by the contract and set to periodically confirm which ever information is exposed
In any case, the DID is included in the MVA Schema
The DID method has to be complient with the DAO MVA standard
As in, the DID needs to be consumable by the DAO in order to confirm that each element in the DID is or is not complient with the DAO
Â
Resultant DAO MVA Schema
{"@context":"http://www.daostar.org/schemas","type":"DAO","name":"<name of the DAO>",
Â
Building off the Ceramic Schemas, DAO*1 should create a dao-affiliations schema
The Index should include the DAO (based off the DAO URI schema)
This is an endpoint of the identity standard, being included in the index
The stream is a mutable datastore on Ceramic that can contain VCs
The user is able to decide which VCs they expose based on which IDX they are submitting. A user is able to have multiple IDXs that reflect different aspects of their identity that they would like to be consumed and queried by applications
For example, you could have a profile that links to one of your discord alts with the social accounts schema, a specific crypto account used by that user, a basic profile, any blog posts or photos that that user wishes to associate with that identity and, in the case of DAOs, any DAOs that they are related to.
Everything in the above index is user defined and not attested
How would a person be able to verify that they are affiliated or a member of a DAO
The document provides a summary of the discussion during the Voyager Identity #5 Meeting. Following the summary is the beginning of a proposal that attempts to develop on the DAOIP model in light of the discussion. The proposal points to a different architecture of where the UX of persons/addresses seeking attestation from a DAO are centered, and a finer distinction between on and off chain data sources and their relationship to membership are made.
Â
The proposal development is still in a highly sketched out WIP form, and needs to be more clearly outlined and formulated. The primary focus over the next two days should be to review the summary of the discussion, and leave comments. This document will be relinked in at least two days with a more developed iteration of the proposal development that follows the summary.
Â
To compliment the summary of models discussed in the previous call, this document also outlines five mental models of identity for clarifying the focus and intentions of this WG.
Key Documents:
Summary of Conversation
Proposed Model and Alternative Models
DAO-Level Model
The current spec of DAOIP involves a DAO implementing an extension of the EIP-4842 Membership JSON-LD Schema. This implementation allows a DAO to define membership through a variety of inputs such at NFTs, ERC-20 tokens, Whitelists, Gnosis Safe multi-sigs, etc. Membership is formulated into a member object.
Separate from the DAO generated member object are other DAOs that function as attestation verifiers (i.e. Closer or Station: DAOs that are providing a profile for the DAOs implementing the Membership Schema), which implement at attestation endpoint that can consume member objects and return the list of all the organizations they belong to, including their DAO URI. What is returned is effectively conceived of as a web3 CV.
These DAO attestation verifiers are intended to prevent DAOs from having too much control over the member object. For example, an attestation originating DAO could change the off-chain member object, effectively no longer registering an address as belonging to the membership of the DAO. DAO attestation verifiers would track the history of member objects from attestation originating DAOs as a way of recording past/historic attestation.
There are questions around whether there should be additional expectations set for attestation verifiers besides hosting an attestation endpoint (particularly since they may be handling PII).
This overall model is a DAO-level form of member attestation and attestation verification that redundantly records membership at the level of off-chain data (JSON-LD objects).
P2P Models
During the discussion in the VI#5 meeting, this model of a top-level DAO classification of membership based around DAO attestation and verification was raised in contrast to peer-to-peer attestation, where peers function as the Schelling point in attesting to some form of data (in the case of the conversation: contribution data, though this could potentially include membership / member objects).
Integrative Platform as Interface Model
In addition to the DAO level model and the p2p model, there are also experiments by collab.land that are exploring role-/platform(discord)-based VC issuance. This experiment is using the discord handle, not an address, though in many cases collabl.land has access to a user’s address through their token permissioning system, and could thus conceivably also issue the same VC to an Ethereum address. They can also support peer to peer attestation. For example: a user makes a statement on a discord and 10 people give it a thumbs up emoji which could generate some other form of attestation.
In this model, the platform becomes the interface through which the bot functions like an oracle and issues VCs. This requires some level of trust in relation to the bot (note that there have been recent hacks of collab.land). The next phase in this experiment would involve having everyone in a discord trigger an event and have this attestation signed by their keys, which would eliminate the need for the bot as the intermediary.
Regardless of the model, we need DAOs to consume the information (the VCs) that are being generated in order to build reputation models, otherwise the VCs themselves are meaningless.
In regards to p2p attestation, DisCo is thinking about this, more in the “civil schemas” direction.
We should have Ese and Evin speak about this during one of the WG meetings
In addition to all of the above, and especially in the context of p2p attestation, the question of proof of humanity (PoH) is raised in the context of BrightID. It is unclear how this standard relates to PoH social attestation.
Reflections on the Proposed and Alternative Models
Mendez is thinking that the membership and the identity might evolve independent of each other. I think the implication of this is that the WG is less focused on identity than it is on representations of membership objects, though this question of the level of abstraction that membership resides at is raised in the following discussion.
Aaron: The attestation model, and the idea of standardizing attestation is interesting, but outside of discovery, it isn’t clear what use cases there are for this information. The reason this is the case is because each DAO defines membership differently from each other (this is in part their autonomous nature at play). Being able to request an attestation from a protocol though is an interesting thing to standardize. For Govrn to be able to request an attestation from Closer has a value. Question: is there a standard for attestation GIVES and attestation REQUESTS?
Cent: what role does more regular attestation and expiry play in this attestation give and requests question?
Rouven: There are usually two alternatives here. One is to have regular expiry times, say every two weeks or every month for something like employment. Depending on the usecase, we could issue something on a daily, monthly, yearly basis. You can also, as an individual, go to your employer and ask to be confirmed today (this could be done through a contract).
Mendes: Would this remove the need for any revocation at all? I’m thinking of the scenario where a user can have multiple identities, and either us, a third party, or the user itself can issue a zkproof saying I have a third identity that you don’t know about, and there is proof that I own this token, so give me access to this DAO.
Discussion of Membership and Use Cases
Josh: We should take a step back and approach this membership question directly, focusing on specific use cases.
Prapion: Potentially a role-based model. This was previously discussed in the collab.land integrative platform as interface model.
Aaron: My hypothesis is that the only difference between DAO protocols is going to be how we define membership. IF you look at any DAO tool, the key difference is how they are defining membership and what you can do with that membership.
Membership Distinctions
Josh: Membership can be thought of in two distinct ways.
The meaning membership according to the contract itself, and
the notion of membership that a DAO might chose to publish externally
Are we trying to target the first or second form of membership? That is, are we trying to offer insight into the underlying nature of the DAO itself and how it structures membership (tokens, voting permissions, etc.), or are we try to accommodate a one off attestation saying that this person has participated with us and here is a more bespoke description of what the DAO’s attestation means?
Prapion: The answer to this question depends on our purpose. If the purpose is to get some clarification on a person, membership at the level of the DAO’s structure is enough. If I want to know if I can trust the person in some sort of affairs, then I want to know both about the DAO’s structure and what the DAO thinks about that person.
Josh: My vision of success in this is: DAOs are incentivized to integrate and use this standard for listing DAO-attested membership in away that is seamless and easy to do.
Aaron: If that is what success looks like, then this track that the WG is on is fine. However, I don’t think that DAO discoverability is the problem that DAOs face. People are not not joining DAOs because they can’t discover them; they aren’t joining DAOs because DAOs have problems working, and DAOs are failing to provide value.
Mendes: It isn’t up to us to determine what membership is for a DAO, which is why having the descriptive membership field is important. What companies and protocols can do at most is attest that that requirement is bad.
Aaron: Someone could have access to a dWork board, access to a Closer space, voting rights at DAOHaus, and access to a Govern instance of contributions. Each of these are layers in the circle of what you are, as a member. This means that membership is an interdependent aggregation of access and permissions with DAOs.
identity is limited to correlated data within a single system
ignores the consequences of common identifications across different systems for the sake of simplicity and feature management
also ignores how that data came to be, what is done with it, and how it is governed
focused on bits and bytes and no on processes involved
Â
Relationship
identity emerging through interactions and relationsips with others
identity is not defined in isolation, but in the relationships we have
Ubuntu: I am because we are
Q: How is this person related?
“Are you now, or have you ever been, a member of the communist party?”
relationships often hold true across context when our physical traits do not
“Relationships are given and earned through interactions with others, never to be fully perceived by any one observer, never to be fully known or captures at any point in time.”
this model most directly embraces the fundamental fluidity of identity
more p2p
Â
Capability
identity in terms of an individual’s actual capability to perform some task
including their physical ability now, in the past, or in the future
inevitable approach for anyone in an emergency
Q: What can the subject actually do?
Capabilities combine both the ability and the will to execute
identity’s capability is a test of one’s willingness and ability to take action
in the context of DAOs, what use s past history of ability without a metric of willingness?
sometimes you may need something so much that it is less important that someone is licensed to than it is that they are able to do what is needed
this model has some parallel with the blockchain space, take this example:
ultimately, a capability is only verifiable by testing it, and even then that test may prove valid only in a highly specific context
Â
Intersections of Mental Models: Patterns and Pitfalls
Intersection between Space-time and Attribute
Conversation typically leads to these two questions:
What are the minimum attributes to identify a particular (physical) individual?, and
Given the data we have, how can we identify particular individuals?
Naive implementations leave to oversampling, aka surveillance
Can also lead to overconfidence in conclusions abut a physical person based on attributes stored in a database, aka tyranny of data
official record indicating someone is dead, when clearly they are not
subsidies people need to live are denied as a result of errors in the Aadhaar identity service
intersects when a capability implies a relationship or vice versa
this seems like the position/contradiction this WG is working through
similar to caste systems such as european aristocracy
familial relationships are suitable indicators of ability to perform certain societal roles
mythical example (which DAOs are not immune to): King Arthur’s ability to remove the sword from the stone proved his lineage and right to govern the kingdom
capability re-established relationship with kingdom
Â
Intersection between Presentation and Relationship
identity does not belong to one entity alone
it is built on the perception the observer has of the subject
moving beyond bilateral interactions to societal engagements, social norms dictate what information share is expected, conventional, and allowed
these both enable and restrict freedom of presentation
self-asserting information may be enough for certain types of data, but not others
this is where truth based on the assertion of known actors is important
information is projected from the source, filtered and presented by the holder, and interpreted through the lens of the relying party
no one party is in sole control of the meaning
architecture of verifiable credentials
see this flow:
Â
Issuer (I) = Subject
Receiver
Verifier (V) = Relying Party
DAO or P2P consensus = I
Creates and stores a DID for a VC
The I request may or may not need to verify the identity of R
A DAO may be an I and/or a V that issues VC and receives VPs (verified presentations)
A persona presents, in data, information about a subject, as presented by that subject to others
This is a subset of information that a subject could present (and independent of what may have been recorded about the subject)
This is an attribute-centric vehicle for presenting identity information
Neither the totality of the subject’s information, nor
the only data known about them
An individual may present different persona in different context, sharing different information with difference recipients (verifiers) at different times
(This seems like one reason to valorize capability in so far as it is possible, since that information is not as deleterious in terms of omission. It is cumulative.)
Self-asserted claims are at this intersection
presenting an attribute of their own authority
Â
Intersection between Attribute and Relationship
we interpret data differently based on the relationship we have with its source
social constructs shape the way entities deal with matters of fact
for example: how time is handled differs depending on where you originally come from
matchmaking services try to create relationships between individuals based on their affinity as measured by their common attributes
data analytics do something similar when evaluating known attributes of individuals to seek out patterns and relationships
sometimes data is used to infer a common group dynamics related to life events, buying patterns, or explicit relationships
Â
Notes and Brainstorming on Developments to the Current DAOIP Proposed Model
Based on the discussion above, the following are some suggested developments and guiding principles that attempt to take one step back from membership towards a minimum verification of affiliation (MVA) based on interaction with a standardized contract that checks data, and if verified is added to the equivalent of a member object.
The data submitted/read would include on-chain data pertinent to access-based assets (NFTs, Tokens, Transactions, etc.) that must satisfy only a minimum amount of criterial across a broad range of DAO structures (distinction #1 from above). Beyond meeting this on-chain based minimum verifiable affiliation, the data submitter would also be able to submit finer details of interaction with a DAO for verification, with the data working in a mutable off-chain self-sovereign identity model with per-DAO permissions set by the submitter of the data using something like DIDs, potentially in conjunction with a tool such as Ceramic.
The developments here attempt to highlight both the individual’s UX as well as DAOs’ use cases and implementations.
Remember that this is only a first pass stream of conscious that needs to be reviewed and refined before being subject to any serious scrutiny. Please check again in at least three days for a more developed version of the following outline.
Â
UX Principles
I want the ability to issue a claim to some activity as recognized across DAOs through a standard spec.
I want to be able to relate some activity tied to data that I own in a sovereign manner (thus on-chain) with the activities recognized by a DAO which is emiting a DAO URI.
I want to be able to have control over what data I hold in my data set (think Solid Pod, or DID) is exposed to other DAOs that have adopted the EIP-4842 and Voyager Identity standards.
I want to interact with a DAO that regularly checks the data I expose to their standard and verifies that the data still confers attestation of data validity.
I want a clearly defined Minimum Verifiable Affiliation that keeps me in a DAO’s registry of known identities.
I want this MVA to be something that other DAOs provide a pathway (or gateway) to recognition.
This might be a standardized contract that DAOs can implement that would allow individuals to submit their MVAs to their DAO
I want to be able to decide which aspects of my data I reveal to a DAO upon interaction with their contract
A DAO might use this MVA to infer fundamentals about an address
This could be inclusive enough to include protocols that have interacted with DAOs in a productive manner
Â
I assume that individuals have multiple addresses, that they are composed of an address space
I want to be able to create a dedicated DID that is able to incorporate multiple on-chain addresses
I want to be able to submit multiple addresses to this contract to demonstra
Â
“The membership list is being provided by the DAO through the DAO URI”
How does the DAO build this membership list?
This should be self-submitting, from the user, not through the DAO
The DAO should have a standard in place for people to verify that they meet some minimum requirements to be included in their membership
The question then becomes:
Since DAOs do not have a standardized approach towards membership recognition, what would be a necessary threshold for a DAO to recognize an address as belonging to this list?
Minimum affiliation gives an interested reviewer of a DAO’s membership the ability to filter for a specific DAO
The user would then be able to expose additional data that further details their degree of involvement with the DAO, such as:
Have they interacted with their sorcecred program?
When was the last interaction?
This information can be used by custom contract that the DAO makes that extends the MVA context and is able to account for off-chain data?
This would give a DAO the ability to have a base affiliation criteria, say, the DAO wants to know if you have an affiliation with Radicle:
From there, depending on what information the user permitted to be emitted when the DAO calls their DID, the DAO is able to make finer refinements in terms of admittance into the DAO
The question though is, how is that additional, non-verified data, verified through attestation?
The standard that a DAO implements as a contract that an address can interact with should be able to account for the broad range of information that DAOs might want to query
That information should not be stored on-chain though, and the user/address should only be given a basic MVA in return after interacting with the contract. Because the standard is broad, a DAO can then query any given member, and based on what information they decided to expose, be able to use that information in a way that makes sense for how they define membership.
This allows DAOs to automatically add member URIs that include DIDs that members are able to edit off-chain
Both the DAO and the User are able to revoke permissions based on
a) how much information the user wants to emit, and
b) how compliant the data emitted from the user is with the DAO’s standard for defining MVA
Again, this gives the user control over how much information they share, they are self submitting to the DAO standard, and any toher DAO is able to queery that information on a DAO by DAO basis to see the information that the user is emitting via their DID (perhaps something like ceramic with vision control and history of changes?)
It is possible to have some type of relationship to Poster such that any time a user make a change to their DID, that information gets sent to the DAO contract for reverification, and propagates across the network of DAOs that are dependent on the information being emitted by that DAO.
How would offboarding/forced-removal work in this case?
Perhaps the DID is primarily for storing off-chain information, almost like private metadata that the use gets to chose to emit,
And the on-chain information is what ultimately has the potential to automatically revoke MVA with a DAO.
This means that other DAOs should not make use of the MVA as the sole index for membership in their DAO, and that they should either require some metadata be exposed through the DID (which the use controls), or use the MVA as a means of granting or sending some on-chain element that affords them MVA with their DAO.
I want to be able to issue multiple DIDs, one for each time I interact with a DAO MVA contract such that I am only choosing to emit the information I want to emit for that specific DAO.
Â
Contract for intaking/verifying address submission
Reads from the DID based on the permissions granted to the DAO by the DID holder
If the on chain information conforms to the DAO MVA standard, then
the DID with the permissions that the user set for that specific DAO is consumed by the contract and set to periodically confirm which ever information is exposed
In any case, the DID is included in the MVA Schema
The DID method has to be complient with the DAO MVA standard
As in, the DID needs to be consumable by the DAO in order to confirm that each element in the DID is or is not complient with the DAO
Â
Resultant DAO MVA Schema
{"@context":"http://www.daostar.org/schemas","type":"DAO","name":"<name of the DAO>",
Â
Building off the Ceramic Schemas, DAO*1 should create a dao-affiliations schema
The Index should include the DAO (based off the DAO URI schema)
This is an endpoint of the identity standard, being included in the index
The stream is a mutable datastore on Ceramic that can contain VCs
The user is able to decide which VCs they expose based on which IDX they are submitting. A user is able to have multiple IDXs that reflect different aspects of their identity that they would like to be consumed and queried by applications
For example, you could have a profile that links to one of your discord alts with the social accounts schema, a specific crypto account used by that user, a basic profile, any blog posts or photos that that user wishes to associate with that identity and, in the case of DAOs, any DAOs that they are related to.
Everything in the above index is user defined and not attested
How would a person be able to verify that they are affiliated or a member of a DAO
