Traditional methods of user engagement such as quests, points, and scores are becoming outdated. We're increasingly seeing a need for a universal standard that outlives trends, due to the fractured nature of user achievements and platform-specific metrics. This standard should span across various platforms and chains, catering to the evolving demands of Web3.

ICP - is the best place/blockchain (not a protocol on other blockchain) to bring real Identity with interoperable web2\web3 achievements to the world. It by default is universal decentralized infrastructure layer.

Consider Jeremy, an active user of the ICP. He frequently participates in various activities across different applications and utilizes DeFi protocols. Jeremy is particularly fond of the SwappDapp protocol, where he completes various quests, performs numerous swaps, and consistently earns generous rewards. Additionally, Jeremy enjoys participating in social activities on the SocialDapp platform, where he maintains a popular profile with a large number of followers.

However, Jeremy faces a problem. His actions and achievements within these applications only benefit him within the confines of those individual applications. For instance, SocialDapp is unaware of Jeremy's DeFi achievements on SwappDapp, and vice versa. For Jeremy, each new platform presents different metrics, scores, and a non-transferable reputation. His activity scores are heavily localized.

Jeremy experiences a disjointedness in achievements and reputation across different applications. Each new application he connects to with Internet Identity within ICP creates a new "empty" wallet.

SwappDapp would also be willing to reward and share profits with active and authentic users like Jeremy. They would like to verify Jeremy's humanity based on his social account in SocialDapp and, with his consent, use his reputation from other applications. Hence, there's a need to bridge this gap and create a unified reputation standard.

Creating a unified reputation standard allows for the evaluation of user activity using a single logic. This standard facilitates the creation of transferable reputations from any application within the Internet Identity and beyond.

In this scenario, Jeremy could receive more rewards from new projects. SwappDapp and SocialDapp could attract new genuine users, collaborate, create higher-quality loyalty programs, and distribute allocations more efficiently.

To make this possible, we need to tackle a unique feature of ICP, which is the transfer of user activity data between applications and principals. This feature is linked to security and anonymity: whenever a user logs into a new application, a new "empty" key pair is always created. Consequently, the application cannot evaluate the prior experience or verify the humanity of a principal based on their activity.

The primary goal of this concept is to develop a protocol solution that doesn't require modifications to the existing implementation of Internet Identity or the ICP infrastructure in order to create public identity verifications or "achievements".

The PublicAchievements format, acting as public credentials, stores user achievements in the form of NFTs. However, it maintains user anonymity by not disclosing the principals who have performed the corresponding actions in DApp.

Terminology / Core Concepts

• Achievements (Public credentials issued by an issuer in the form of NFTs). Each achievement is a canister that verifies a user's actions within a project or protocol.

• Hub, an application that allows users to manage and control their achievements.

• Identity Wallet, a wallet where a user's achievements are stored and which is connected to the Hub. In the schema explained below, the Identity Wallet represents the Identity Holder in the Trust Triangle.

• Issuer, a protocol or project responsible for issuing an achievement.

• Issuer Marketplace, a centralized list of existing issuers.

• Internal Principal, inside dApp and identity wallet - something that needs to be differentiated.

• ReputationModule, a canister deployed by a project, enabling the project to interact with the user as both an Issuer and a Verifier.

Important Note! Within the scope of this specification, Internet Identity and Identity Wallet are two distinct entities.

This model proposes that projects and protocols issue public achievement in the form of NFTs (ICRC-7 or DIP-721) to users as rewards. This will enable users to "level up" their Identity and build their reputation within ICP. In this concept, protocols and projects issuing achievements to users act as Issuers. The achievements/rewards issued to users encourage their participation in projects and protocols. For projects, this provides the opportunity to differentiate reliable users with a verified reputation from sybils, thereby improving the user experience.

This implementation aims to foster healthier relationships between Dapps and users. On the one hand, it reduces the likelihood of abuse by sybils. On the other hand, it creates better conditions for attracting new users.

For a better understanding, let's revisit the example involving Jeremy and examine his interaction within this implementation.

In this scheme, Jeremy acts as the Identity Holder, while SocialDapp and SwapDapp function as ReputationModules. Let's assume that Jeremy wants to earn an achievement from SocialDapp that validates he has more than 1000 followers. This achievement would be recognized by SwapDapp as an affirmation of Jeremy's authenticity and reliability.

