🚀

Attestations for DAOs [DEPRECATED]

Minimal project management section!

For DAOs: attestationIssuers and issuerURI

For Issuers: Attestation Endpoints

Extensions

Rationale

Example

For DAOs: attestationIssuers and issuerURI

Expiration

Leave for future work

Reference Implementation

CUT

Additional text for attestationIssuers

For Issuers: Attestation Endpoints

Background and edge-cases

Cut from long example

Minimal project management section!

Talk to:

Isaac + Spencer (DAOhaus, also look at Hats Protocol)

James Young (take a look at Nuggets)

Raz (guild.xyz)

Writing

Rationale section

Write up in the rationale how this standard relates to typical use-cases involving NFTs and SBTs (ref. notes from call with Balazs on kycDAO).

Write a user story into the rationale where a DAO or a service using SBTs, worth thinking about whether if Avenue is consuming SBTs from DAOhaus.

Simple Summary

An attestation-based architecture and data model for DAO membership, member contributions, and other data.

Abstract

This standard provides the basic architecture for a permissionless attestation framework where different parties can make arbitrary and conflicting attestations about DAO membership, member contributions, and other data.

Note: this standard does not specify how DAOs and service providers should handle identity verification & management. We assume that many different identity systems exist in tandem across different DAOs and different service providers. The way these are implemented is left to the discretion of both the DAO and its service providers. Thus, this standard is NOT appropriate for handling personally-identifiable information (PII) or other forms of personal data.

Motivation

What does it mean to contribute to a DAO, and where can people find these contributions? What does it mean to be a member of a DAO, and how can membership be verified?

Contributions and membership are important building blocks within DAOs and related Web3 applications, from Web3 profiles to contribution graphs to measures of participation to interoperable reputation metrics. These systems are often the first settings in which DAOs and DAO service providers need to operationalize their underlying identity systems.

In current DAOs, membership and contributions are commonly defined via ownership of on-chain assets, whether fungible tokens, NFTs, or (more recently) soulbound NFTs. But on-chain definitions miss many important use-cases and risk locking DAOs into very specific modes of membership and organization. For example, a DAO may want to make membership contingent on some (off-chain) measure of participation such as git commits or Discourse posts, while definitions of contributions could vary across each of the (off- and on-chain) services that a DAO uses to track contributions.

daoURI already allows DAOs to publish off-chain data about their membership. This standard composes with daoURI in order to specify a permissionless attestation framework for DAOs and DAO service providers.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

For DAOs: attestationIssuers and issuerURI

All DAOs conforming to DAOIP-## MUST implement the attestationIssuers field as part of daoURI. attestationIssuersis an array of attestation endpoints (see “Attestation Endpoints”, below) hosted by service providers trusted by the DAO to issue attestations on their behalf.