1. SocialDapp ReputationModule Indexing. SocialDapp confirms its authority, gets indexed in the IssuerMarketPlace, receives a 'verified' status, and publishes a list of achievements that it can issue as an Issuer.

2. Checking Achievement Eligibility. The SocialDapp ReputationModule refers to the "More than 1000 followers" achievement canister for validation.

3. Return Eligibility. The achievement canister confirms that Jeremy is eligible for this achievement.

4. Issuing Achievement. Upon confirmation, the SocialDapp ReputationModule refers to the NFT canister, Achievement Collection, to mint the achievement and send it to Jeremy's Identity Wallet.

5. Mint Achievement. The achievement is minted onto Jeremy's Identity Wallet.

6. Achievement Management. Jeremy can view his achievement collection on the Hub.

7. Displaying issuer marketplace and achievements. Jeremy can also verify that the achievement was issued by an authoritative issuer.

8. Verify Achievements. With the received achievement confirming that he has more than 1000 followers, Jeremy goes to SwapDapp, which verifies Jeremy's achievement.

As a result, Jeremy has successfully enhanced his overall Web3 reputation and validated his authenticity to SwapDapp by earning one of many possible achievements 🎉

Continuing with this example, SwapDapp could also issue valuable achievements that users can claim. SocialDapp and other applications could utilize these achievements, leading to each application participating in the construction of a reputation layer.

Another crucial goal of this standard is the global development of (SSI and the IC ecosystem. It introduces users and projects to each other, opening up new opportunities for project collaborations within the IC by mutual achievement recognition and support of the standard. Furthermore, projects can enhance their visibility by listing in the verified Issuers list.

This opens the door for gaming mechanics, achievement collections, incentivization of reputation, and Identity enhancement. Here are just a few examples of possible achievements:

• Web2

  • Owning an account and being active on social networks.

  • Achievements in loyalty programs (such as miles, number of visits, number of purchases, etc.).

  • Status or achievements on educational, professional, or gaming platforms.

  • Confirmation of KYC process completion.

• Web3

  • Activity or swaps in protocols.

  • GameFi achievements and activity.

  • DAO activity.

  • Balance and transaction history on DeFi protocols or chains.

  • Achievements for holding tokens, creating liquidity pairs, staking.

  • Confirmations of NFT ownership.

The specifications of the achievements protocol described below draw significant inspiration from the Attribute Sharing documentation and the ICRC-35 standard. These resources propose solutions for the exchange of information between two dApps within the ICP.

For a user like Jeremy, the technical architecture outlined here would mean just a few clicks and seconds of waiting time, ensuring a pleasant user experience. Moreover, Jeremy can be confident in the security of this process and the complete anonymity of the disclosed data. This assurance comes from his friend Tony, who is technically adept and has affirmed the reliability of the standard's technical implementation. If you are Tony, we invite you to not just take your friend's word, but to personally verify the reliability of the solution described. DYOR

Every project or protocol can become an issuer-provider by deploying a ReputationModule canister. This canister implements both verifier and issuer functions, enabling it to issue and verify user achievements. The project or protocol can also specify the public address of its canister in the IssuerMarketPlace, a canister that indexes issuers, thereby confirming its authority. The address of the canister is linked to the project's domain. The ReputationModule canister also marks the achievements that the project can issue. You can familiarize yourself with the available achievements of an issuer in the index canister for issuers, the IssuerMarketPlace.

When interacting with the canister, the retrieval of information is restricted through the caller-only wallet. The ReputationModule indexes an Achievement in the list of achievements it supports (Access control; these canisters can forcibly perform actions in the ReputationModule).

Within the protocol/project, the deployer must grant extra rights to the ReputationModule canister so that it can retrieve user information. However, only the user can consent to this, which means it does not infringe on their rights.

The Issuer Marketplace is a centralized list of existing issuers that have been authenticated. Multiple such marketplaces can exist, and projects or users can freely choose which one to trust, much like a Token List. In the Issuer Marketplace, issuers register their information, including the address of their issuer canister, and may also attach metadata such as images or logos. The marketplace confirms the authenticity of the issuer through a verified: boolean field.

The verified status in the marketplace can be granted or revoked by trusted entities if the issuer is found to be fraudulent or if a newer ReputationModule has been deployed and the current one is deemed invalid.

For an example of an Issuer Marketplace implementation, consider the Polygon ID Marketplace.

The verification of achievement validity uses our list of issuers by pulling their addresses and avatars.

Each achievement is a canister that validates a user's information within a protocol and forms an achievement, marking specific actions completed by the user. This achievement warrants the issuing of an achievement exemplar to the user's Identity Wallet. For added trust in the Achievement, it is recommended to disable its active controllers for immutability.

Within the achievement, an internal record is kept of the principals (internal principal of the protocol) who have been granted the achievement. This prevents them from endlessly cloning it in the NFT format. A public achievement can only be issued once to a single principal and sent to an identity wallet.

Templates for checking such actions, full documentation, and constructors for simplification are available. The Achievement is bidirectionally linked to its ReputationModule.

The public nature of a achievement does not mean it breaches user anonymity. When issuing a achievement, the protocol that executes the achievement issuance does not disclose the address that performed actions in the protocol, preventing a connection between Internet Identity principals and the identity wallet where achievements are issued.

The sharing of achievements is made possible through canister signature, using the application address for confirmation. An instance of an achievement in the form of an NFT can only be issued once to a single IdentityWallet.

The Hub, our protocol, or other deployed Hubs that adhere to the specifications, interact with ReputationModule-s to confirm the ownership of achievements, or to validate the entitlement to receive an Achievement confirmed by the Issuer.

The identity wallet interacts with the canister to send NFTs, without publicly disclosing this address, and hides the connection between them.

The Hub serves as an application that allows users to:

• Manage their achievements

• Act as a public profile link (It can be connected with a name service, a potential partnership)

• View and display the issuer marketplace

• Browse a database of achievements from various verified Issuers

Identity holder === user

A user's wallet, which stores achievements, essentially functions as an identity wallet, serving as a repository for their reputation.

It's recommended to use wallets such as Plug Wallet, which can be connected to the ReputationModule to authenticate achievements. Additional abstraction is also possible through ICRC-35, which allows the transfer of achievement confirmations through a decentralized signature via the postMessage API. This ensures additional security and facilitates the transfer of information from the frontend to the frontend.

There is also the possibility of deploying a canister that implements the IdentityHolder functionality through the introduction of methods.

The Achievement Collection is an NFT collection that contains all issued Achievement instances. It adheres to either the ICRC-7 or DIP-721 formats.

Metadata about the Issuer is initially specified in the ReputationModule, and the Achievement Collection retrieves this information. They are mutually interconnected.

Each issued NFT is additionally marked as an Achievement for easier usage and display.

An Achievement can only be issued once per wallet. However, it can be utilized as multi-identity with the Identity Holder canister implementation.

Here, we describe the MVP standard implementation. Although it adheres to the general concept, it has some simplifications for faster implementation and concept validation.

Stable Memory

• achievementsList: a list of canister addresses for all achievements supported by the ReputationModule.

• achievementToInformation: a map linking achievements to metadata.

• totalIssued: a variable.

Methods

• isIssuer: returns true by default, this is a system function for verification.

• verifyAchievements: returns a list of achievements that the caller possesses.

• issueAchievement: accepts the address of an achievement and Identity wallet for it, verifies the rights to issue using validateSignature. After that, it mints the achievement using Achievement Collection.

• checkAchievementValidity: accepts the address of an achievement as a parameter, calls a similar method in the achievement canister, and passes the calling address as a parameter for verification.

Admin Methods

• addAchievement: adds to the achievementList.

• removeAchievement: removes from the achievementList.

methods

• checkAchievementValidity is a query function that can also be updated if the achievement includes HTTP requests to other blockchains or Web2 resources. It takes a principal as a parameter to be checked.

  This function can also accept an additional parameter alongside the principal, to verify additional interactions. For example, a linked Twitter account (the parameter must be linked to the principal. For instance, the linking of a social account with a principal can be done with networks like Orally Network with the Cassandra Product).

  This function returns true if the user is eligible for the achievement.

• prepareToIssue takes an address as an input, where a achievement will be issued. It generates a hash based on the Canister Signature. When the IdentityHolder calls issueAchievement, the hash based on the Canister Signature will match. This adds an extra layer of security, where the actual hash can only be obtained by calling a function in the canister to get the identical hash (this excludes external enumeration).

• checkIssuedStatus checks whether a achievement is issued based on the achievement's identifier and the internal principal's address.

• validateSignature performs the same function as prepareToIssue, but in a query format. It returns a Canister signature.

• validateIssue checks all the sending addresses to ensure they match when the Reputation Module issues an achievement. If everything is correct, it changes the achievement status to 'Issued' in the principalsToAchievements map.

Stable memory

• principalsToAchievement - This allows for retrieving information about the status of an achievement based on an internal principal. It contains a structure that includes the following:

{
    status: Status;
    validityHash: Blob;
}

There are three statuses: NotEligible, IssuePrepared, and Issued.

Constants

• REPUTATION_MODULE_ADDRESS - This is the address of the Reputation Module.

• ACHIEVEMENT_COLLECTION_ADDRESS - This is the address of the achievements NFT collection.

Methods

• [...list of NFT methods]

• getIssuerMetadata

Constants

• REPUTATION_MODULE_ADDRESS - Address of Reputation Module

StableMemory

principalToIssuer - This maps the Reputation Module address to the issuer status, indicating whether it's verified or not.

IssuerListMap - This is an array containing the addresses of all issuers.

VerifiedIssuerListMap - This is an array containing the addresses of all verified issuers.

methods

• AddIssuer - This can be called by any wallet. It adds an address to the IssuerListMap if the address doesn't already exist and if the isIssuer function inside the canister returns true.

• [...role management methods]

• VerifyIssuer - This method adds an issuer to the VerifiedIssuerListMap and changes the status to verified in the principalToIssuer map.

This is a Frontend Dapp, with an interface that allows for:

• Visualizing the Issuer Marketplace

• Viewing all interactions with all achievements

• Providing an external link to your profile

• Viewing available achievements

In this implementation, it acts merely as a wallet storing achievements.

For future implementations, it will be convenient to create a unique identity wallet with specific identity features, including the storage of reputation on the IC.

• Stores user achievements

• It's recommended to use Plug or other wallets. You can also send your achievements to your primary wallet.

• Could be realized with an Identity Holder Canister (Your multi-wallet identity, easy to use)

Let's consider, based on our methods, the process of issuing an achievement to an Identity Holder.

1. The Identity Holder obtains the address of the desired achievement canister.

2. The Identity Holder calls the checkAchievementValidity method on the ReputationModule, providing the address of the achievement they wish to verify.

3. The ReputationModule in turn calls the same method in the AchievementCanister, passing the internal address of the caller. The method returns a response in the form of a boolean value.

4. The Identity Holder calls the prepareToIssue method on the AchievementCanister, specifying their identity wallet as a parameter. This is the wallet to which the achievement will be issued. If all checks out, the prepareToIssue method changes the status of the achievement issuance to IssuePrepared and adds a validityHash to the principalsToAchievement map.
   
   The validityHash is created based on the canister signature, as shown in the following Motoko example:

   let { signature } = await ic.sign_with_ecdsa({
     message_hash; // This is the hash of the message that needs to be signed
     derivation_path = [ caller ];
     key_id = { curve = #secp256k1; name = "dfx_test_key" };
   });
   

   Here, the internal principal is referred to as the caller, and the message_hash is a hash based on converting the Identity Wallet principal into a string.

5. The Identity Holder calls the

While we don't want to speculate too much about the future in this final section, it's worth taking a broader look at the Identity space as a crucial building block of Web3 and the digital economy. One of the primary current issues is the fragmented nature of Identity across multiple blockchains and wallets.

The emergence of an achievements standard, implemented within the ICP, could play a significant role in solving the problem of fragmented digital reputation.

To conclude this article, we'll highlight a couple examples that could greatly enhance and scale this concept towards cross-chain compatibility:

• A partnership with POAP.xyz would allow any POAPs from EVM wallets to be transferred to Internet Identity, Solana, or any other chains using this standard.

• A partnership with Gitcoin could enable the transfer of any badges from the Gitcoin Passport to Internet Identity.

Let's finish where we started: ICP is the ideal blockchain (not merely a protocol on another blockchain) to bring real Identity with interoperable web2\web3 achievements to the world. By default, it serves as a universal decentralized infrastructure layer.

https://www.polygonid.com/

https://orally.network/

https://plugwallet.ooo/

https://github.com/dfinity/wg-identity-authentication/blob/main/topics/icrc_35_webpage_apis.md

https://github.com/dfinity/wg-identity-authentication/blob/main/topics/attribute-sharing.md

Traditional methods of user engagement such as quests, points, and scores are becoming outdated. We're increasingly seeing a need for a universal standard that outlives trends, due to the fractured nature of user achievements and platform-specific metrics. This standard should span across various platforms and chains, catering to the evolving demands of Web3.

ICP - is the best place/blockchain (not a protocol on other blockchain) to bring real Identity with interoperable web2\web3 achievements to the world. It by default is universal decentralized infrastructure layer.

Consider Jeremy, an active user of the ICP. He frequently participates in various activities across different applications and utilizes DeFi protocols. Jeremy is particularly fond of the SwappDapp protocol, where he completes various quests, performs numerous swaps, and consistently earns generous rewards. Additionally, Jeremy enjoys participating in social activities on the SocialDapp platform, where he maintains a popular profile with a large number of followers.

However, Jeremy faces a problem. His actions and achievements within these applications only benefit him within the confines of those individual applications. For instance, SocialDapp is unaware of Jeremy's DeFi achievements on SwappDapp, and vice versa. For Jeremy, each new platform presents different metrics, scores, and a non-transferable reputation. His activity scores are heavily localized.

Jeremy experiences a disjointedness in achievements and reputation across different applications. Each new application he connects to with Internet Identity within ICP creates a new "empty" wallet.

SwappDapp would also be willing to reward and share profits with active and authentic users like Jeremy. They would like to verify Jeremy's humanity based on his social account in SocialDapp and, with his consent, use his reputation from other applications. Hence, there's a need to bridge this gap and create a unified reputation standard.

Creating a unified reputation standard allows for the evaluation of user activity using a single logic. This standard facilitates the creation of transferable reputations from any application within the Internet Identity and beyond.

In this scenario, Jeremy could receive more rewards from new projects. SwappDapp and SocialDapp could attract new genuine users, collaborate, create higher-quality loyalty programs, and distribute allocations more efficiently.

To make this possible, we need to tackle a unique feature of ICP, which is the transfer of user activity data between applications and principals. This feature is linked to security and anonymity: whenever a user logs into a new application, a new "empty" key pair is always created. Consequently, the application cannot evaluate the prior experience or verify the humanity of a principal based on their activity.

The primary goal of this concept is to develop a protocol solution that doesn't require modifications to the existing implementation of Internet Identity or the ICP infrastructure in order to create public identity verifications or "achievements".

The PublicAchievements format, acting as public credentials, stores user achievements in the form of NFTs. However, it maintains user anonymity by not disclosing the principals who have performed the corresponding actions in DApp.

Terminology / Core Concepts

• Achievements (Public credentials issued by an issuer in the form of NFTs). Each achievement is a canister that verifies a user's actions within a project or protocol.

• Hub, an application that allows users to manage and control their achievements.

• Identity Wallet, a wallet where a user's achievements are stored and which is connected to the Hub. In the schema explained below, the Identity Wallet represents the Identity Holder in the Trust Triangle.

• Issuer, a protocol or project responsible for issuing an achievement.

• Issuer Marketplace, a centralized list of existing issuers.

• Internal Principal, inside dApp and identity wallet - something that needs to be differentiated.

• ReputationModule, a canister deployed by a project, enabling the project to interact with the user as both an Issuer and a Verifier.

Important Note! Within the scope of this specification, Internet Identity and Identity Wallet are two distinct entities.

This model proposes that projects and protocols issue public achievement in the form of NFTs (ICRC-7 or DIP-721) to users as rewards. This will enable users to "level up" their Identity and build their reputation within ICP. In this concept, protocols and projects issuing achievements to users act as Issuers. The achievements/rewards issued to users encourage their participation in projects and protocols. For projects, this provides the opportunity to differentiate reliable users with a verified reputation from sybils, thereby improving the user experience.

This implementation aims to foster healthier relationships between Dapps and users. On the one hand, it reduces the likelihood of abuse by sybils. On the other hand, it creates better conditions for attracting new users.

For a better understanding, let's revisit the example involving Jeremy and examine his interaction within this implementation.

In this scheme, Jeremy acts as the Identity Holder, while SocialDapp and SwapDapp function as ReputationModules. Let's assume that Jeremy wants to earn an achievement from SocialDapp that validates he has more than 1000 followers. This achievement would be recognized by SwapDapp as an affirmation of Jeremy's authenticity and reliability.

1. SocialDapp ReputationModule Indexing. SocialDapp confirms its authority, gets indexed in the IssuerMarketPlace, receives a 'verified' status, and publishes a list of achievements that it can issue as an Issuer.

2. Checking Achievement Eligibility. The SocialDapp ReputationModule refers to the "More than 1000 followers" achievement canister for validation.

3. Return Eligibility. The achievement canister confirms that Jeremy is eligible for this achievement.

4. Issuing Achievement. Upon confirmation, the SocialDapp ReputationModule refers to the NFT canister, Achievement Collection, to mint the achievement and send it to Jeremy's Identity Wallet.

5. Mint Achievement. The achievement is minted onto Jeremy's Identity Wallet.

6. Achievement Management. Jeremy can view his achievement collection on the Hub.

7. Displaying issuer marketplace and achievements. Jeremy can also verify that the achievement was issued by an authoritative issuer.

8. Verify Achievements. With the received achievement confirming that he has more than 1000 followers, Jeremy goes to SwapDapp, which verifies Jeremy's achievement.

As a result, Jeremy has successfully enhanced his overall Web3 reputation and validated his authenticity to SwapDapp by earning one of many possible achievements 🎉

Continuing with this example, SwapDapp could also issue valuable achievements that users can claim. SocialDapp and other applications could utilize these achievements, leading to each application participating in the construction of a reputation layer.

Another crucial goal of this standard is the global development of (SSI and the IC ecosystem. It introduces users and projects to each other, opening up new opportunities for project collaborations within the IC by mutual achievement recognition and support of the standard. Furthermore, projects can enhance their visibility by listing in the verified Issuers list.

This opens the door for gaming mechanics, achievement collections, incentivization of reputation, and Identity enhancement. Here are just a few examples of possible achievements:

• Web2

  • Owning an account and being active on social networks.

  • Achievements in loyalty programs (such as miles, number of visits, number of purchases, etc.).

  • Status or achievements on educational, professional, or gaming platforms.

  • Confirmation of KYC process completion.

• Web3

  • Activity or swaps in protocols.

  • GameFi achievements and activity.

  • DAO activity.

  • Balance and transaction history on DeFi protocols or chains.

  • Achievements for holding tokens, creating liquidity pairs, staking.

  • Confirmations of NFT ownership.

The specifications of the achievements protocol described below draw significant inspiration from the Attribute Sharing documentation and the ICRC-35 standard. These resources propose solutions for the exchange of information between two dApps within the ICP.

For a user like Jeremy, the technical architecture outlined here would mean just a few clicks and seconds of waiting time, ensuring a pleasant user experience. Moreover, Jeremy can be confident in the security of this process and the complete anonymity of the disclosed data. This assurance comes from his friend Tony, who is technically adept and has affirmed the reliability of the standard's technical implementation. If you are Tony, we invite you to not just take your friend's word, but to personally verify the reliability of the solution described. DYOR

Every project or protocol can become an issuer-provider by deploying a ReputationModule canister. This canister implements both verifier and issuer functions, enabling it to issue and verify user achievements. The project or protocol can also specify the public address of its canister in the IssuerMarketPlace, a canister that indexes issuers, thereby confirming its authority. The address of the canister is linked to the project's domain. The ReputationModule canister also marks the achievements that the project can issue. You can familiarize yourself with the available achievements of an issuer in the index canister for issuers, the IssuerMarketPlace.

When interacting with the canister, the retrieval of information is restricted through the caller-only wallet. The ReputationModule indexes an Achievement in the list of achievements it supports (Access control; these canisters can forcibly perform actions in the ReputationModule).

Within the protocol/project, the deployer must grant extra rights to the ReputationModule canister so that it can retrieve user information. However, only the user can consent to this, which means it does not infringe on their rights.

The Issuer Marketplace is a centralized list of existing issuers that have been authenticated. Multiple such marketplaces can exist, and projects or users can freely choose which one to trust, much like a Token List. In the Issuer Marketplace, issuers register their information, including the address of their issuer canister, and may also attach metadata such as images or logos. The marketplace confirms the authenticity of the issuer through a verified: boolean field.

The verified status in the marketplace can be granted or revoked by trusted entities if the issuer is found to be fraudulent or if a newer ReputationModule has been deployed and the current one is deemed invalid.

For an example of an Issuer Marketplace implementation, consider the Polygon ID Marketplace.

The verification of achievement validity uses our list of issuers by pulling their addresses and avatars.

Each achievement is a canister that validates a user's information within a protocol and forms an achievement, marking specific actions completed by the user. This achievement warrants the issuing of an achievement exemplar to the user's Identity Wallet. For added trust in the Achievement, it is recommended to disable its active controllers for immutability.

Within the achievement, an internal record is kept of the principals (internal principal of the protocol) who have been granted the achievement. This prevents them from endlessly cloning it in the NFT format. A public achievement can only be issued once to a single principal and sent to an identity wallet.

Templates for checking such actions, full documentation, and constructors for simplification are available. The Achievement is bidirectionally linked to its ReputationModule.

The public nature of a achievement does not mean it breaches user anonymity. When issuing a achievement, the protocol that executes the achievement issuance does not disclose the address that performed actions in the protocol, preventing a connection between Internet Identity principals and the identity wallet where achievements are issued.

The sharing of achievements is made possible through canister signature, using the application address for confirmation. An instance of an achievement in the form of an NFT can only be issued once to a single IdentityWallet.

The Hub, our protocol, or other deployed Hubs that adhere to the specifications, interact with ReputationModule-s to confirm the ownership of achievements, or to validate the entitlement to receive an Achievement confirmed by the Issuer.

The identity wallet interacts with the canister to send NFTs, without publicly disclosing this address, and hides the connection between them.

The Hub serves as an application that allows users to:

• Manage their achievements

• Act as a public profile link (It can be connected with a name service, a potential partnership)

• View and display the issuer marketplace

• Browse a database of achievements from various verified Issuers

Identity holder === user

A user's wallet, which stores achievements, essentially functions as an identity wallet, serving as a repository for their reputation.

It's recommended to use wallets such as Plug Wallet, which can be connected to the ReputationModule to authenticate achievements. Additional abstraction is also possible through ICRC-35, which allows the transfer of achievement confirmations through a decentralized signature via the postMessage API. This ensures additional security and facilitates the transfer of information from the frontend to the frontend.

There is also the possibility of deploying a canister that implements the IdentityHolder functionality through the introduction of methods.

The Achievement Collection is an NFT collection that contains all issued Achievement instances. It adheres to either the ICRC-7 or DIP-721 formats.

Metadata about the Issuer is initially specified in the ReputationModule, and the Achievement Collection retrieves this information. They are mutually interconnected.

Each issued NFT is additionally marked as an Achievement for easier usage and display.

An Achievement can only be issued once per wallet. However, it can be utilized as multi-identity with the Identity Holder canister implementation.

Here, we describe the MVP standard implementation. Although it adheres to the general concept, it has some simplifications for faster implementation and concept validation.

Stable Memory

• achievementsList: a list of canister addresses for all achievements supported by the ReputationModule.

• achievementToInformation: a map linking achievements to metadata.

• totalIssued: a variable.

Methods

• isIssuer: returns true by default, this is a system function for verification.

• verifyAchievements: returns a list of achievements that the caller possesses.

• issueAchievement: accepts the address of an achievement and Identity wallet for it, verifies the rights to issue using validateSignature. After that, it mints the achievement using Achievement Collection.

• checkAchievementValidity: accepts the address of an achievement as a parameter, calls a similar method in the achievement canister, and passes the calling address as a parameter for verification.

Admin Methods

• addAchievement: adds to the achievementList.

• removeAchievement: removes from the achievementList.

methods

• checkAchievementValidity is a query function that can also be updated if the achievement includes HTTP requests to other blockchains or Web2 resources. It takes a principal as a parameter to be checked.

  This function can also accept an additional parameter alongside the principal, to verify additional interactions. For example, a linked Twitter account (the parameter must be linked to the principal. For instance, the linking of a social account with a principal can be done with networks like Orally Network with the Cassandra Product).

  This function returns true if the user is eligible for the achievement.

• prepareToIssue takes an address as an input, where a achievement will be issued. It generates a hash based on the Canister Signature. When the IdentityHolder calls issueAchievement, the hash based on the Canister Signature will match. This adds an extra layer of security, where the actual hash can only be obtained by calling a function in the canister to get the identical hash (this excludes external enumeration).

• checkIssuedStatus checks whether a achievement is issued based on the achievement's identifier and the internal principal's address.

• validateSignature performs the same function as prepareToIssue, but in a query format. It returns a Canister signature.

• validateIssue checks all the sending addresses to ensure they match when the Reputation Module issues an achievement. If everything is correct, it changes the achievement status to 'Issued' in the principalsToAchievements map.

Stable memory

• principalsToAchievement - This allows for retrieving information about the status of an achievement based on an internal principal. It contains a structure that includes the following:

{
    status: Status;
    validityHash: Blob;
}

There are three statuses: NotEligible, IssuePrepared, and Issued.

Constants

• REPUTATION_MODULE_ADDRESS - This is the address of the Reputation Module.

• ACHIEVEMENT_COLLECTION_ADDRESS - This is the address of the achievements NFT collection.

Methods

• [...list of NFT methods]

• getIssuerMetadata

Constants

• REPUTATION_MODULE_ADDRESS - Address of Reputation Module

StableMemory

principalToIssuer - This maps the Reputation Module address to the issuer status, indicating whether it's verified or not.

IssuerListMap - This is an array containing the addresses of all issuers.

VerifiedIssuerListMap - This is an array containing the addresses of all verified issuers.

methods

• AddIssuer - This can be called by any wallet. It adds an address to the IssuerListMap if the address doesn't already exist and if the isIssuer function inside the canister returns true.

• [...role management methods]

• VerifyIssuer - This method adds an issuer to the VerifiedIssuerListMap and changes the status to verified in the principalToIssuer map.

This is a Frontend Dapp, with an interface that allows for:

• Visualizing the Issuer Marketplace

• Viewing all interactions with all achievements

• Providing an external link to your profile

• Viewing available achievements

In this implementation, it acts merely as a wallet storing achievements.

For future implementations, it will be convenient to create a unique identity wallet with specific identity features, including the storage of reputation on the IC.

• Stores user achievements

• It's recommended to use Plug or other wallets. You can also send your achievements to your primary wallet.

• Could be realized with an Identity Holder Canister (Your multi-wallet identity, easy to use)

Let's consider, based on our methods, the process of issuing an achievement to an Identity Holder.

1. The Identity Holder obtains the address of the desired achievement canister.

2. The Identity Holder calls the checkAchievementValidity method on the ReputationModule, providing the address of the achievement they wish to verify.

3. The ReputationModule in turn calls the same method in the AchievementCanister, passing the internal address of the caller. The method returns a response in the form of a boolean value.

4. The Identity Holder calls the prepareToIssue method on the AchievementCanister, specifying their identity wallet as a parameter. This is the wallet to which the achievement will be issued. If all checks out, the prepareToIssue method changes the status of the achievement issuance to IssuePrepared and adds a validityHash to the principalsToAchievement map.
   
   The validityHash is created based on the canister signature, as shown in the following Motoko example:

   let { signature } = await ic.sign_with_ecdsa({
     message_hash; // This is the hash of the message that needs to be signed
     derivation_path = [ caller ];
     key_id = { curve = #secp256k1; name = "dfx_test_key" };
   });
   

   Here, the internal principal is referred to as the caller, and the message_hash is a hash based on converting the Identity Wallet principal into a string.

5. The Identity Holder calls the

While we don't want to speculate too much about the future in this final section, it's worth taking a broader look at the Identity space as a crucial building block of Web3 and the digital economy. One of the primary current issues is the fragmented nature of Identity across multiple blockchains and wallets.

The emergence of an achievements standard, implemented within the ICP, could play a significant role in solving the problem of fragmented digital reputation.

To conclude this article, we'll highlight a couple examples that could greatly enhance and scale this concept towards cross-chain compatibility:

• A partnership with POAP.xyz would allow any POAPs from EVM wallets to be transferred to Internet Identity, Solana, or any other chains using this standard.

• A partnership with Gitcoin could enable the transfer of any badges from the Gitcoin Passport to Internet Identity.

Let's finish where we started: ICP is the ideal blockchain (not merely a protocol on another blockchain) to bring real Identity with interoperable web2\web3 achievements to the world. By default, it serves as a universal decentralized infrastructure layer.

https://www.polygonid.com/

https://orally.network/

https://plugwallet.ooo/

https://github.com/dfinity/wg-identity-authentication/blob/main/topics/icrc_35_webpage_apis.md

https://github.com/dfinity/wg-identity-authentication/blob/main/topics/attribute-sharing.md