{
	"@context": "<http://www.daostar.org/schemas>",
	"type": "DAO",
	"name": "<name of the DAO>",
	"description": "<description>",
	"attestationIssuers": [
		{
			"type": "AttestationIssuer",

For Issuers: Attestation Endpoints

An attestation issuer, or just issuer, is an entity that issues and manages attestations on behalf of some other entity such as a DAO. 

Every issuer conforming to DAOIP-## MUST implement an issuerURI endpoint describing the issuer and listing endpoints that it supports, following the Attestation Issuer JSON Schema below: 

{
	"@context": "http://www.daostar.org/schemas",
	"type": "issuer",
	"name": "<name of the issuer>",
	"description": "<description>",
	"memberAttestationsURI": "<URI>"
}e

Further, each issuer MUST implement a memberAttestationsURI attestation endpoint which, given a member object as recorded in the daostar.org/schemas context files, returns a list of organizations following the memberAttestationsURI JSON Schema below:

{
	"@context": "http://www.daostar.org/schemas",

In particular, note the inclusion of an expiration field on every attestation.

Further, note that the above schema is designed to attest to a member object by looking up its “identity”, where identity might be determined by Ethereum address, Cosmos address, CAIP-10 address, decentralized identity, ENS, BrightID, Disco, or any other service with a recognized identity type.

Extensions

Issuers that wish to extend the attestation framework above to attestations about things other than membership or contribution can use the following schema for their attestations:

{
	"@context": "http://www.daostar.org/schemas",
	"type": "attestation",
	"expiration": "ISO-datetime",
	"attestationURI": "<the URI from which someone can obtain the attestation>"
}

Rationale

This attestation framework is designed to support multi-party integrations between DAOs and DAO service providers, including use-cases related to Web3 profiles and Web3 CVs that do not assume any identity system or verification system such as verifiable credentials or soulbound tokens.

Example

Let’s take a hypothetical example featuring two DAOs (DAOstar One and groundw3rk) and three attestation issuers (Disco, Govrn, and Avenue). Assume a user owns two different addresses: josh.eth and joshua.eth.

Through their two addresses, the user belongs to two DAOs:

josh.eth owns enough DAO tokens to be a member of DAOstar One

joshua.eth owns an NFT needed to be a member of groundw3rk

Our user logs into Avenue using josh.eth. When a third-party queries Avenue’s attestation endpoint, the response should be:

{
	"@context": "http://www.daostar.org/schemas",
	"type": "arrayAttestation",
	"issuer": "<Avenue's issuerURI>",
	"member": {
		"type": "ENS",
		"id": "josh.eth"
	},
	"organizations": [
		{
			"expiration": "<ISO-datetime>",
			"attesterURI": "<DAOStar One's membersURI>",
			"name": "DAOstar One",
			"daoURI": "<DAOStar One's daoURI, following EIP-4824>"
		}
	]
}

Let’s now assume DAOStar One is using Govrn to track contributions and Avenue is integrating with Govrn to track data.

Any contributions the user allows to be publicly shared will also be available to Avenue. Even though a client would be querying Avenue’s attestation endpoint, the contributions field would relay any contributions made by Govrn. Querying the previous endpoint would return:

{
	"@context": "http://www.daostar.org/schemas",
	"type": "arrayAttestation",
	"issuer": "<Avenue's issuerURI>",
	"member": {
		"type": "ENS",
		"id": "josh.eth"
	},
	"organizations": [
		{
			"expiration": "<ISO-datetime>",
			"attesterURI": "<DAOStar One's membersURI>",
			"name": "DAOstar One",
			"daoURI": "<DAOStar One's daoURI, following EIP-4824>"
		}
	],
	"contributions": [
		{
			"type": "contribution",
			"commit_type": "tweet",
			"reference?": "<URI reference to the tweet on Govrn's platform>",
			"attesterURI": "<Govrn's issuerURI>"
		},
}

Notice the contributions field includes information issued by Govrn and relayed by Avenue. Making use of this information relay allows tools to easily integrate with a single one of the issuers but still have access to data of others without being aware of any implementation details. At the same time, there’s still confidence in the data being relayed since it can be validated by the reference field.

Let’s assume now that Avenue also integrates with Disco. Disco, in turn, attests user identities. If the user links both profiles (josh.eth and joshua.eth) in Disco, even though the former only has token access to DAOStar One, Disco can issue an attestation that it should be able to access groundw3rk as well. In essence, Disco is stating “josh.eth has tokens to access DAOStar One but, even though you can’t see it, I guarantee you its owner also has an address with the NFT to access groundw3rk”.

This is represented by returning the following data in Discos’ issuer endpoint:  

{
	"@context": "http://www.daostar.org/schemas",
	"type": "arrayAttestation",
	"issuer": "<Disco's issuerURI>",
	"member": {
		"type": "ENS",
		"id": "josh.eth"
	},
	"organizations": [
		{
			"expiration": "<ISO-datetime>",
			"attesterURI": "<DAOStar One's membersURI>",
			"name": "DAOstar One",
			"daoURI": "<DAOStar One's daoURI, following EIP-4824>"
		},
		{
			"expiration": "<ISO-datetime>",
			"attesterURI": "<Disco's URI>",
			"name": "groundw3rk",
			"daoURI": "<groundw3rk's daoURI, following EIP-4824>"
		}
	]
}

Notice how the attesterURI in this scenario points to Disco’s own URI. A third-party using this information to token gate access to a DAO should decide if they trust Disco’s attestation.

For DAOs: attestationIssuers and issuerURI

The basic use-case for a DAO using attestationIssuers and issuerURI is so that the DAO can (1) declare what services they use, along with the data published by those service providers, and (2) to declare to other services where “authorized” third party data is being maintained about members of the data.

Expiration

Since attestations can be easily (and freely) issued by the DAO issuer contract or a trusted party, we propose adding an expiry timestamp to the attestation schema. Having a (short-lived) self-expiring attestation avoids the rigmarole of maintaining a revocation registry and the underlying issues of trust and access to it.

With self-revoking credentials, the problem of storing is partially solved: they can at any time be reissued by the DAO contract or the trusted party. The approach also adds flexibility for storage by the user themselves (e.g. via a browser extension, that could potentially automatically refresh expired credentials).

Copyright

Copyright and related rights waived via CC0.

Leave for future work

We can’t fit everything we’d like in a single standard. Here’s what we cut:

richer metadata (emphasis on enabling contributor-centric data instead of just member data)

extensions to membersURI

verifiability of attestations & credentials (meaning we are NOT doing verifiable credentials right now!)

revocability & editability of an attestation

questions about privacy—right now, all attestations are public

questions about consent—how do we make sure people don’t get spammed?

Reference Implementation

📓

Specification

CUT

Definitions

PII

Attestation Architecture

Extensions to membersURI

💡

Use-case for permissioning. Right now, many DAOs are using NFT badges as a workaround to get around access + permissioning. Common problem: people want a way of issuing guest passes and permissions. And they rely on centralized services and processes to issue those tokens. Could this attestation framework help there?

💡

We should discuss how granular the expiration timestamp should be.

🖊️

Use-case for on-chain issuers. Why would an on-chain issuer of NFTs or SBTs want to publish an off-chain API attesting to who owns which NFTs? Does DAOstar need to issue a API proxy for on-chain issuers? Probably, yes, at least for convenience reasons. I.e. if an issuer is publishing some form of data on-chain (whether NFTs, SBTs, or just data into a public method), they will need to demonstrate control over an off-chain API. We should re-use the API manager contract from Strike Team WG.

Additional text for attestationIssuers

The most common scenario for membership is owning a digital asset, for which we propose that the DAO deploys an issuance contract that checks against the main contract for the ownership of the said asset. Besides covering most scenarios, this also composes well with contract upgrades. Third-party tools should check for that user-provided attestation (assuming it’s structurally valid and hasn’t expired) instead of performing on-chain verification. 

If the membership requirements are more complex - taking the example of owning a token or an NFT or a guest pass or belong to a sub-DAO - the attestation can be valid for either one of those. In this example, the attestation itself can act as the entry point for authorization in third-parties: if a user only has a valid attestation for a sub-group, they should only see assets or features related to that.

For Issuers: Attestation Endpoints

💡

Question: Should attestation issuers provide provenance information for their attestations, i.e. whether it came from the DAO, from the user, from the issuer itself, or some combination thereof? Question: an issuer may also issue secondary, “derived” attestations where the DAO first emits an attestation and then an issuer issues it again. Question: how can we support easy sorting of attestations from many issuers? Question: should issuers be expected to demonstrate or prove some kind of trustworthiness? Question: Should attestation endpoints include the public keys [to…]? What are the security implications of doing so?

Background and edge-cases

Polygon DAO: anyone who owns a secret (a zk-proof that you issue?) is a member of the DAO? works with their system fo zk verification their polygon ID system?

Polygon DAO also had a very interesting use-case for requirements to join the DAO; “having received USDC for completing a project”. Had tool that checks this.

Talking with Evin: had a few interesting opinions about the work we’re doing, because they’re super interested in a standard like this.

💡

Maintaining records of attestations. We expect issuers (and DAOs) or any entity who wants to consume attestations will have to have their own process for dealing with expired attestations and for re-upping existing attestations.

💡

Are there additional expectations we have for issuers BESIDES hosting an attestation endpoint, since they might be handling PII? Answer: no, we don’t cover PII use-cases here.

Cut from long example

There is also the possibility of third parties accepting attestations from issuers not described in the issuerURI field. Take the example of a user not wanting to reveal the identity in which they own a token, but wanting to get access to the DAO with a secondary identity. In this scenario, the DAO could still have a smart contract as the trusted issuer. However, the user could still ask a third party for a VC that covers this scenario. 

In a hypothetical example featuring three attestation issuers, Disco, Govrn, and Avenue:

Disco has knowledge of multiple identities owned by the same person.

Identity idA owns the token, the user wants to make use of idB to access a token-gated feature in Avenue.

Disco can attest that the owner of idB has the token.

The user provides this attestation to Avenue.

At this point, Avenue could check that the DAO schema points to a smart contract but the attestation was issued by Disco. In our proposal, we leave it up to the third parties to choose what happens next. Either Avenue doesn’t trust Disco and therefore doesn’t consider this to be a valid attestation or Avenue does. This can be further discussed as there are other mechanisms for issuer trust. Regardless, the DAO membership requirements are fulfilled without the DAO having to account for more complex scenarios.

{
	"@context": "http://www.daostar.org/schemas",
	"type": "attestation",
	"member": {
		"type": "EthereumAddress",
		"address": "<address>",
	},
	"expiration": "ISO-datetime",
	"issuer": "<issuerURI>",
	"organizations": [
		{
			"type": "DAO",
			"daoURI": "<URI that follows EIP-4824 DAO JSON-LD Schema>",
			"attesterURI": "<DAO1's own membersURI>"
		},
		{
			"type": "DAO",
			"daoURI": "<URI that follows EIP-4824 DAO JSON-LD Schema>", [we should include this even if the attester is NOT the dao] 
			"attesterURI": "<Disco's issuerURI>" [this is Disco claiming that this address should belong to the DAO]
		},
		{ [this is Govrn's attestation that josh.eth is in DAO3]
			"type": "DAO",
			"daoURI": "<URI that follows EIP-4824 DAO JSON-LD Schema>", 
			"attesterURI": "<Govrn's issuerURI>" [this is Govrn claiming that this address should belong to the DAO]
		}
	],
	"contributions": [
		{
			"type": "contribution",
			"commit_type": "code commit",
			"reference?": "<organization or project or reference>", [this would be on GitHub]
			"attesterURI": "<Govrn's issuerURI>" [this would be attested by Govrn]
		},
		{
			"type": "tweet"
			"attesterURI": "<Twitter's issuerURI>"
		}
	],
	"scores": [
		{
			"type": "reputation",
			"attesterURI": "<this should be = daoURI or at least membersURI>"
		}
	]
}

Attestations for DAOs [DEPRECATED]

Minimal project management section!

For DAOs: attestationIssuers and issuerURI

For Issuers: Attestation Endpoints

Extensions

Rationale

Example

For DAOs: attestationIssuers and issuerURI

Expiration

Leave for future work

Reference Implementation

CUT

Additional text for attestationIssuers

For Issuers: Attestation Endpoints

Background and edge-cases

Cut from long example

Minimal project management section!

Talk to:

Isaac + Spencer (DAOhaus, also look at Hats Protocol)

James Young (take a look at Nuggets)

Raz (guild.xyz)

Writing

Rationale section

Write up in the rationale how this standard relates to typical use-cases involving NFTs and SBTs (ref. notes from call with Balazs on kycDAO).

Write a user story into the rationale where a DAO or a service using SBTs, worth thinking about whether if Avenue is consuming SBTs from DAOhaus.

Simple Summary

An attestation-based architecture and data model for DAO membership, member contributions, and other data.

Abstract

This standard provides the basic architecture for a permissionless attestation framework where different parties can make arbitrary and conflicting attestations about DAO membership, member contributions, and other data.

Note: this standard does not specify how DAOs and service providers should handle identity verification & management. We assume that many different identity systems exist in tandem across different DAOs and different service providers. The way these are implemented is left to the discretion of both the DAO and its service providers. Thus, this standard is NOT appropriate for handling personally-identifiable information (PII) or other forms of personal data.

Motivation

What does it mean to contribute to a DAO, and where can people find these contributions? What does it mean to be a member of a DAO, and how can membership be verified?

Contributions and membership are important building blocks within DAOs and related Web3 applications, from Web3 profiles to contribution graphs to measures of participation to interoperable reputation metrics. These systems are often the first settings in which DAOs and DAO service providers need to operationalize their underlying identity systems.

In current DAOs, membership and contributions are commonly defined via ownership of on-chain assets, whether fungible tokens, NFTs, or (more recently) soulbound NFTs. But on-chain definitions miss many important use-cases and risk locking DAOs into very specific modes of membership and organization. For example, a DAO may want to make membership contingent on some (off-chain) measure of participation such as git commits or Discourse posts, while definitions of contributions could vary across each of the (off- and on-chain) services that a DAO uses to track contributions.

daoURI already allows DAOs to publish off-chain data about their membership. This standard composes with daoURI in order to specify a permissionless attestation framework for DAOs and DAO service providers.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

For DAOs: attestationIssuers and issuerURI

All DAOs conforming to DAOIP-## MUST implement the attestationIssuers field as part of daoURI. attestationIssuersis an array of attestation endpoints (see “Attestation Endpoints”, below) hosted by service providers trusted by the DAO to issue attestations on their behalf.

{
	"@context": "<http://www.daostar.org/schemas>",
	"type": "DAO",
	"name": "<name of the DAO>",
	"description": "<description>",
	"attestationIssuers": [
		{
			"type": "AttestationIssuer",

For Issuers: Attestation Endpoints

An attestation issuer, or just issuer, is an entity that issues and manages attestations on behalf of some other entity such as a DAO. 

Every issuer conforming to DAOIP-## MUST implement an issuerURI endpoint describing the issuer and listing endpoints that it supports, following the Attestation Issuer JSON Schema below: 

{
	"@context": "http://www.daostar.org/schemas",
	"type": "issuer",
	"name": "<name of the issuer>",
	"description": "<description>",
	"memberAttestationsURI": "<URI>"
}e

Further, each issuer MUST implement a memberAttestationsURI attestation endpoint which, given a member object as recorded in the daostar.org/schemas context files, returns a list of organizations following the memberAttestationsURI JSON Schema below:

{
	"@context": "http://www.daostar.org/schemas",

In particular, note the inclusion of an expiration field on every attestation.

Further, note that the above schema is designed to attest to a member object by looking up its “identity”, where identity might be determined by Ethereum address, Cosmos address, CAIP-10 address, decentralized identity, ENS, BrightID, Disco, or any other service with a recognized identity type.

Extensions

Issuers that wish to extend the attestation framework above to attestations about things other than membership or contribution can use the following schema for their attestations:

{
	"@context": "http://www.daostar.org/schemas",
	"type": "attestation",
	"expiration": "ISO-datetime",
	"attestationURI": "<the URI from which someone can obtain the attestation>"
}

Rationale

This attestation framework is designed to support multi-party integrations between DAOs and DAO service providers, including use-cases related to Web3 profiles and Web3 CVs that do not assume any identity system or verification system such as verifiable credentials or soulbound tokens.

Example

Let’s take a hypothetical example featuring two DAOs (DAOstar One and groundw3rk) and three attestation issuers (Disco, Govrn, and Avenue). Assume a user owns two different addresses: josh.eth and joshua.eth.

Through their two addresses, the user belongs to two DAOs:

josh.eth owns enough DAO tokens to be a member of DAOstar One

joshua.eth owns an NFT needed to be a member of groundw3rk

Our user logs into Avenue using josh.eth. When a third-party queries Avenue’s attestation endpoint, the response should be:

{
	"@context": "http://www.daostar.org/schemas",
	"type": "arrayAttestation",
	"issuer": "<Avenue's issuerURI>",
	"member": {
		"type": "ENS",
		"id": "josh.eth"
	},
	"organizations": [
		{
			"expiration": "<ISO-datetime>",
			"attesterURI": "<DAOStar One's membersURI>",
			"name": "DAOstar One",
			"daoURI": "<DAOStar One's daoURI, following EIP-4824>"
		}
	]
}

Let’s now assume DAOStar One is using Govrn to track contributions and Avenue is integrating with Govrn to track data.

Any contributions the user allows to be publicly shared will also be available to Avenue. Even though a client would be querying Avenue’s attestation endpoint, the contributions field would relay any contributions made by Govrn. Querying the previous endpoint would return:

{
	"@context": "http://www.daostar.org/schemas",
	"type": "arrayAttestation",
	"issuer": "<Avenue's issuerURI>",
	"member": {
		"type": "ENS",
		"id": "josh.eth"
	},
	"organizations": [
		{
			"expiration": "<ISO-datetime>",
			"attesterURI": "<DAOStar One's membersURI>",
			"name": "DAOstar One",
			"daoURI": "<DAOStar One's daoURI, following EIP-4824>"
		}
	],
	"contributions": [
		{
			"type": "contribution",
			"commit_type": "tweet",
			"reference?": "<URI reference to the tweet on Govrn's platform>",
			"attesterURI": "<Govrn's issuerURI>"
		},
}

Notice the contributions field includes information issued by Govrn and relayed by Avenue. Making use of this information relay allows tools to easily integrate with a single one of the issuers but still have access to data of others without being aware of any implementation details. At the same time, there’s still confidence in the data being relayed since it can be validated by the reference field.

Let’s assume now that Avenue also integrates with Disco. Disco, in turn, attests user identities. If the user links both profiles (josh.eth and joshua.eth) in Disco, even though the former only has token access to DAOStar One, Disco can issue an attestation that it should be able to access groundw3rk as well. In essence, Disco is stating “josh.eth has tokens to access DAOStar One but, even though you can’t see it, I guarantee you its owner also has an address with the NFT to access groundw3rk”.

This is represented by returning the following data in Discos’ issuer endpoint:  

{
	"@context": "http://www.daostar.org/schemas",
	"type": "arrayAttestation",
	"issuer": "<Disco's issuerURI>",
	"member": {
		"type": "ENS",
		"id": "josh.eth"
	},
	"organizations": [
		{
			"expiration": "<ISO-datetime>",
			"attesterURI": "<DAOStar One's membersURI>",
			"name": "DAOstar One",
			"daoURI": "<DAOStar One's daoURI, following EIP-4824>"
		},
		{
			"expiration": "<ISO-datetime>",
			"attesterURI": "<Disco's URI>",
			"name": "groundw3rk",
			"daoURI": "<groundw3rk's daoURI, following EIP-4824>"
		}
	]
}

Notice how the attesterURI in this scenario points to Disco’s own URI. A third-party using this information to token gate access to a DAO should decide if they trust Disco’s attestation.

For DAOs: attestationIssuers and issuerURI

The basic use-case for a DAO using attestationIssuers and issuerURI is so that the DAO can (1) declare what services they use, along with the data published by those service providers, and (2) to declare to other services where “authorized” third party data is being maintained about members of the data.

Expiration

Since attestations can be easily (and freely) issued by the DAO issuer contract or a trusted party, we propose adding an expiry timestamp to the attestation schema. Having a (short-lived) self-expiring attestation avoids the rigmarole of maintaining a revocation registry and the underlying issues of trust and access to it.

With self-revoking credentials, the problem of storing is partially solved: they can at any time be reissued by the DAO contract or the trusted party. The approach also adds flexibility for storage by the user themselves (e.g. via a browser extension, that could potentially automatically refresh expired credentials).

Copyright

Copyright and related rights waived via CC0.

Leave for future work

We can’t fit everything we’d like in a single standard. Here’s what we cut:

richer metadata (emphasis on enabling contributor-centric data instead of just member data)

extensions to membersURI

verifiability of attestations & credentials (meaning we are NOT doing verifiable credentials right now!)

revocability & editability of an attestation

questions about privacy—right now, all attestations are public

questions about consent—how do we make sure people don’t get spammed?

Reference Implementation

📓

Specification

CUT

Definitions

PII

Attestation Architecture

Extensions to membersURI

💡

We should discuss how granular the expiration timestamp should be.

🖊️

Additional text for attestationIssuers

The most common scenario for membership is owning a digital asset, for which we propose that the DAO deploys an issuance contract that checks against the main contract for the ownership of the said asset. Besides covering most scenarios, this also composes well with contract upgrades. Third-party tools should check for that user-provided attestation (assuming it’s structurally valid and hasn’t expired) instead of performing on-chain verification. 

If the membership requirements are more complex - taking the example of owning a token or an NFT or a guest pass or belong to a sub-DAO - the attestation can be valid for either one of those. In this example, the attestation itself can act as the entry point for authorization in third-parties: if a user only has a valid attestation for a sub-group, they should only see assets or features related to that.

For Issuers: Attestation Endpoints

💡

Background and edge-cases

Polygon DAO: anyone who owns a secret (a zk-proof that you issue?) is a member of the DAO? works with their system fo zk verification their polygon ID system?

Polygon DAO also had a very interesting use-case for requirements to join the DAO; “having received USDC for completing a project”. Had tool that checks this.

Talking with Evin: had a few interesting opinions about the work we’re doing, because they’re super interested in a standard like this.

💡

Are there additional expectations we have for issuers BESIDES hosting an attestation endpoint, since they might be handling PII? Answer: no, we don’t cover PII use-cases here.

Cut from long example

There is also the possibility of third parties accepting attestations from issuers not described in the issuerURI field. Take the example of a user not wanting to reveal the identity in which they own a token, but wanting to get access to the DAO with a secondary identity. In this scenario, the DAO could still have a smart contract as the trusted issuer. However, the user could still ask a third party for a VC that covers this scenario. 

In a hypothetical example featuring three attestation issuers, Disco, Govrn, and Avenue:

Disco has knowledge of multiple identities owned by the same person.

Identity idA owns the token, the user wants to make use of idB to access a token-gated feature in Avenue.

Disco can attest that the owner of idB has the token.

The user provides this attestation to Avenue.

At this point, Avenue could check that the DAO schema points to a smart contract but the attestation was issued by Disco. In our proposal, we leave it up to the third parties to choose what happens next. Either Avenue doesn’t trust Disco and therefore doesn’t consider this to be a valid attestation or Avenue does. This can be further discussed as there are other mechanisms for issuer trust. Regardless, the DAO membership requirements are fulfilled without the DAO having to account for more complex scenarios.

{
	"@context": "http://www.daostar.org/schemas",
	"type": "attestation",
	"member": {
		"type": "EthereumAddress",
		"address": "<address>",
	},
	"expiration": "ISO-datetime",
	"issuer": "<issuerURI>",
	"organizations": [
		{
			"type": "DAO",
			"daoURI": "<URI that follows EIP-4824 DAO JSON-LD Schema>",
			"attesterURI": "<DAO1's own membersURI>"
		},
		{
			"type": "DAO",
			"daoURI": "<URI that follows EIP-4824 DAO JSON-LD Schema>", [we should include this even if the attester is NOT the dao] 
			"attesterURI": "<Disco's issuerURI>" [this is Disco claiming that this address should belong to the DAO]
		},
		{ [this is Govrn's attestation that josh.eth is in DAO3]
			"type": "DAO",
			"daoURI": "<URI that follows EIP-4824 DAO JSON-LD Schema>", 
			"attesterURI": "<Govrn's issuerURI>" [this is Govrn claiming that this address should belong to the DAO]
		}
	],
	"contributions": [
		{
			"type": "contribution",
			"commit_type": "code commit",
			"reference?": "<organization or project or reference>", [this would be on GitHub]
			"attesterURI": "<Govrn's issuerURI>" [this would be attested by Govrn]
		},
		{
			"type": "tweet"
			"attesterURI": "<Twitter's issuerURI>"
		}
	],
	"scores": [
		{
			"type": "reputation",
			"attesterURI": "<this should be = daoURI or at least membersURI>"
		}
	]
}