# Reputation in Web3 The infrastructure for capturing self-sovereign reputation in Web3 ## Identity and Reputation Establishing the identity and reputation of an entity within a network without a central authority is swiftly turning into a very important requirement in the evolution of decentralized networks. Reputation is the opinion that is generally held about someone or something. They are generally formed taking attributes and behavior information into account. Reputation matters because it bears consequences. In the real world, reputation directly influences social capital, authority status, eligibility, access to opportunities, bargaining power in negotiations, and often the overall economic cost of acquiring trust in our everyday interactions. While in the digital world, reputation manifests into profiles, hierarchies, tags, and scores that determine the privileges that are granted to users, or the contextual value that users have generated through interactions and contributions within a system. ## Reputation in Web2 Applications The World Wide Web has evolved to the point where most significant exchanges and communication rely on it in some way at least partially, if not completely. A few tech giants collect tremendous amounts of data as more and more people connect and interact via their platforms. The formation of reputation in the digital world is largely based on this data, and users have little to no control over it. Web2 applications when generating reputation models often overlook sensitive aspects of data handling, such as privacy and user consent, thus neglecting the concept of data ownership. These models are used to control their interactions with the system and a variety of network effects take place in such status-seeking interactions. Access to data between systems is also monetized, and in some cases complete models are exchanged as commodities, all while excluding the users from the process. ## How is Web3 different? Web3 is ushering in a major breakthrough in terms of diversification and deepening of user interactions within various decentralized platforms. It is now reaching beyond asset exchange and starting to look at transactions as a form of data that can be processed and used to generate value for the users. A good example would be the communities and DAOs that are being created to fulfill the needs of groups to establish their specialized rules of participation, decision-making, and collaborative interaction. But to manifest the true power of communities to create compelling, engaging, sustainable, and intelligent rules of interaction, the data deficit first needs to be overcome. The answer lies in system interoperability, and breaking the barriers of data exchange, while preserving the user's sovereignty over it. ## A Solution In Web3, applications and platforms should fundamentally be able to conveniently share data, and even reputation models to create a better overall user experience between platforms. Also, users need to be in control of what data is accessible and can be utilized by the said platforms. Applications can also benefit from such a protocol that allows them to fetch user data from other systems, and at the same time use it to generate results that can be used across systems and blockchains. This adds value to both the models, and the data. # What Orange Does Addressing questions of reputation and identity On-chain data is currently scattered across a myriad of decentralized applications. Many types of actions take place in the form of transactions associated with wallet addresses. However, if we were to take that transaction data, extract and consolidate useful data points together turning them into well-defined schemas, this data can prove to be very useful in assessing an entity's on-chain identity for specific contexts. Orange is to achieve just that. **Orange** is a **reputation and trust minting protocol** that aggregates data and **Web3 reputation models** to generate comprehensive reputation proofs in the form of [**Verifiable Credentials**](/glossary#credential) and **NFTs.** It can be used to objectively calculate and assess the "reputation" for a [**Decentralized Identifier**](/glossary#did) **(DID),** and associated wallet addresses. It takes multiple data points into account to assess user behaviour and preferences, such as: #### On-chain data * On-chain transaction data indicating user behaviors * Asset (fungible tokens, NFTs, social tokens, etc.) balance and ownership history * Smart contract interaction * Historical holdings and transactions #### Off-chain data * In-app data from games or other apps, e.g., quest collectibles, in-app purchases, etc. * Reviews, ratings from different platforms * User profile information from social networks and other platforms * IoT data, e.g., locations, health stats, etc. * Financial data from institutions such as banks, insurance firms, etc. * KYC verification using government-issued ID cards such as driving license, or proof of qualification from a university, etc. User data can be processed and manifested as **"minted reputation"** to be stored, exchanged, and used in different forms, such as [**Verifiable Credentials (VCs)**](/glossary#credential)**,** or NFTs**.** ## Two audiences Orange can serve #### Middle-ware for dApp builders to: 1. Use existing model providers, or configure their own model with any data of their choice, including their own dApp data, with one-stop consent management from users 2. Generate their programmable reputation in the format of scores, NFTs, VCs, or reports 3. Seamlessly integrate such programmable reputation into DAO systems to trigger customized actions or privileges 4. Share their models and dApp data with other platforms 5. Issue reputation-based non-transferable NFTs to reward community members and contributors #### Self-sovereign reputation management portal for Web3 citizens to: 1. Browse their DIDs and the associated on-chain data 2. Link their on-chain, off-chain, and in-app data to their DID 3. View, manage, and authenticate reputation claims or requests 4. Program a particular reputation output in the form of scores, NFTs, VCs, or reports using one's own choice of data and model 5. Participate in campaigns and claim reputation NFTs # Orange Humanity Score (OHS) The Orange Humanity Score (OHS) in the [Orange Reputation Studio](https://app.orangeprotocol.io/c/space/info) is a feature designed to evaluate the authenticity and engagement of digital interactions. The OHS goes beyond measuring just activity. It assesses the quality of online interactions, ensuring that real, meaningful engagements are recognized. The OHS takes a variety of factors and sources into account, from on-chain identity to Web2 social accounts like Discord and Twitter. The more sources and forms of identity are provided, the higher your OHS becomes. You can either create it as a Verifiable Credentials (VC) and save it locally to your devices or mint your OHS in the form of an NFT on preferred blockchain to use in gaining access to communities, reputation-based airdrops, and other activities that require a robust POH. Here we’ll explain the basics of OHS and how to generate your own score and NFT in the Orange Reputation Studio. ## Understanding and Generating Your OHS The Orange Humanity Score (OHS) measures the authenticity of users and their interactions in Web3. It indicates how involved and credible users are, considering both on-chain factors and identities in Web 2.0 such as Twitter, Discord, and Telegram. The OHS is calculated based on several key factors: * **Social Proof:** The credibility and trust users have in the online spaces they use, from social media to Web3. It not just verifies if you are the owner of the account, but also rates the score according to your reputation based on your account’s usage history. * **PoH**: If you have done the PoH verification at other platforms which are partnering with Orange, you don’t need to do duplicate verification again. Upon authorization of exiting POH, your score will be updated automatically.
**Verifying Social Accounts** To generate your Orange Humanity Score, link your social media profiles to the [OHS page of the Reputation Studio](https://app.orangeprotocol.io/c/manage/orange-humanity). Follow these steps: 1. **Connect Your Wallet:** Use the address that you use most for POH or that you most associate with your identity. 2. **Connect Your Social Media:** Authorize OHS to access your social media profiles (Facebook, Twitter, Discord, etc.). 3. **Generate Your OHS:** Click “Update” to get your latest Orange Humanity Score. Once you’ve generated your latest Orange Humanity Score, you’ll be ready to mint your OHS as an NFT and utilize it throughout Web3 as Proof of Humanity. ## Proof of Humanity (POH) and OHS Integration Proof of Humanity (POH) is a crucial component of the Orange Humanity Score. It’s a digital fingerprint that verifies the authenticity of a user’s online presence. POH ensures that the user is a real person, not a bot or fake account. This helps to maintain the integrity of the OHS and prevent manipulation of the score. Currently, Orange has partnered with leading PoH providers such as [BrightID](https://www.brightid.org/) and [Gitcoin Passport](https://passport.gitcoin.co/). Those who have already completed verification on these platforms don’t need to take any additional steps. Simply obtain your OHS with just a few clicks using your existing POH. ## Managing Your OHS On-chain and Off-chain There are two options for managing your OHS, either on-chain or off-chain, depending upon your preference. ### **Onchain Management** Onchain management refers to the process of managing your OHS on blockchain platforms. ### Get Orange Protocol’s stories in your inbox Join Medium for free to get updates from this writer. Subscribe This approach provides a secure, transparent, and decentralized way to store and manage your OHS. Here’s a step-by-step guide to managing your OHS on-chain: 1. **Create a Wallet:** Set up a digital wallet to store your OHS. Make sure it’s compatible with the chosen blockchain platform. 2. **Choose a Blockchain Platform:** Select a reputable blockchain platform that supports OHS, such as Ontology EVM or Binance Smart Chain. 3. **Mint OHS NFTs:** Please note that minting will incur minor gas fees. Ensure you have sufficient gas tokens on the chosen blockchain. 4. **Store OHS Tokens:** Store your OHS tokens securely in your wallet, ensuring they are not compromised. 5. **Update OHS NFT timely**: Once your OHS is updated, remember to update your NFTs simultaneously on-chain. ### **Off-chain Management** Off Chain management refers to the process of managing your OHS outside of blockchain platforms. This approach is often used for smaller-scale OHS management or when a higher privacy standard is set. Here’s a step-by-step guide to managing your OHS off-chain: 1. **Choose a Storage Solution:** Select a secure storage solution, such as a cloud-based storage service or a local file storage system. 2. **Encrypt Your OHS:** Encrypt your OHS using a secure encryption algorithm to protect it from unauthorized access. 3. **Store OHS Data:** Store your OHS data in the chosen storage solution, ensuring it is secure and accessible only to authorized users. 4. **Regularly Back Up:** Regularly back up your OHS data to prevent data loss in case of a storage failure. ## Unlocking the Utility of Your OHS One of the key benefits of OHS is its ability to prevent duplicate verification. This ensures that your online presence is unique and authentic, guarding against bots and fake accounts from manipulating your score. **Access to Partner Campaigns and Exclusive Incentives** Your OHS grants access to partner campaigns and exclusive incentives. These campaigns are designed to reward users who demonstrate high levels of engagement and empathy online. Here’s how OHS grants access to partner campaigns: 1. **Partnerships:** OHS partners with reputable organizations and brands to offer exclusive incentives and campaigns. 2. **Score-Based Access:** Users with high OHS scores are granted access to these campaigns, ensuring that only genuine and engaged users participate. 3. **Exclusive Rewards:** Users who participate in these campaigns receive exclusive rewards, such as tokens, NFTs, or other digital assets. **Unlock Special Benefits for Projects’ Token Generation Events (TGEs)** Your OHS can also unlock special benefits for projects’ token generation events (TGEs). These benefits include: 1. **Priority Access:** Users with high OHS scores are granted priority access to TGEs, ensuring they can participate in the early stages of the project. 2. **Exclusive Discounts:** OHS users receive exclusive discounts on TGE tokens, making it more affordable to participate in the project. 3. **Enhanced Project Visibility:** Projects that partner with OHS receive enhanced visibility, attracting more engaged and empathetic users to their TGE. ## Deepening Web3 Authenticity with OHS The widespread adoption of the Orange Humanity Score (OHS) and OHS NFTs is vital for creating a more secure and authentic online environment. By embracing OHS, individuals and organizations can ensure the integrity of their online presence, prevent fake accounts, and foster deeper connections with others. Adopting OHS enhances reputation, trust, and user engagement. As Web3 evolves, widespread adoption of OHS and OHS NFTs will be essential for creating a more trustworthy, efficient, and connected blockchain ecosystem. # Use Cases Scenarios and use cases Web3 communities can benefit largely from Orange as a decentralized protocol that makes the capturing, storing, and utilization of user reputation easy, agile, and transparent. ## Scenarios to Use Orange Each system applies a set of rules on assessing if a particular user is legit to be involved in certain activities. Below are a few scenarios we envision where such assessment is essential and potential criteria to consider: ### Granting Entry A user's entry into a system can be designed based on criteria such as: * Sybil-resistant identity verification * Possession of particular fungible or NFT assets * Social-media verification * Subscriber count and endorsements, and more. ### Participation, Engagement, and Contribution A user's participation in a system can be reflected in actions such as: * Proposal initiation and discussions * Voting participation * Work contribution to treasury management, etc. * Records of donations to public goods * Participation data of certain activities ### Reputation and Influence A user's influence in decision-making can be agreed upon by taking different factors into account, such as: * past decision results * verified credentials of expertise * endorsed trust by other community members ### Creditworthiness A user's credit-worthiness to avail particular levels of a service can be established using data such as: * history of transactions * asset attributes * off-chain verified financial risk data * verified identities And so on. Orange streamlined the process of identity reputation assessment design and execution. Set free from the effort of dealing with scattered data, decentralized applications and systems can get user reputation reports straightaway. ## Use Cases in Different Sectors ### DeFi: User Segmentation In DeFi, user identities are concealed behind addresses. Failing to determine the reliability and engagement level of a user not only hinders DeFi projects to further develop the relationship with high-quality users, but also threatens the security of the ecosystem. Orange makes it possible to group users according to their reputation calculated using on-chain and off-chain data associated with wallet addresses, such as: * Age of address * Transaction history * Holding of assets on specific chains * DeFi participation history * Social media verification User reputation assessment helps DeFi projects prevent potential security incidents such as Sybil attacks. Also, a deeper insight on users establishes a foundation for marketing activities targeting a distinct user group. ### DAO: Reputation-based Voting DAOs provide a more democratic way to cooperate. Any changes to the rules of a DAO must be approved by DAO members through voting. Today, token-weighed voting is the primary mechanism, in which a member's voting power is decided by the token holding. But this model brings potential inequality and security risks. Orange enables a new solution of reputation-based voting. Voting power is distributed according to each member's reputation score represented by their reputation NFTs. With this new mechanism, the direction of a DAO will no longer be in the hands of the wealthy few. It will also incentivize users to be more active in DAO governance. Read more details [here](/case-studies/reputation-nft-based-voting-mechanism). ### SocialFi: Content Recommendation SocialFi are platforms where users can monetize their social interactions and communicate their ideas on cryptocurrencies. Users with different levels of experiences expect to obtain different information from these platforms. Orange allows platforms to suggest personalized contents to a user based on their: * Token holding * NFT holding * Transaction frequency * DeFi & DAO participation ### Reputation NFT Communities and dApps can issue reputation-based NFTs with different user reputation requirements, so they can provide users with utilities that certain NFT holders are eligible to be entitled. NFT eligibility takes into account of user information such as: * DeFi activities * DAO participation * Discord activities # Glossary Keywords and Concepts ## KYC A process where a user's identity is determined or confirmed. Different levels of KYC verification can unlock access to features and resources on different platforms. ### Traditional KYC Verification methods that take a user's identity documents such as passport, driving license, or other documents that are issued and verified by a centralized authority to establish their identity. ### Decentralized KYC Verification methods that establish and verify a user's identity in an ecosystem using processes that do not rely on any central authority for verification. ## DID [Decentralized identifiers](https://www.w3.org/TR/did-core/#dfn-decentralized-identifiers) (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A [DID](https://www.w3.org/TR/did-core/#dfn-decentralized-identifiers) refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the [DID](https://www.w3.org/TR/did-core/#dfn-decentralized-identifiers). An example of a DID string is ***did:ont:t52065e...6Av8eE09.*** Refer to the [**W3C DID Proposed Recommendation** ](https://w3c.github.io/did-core/#a-simple-example)for more details. ## Credential Verifiable credentials basically contain information that is necessary to determine if the credential is genuine. Any party can issue credentials in a trust network. That would make them a source of trust within the network. Users store and maintain credentials after they’re issued. They may choose to selectively, or totally share the data within a credential with credential consumers, who then verify it using the attested record on a public ledger such as Ontology or Ethereum. Refer to the [**W3C Verifiable Credentials docs**](https://www.w3.org/TR/vc-data-model/#what-is-a-verifiable-credential) for more details. ## Model Provider A role within the Orange protocol. Abbreviated as **MP**. **MPs** put together models that they may choose to use for themselves, or make available for public use. ### Model Models define the way data is used to determine the reputation for a DID. You can create and customize models to define the operations that are performed on the data and the weightage that is assigned to data. Each model takes a set of useful data and generates a report depending on the design. ## Data Provider A role within the Orange protocol. Abbreviated as **DP**. **DPs** put together datasets that they may choose to use for themselves or make available for public use. ### Datasets Datasets are collections of on-chain or off-chain data that can be plugged into models. They can be classified based on the platform or ecosystem they are fetched from, and the nature of the use case they were collected in. To plug a dataset into a model, its schema must match with the input parameters of the said model. {% hint style="info" %} Useful data from different sources can also be compiled together by **DPs** to form a dataset. {% endhint %} # Data Diversity Multi-sourced on-chain and off-chain data Public transaction data from any number of sources can first be fetched, and then all the related data points can be uniformly consolidated to form datasets which can then be used within the system. Any off-chain data can also be processed in the same manner. An example would be KYC data that may include user identification information from government-issued ID cards, licenses, permits, etc. After fulfilling the necessary privacy and authorization requirements, **DPs** can organize this data into meaningful datasets that are accessible via **Orange**. This is the role a [**Data Provider (DP)**](/glossary#data-provider) plays within the Orange system. {% hint style="info" %} Datasets can be made available for public access. However, this is not a necessity. Certain applications or platforms may be looking to use a model, while ensuring that their datasets remain limited to themselves and their system. In this case, their dataset can be used with an available model **without making the data public.** {% endhint %} Data points from different datasets and **DPs** can be combined and used with compatible models. Applications can thus access data from multiple ledger networks and sources via Orange, and process it to establish user reputation. # Model Versatility All reports are generated by running data from a [**Data Provider**](/glossary#data-provider) (**DP**) through a model put together by a [**Model Provider**](/glossary#model-provider) (**MP**). The parameters that a model takes can be defined and configured depending on the use case. So each application can have their customized model for reputation assessment for the addresses and DIDs in their ecosystem. **MPs** may also choose to make their models public, which makes them available for use publicly and accessible via Orange. They can be integrated and used by any application or system. Thus, a model constructed and used by one application can still be used by other applications. Useful reputation models have the potential to set the foundation for reputation, since they are tools for value discovery in nascent Web3 ecosystems. # Configurable Reporting Flexible result manifestation Models process the data passed to them and generate results. These results are a basic representation of their reputation in a certain context. Depending on the way a system or an application processes the data and the operations that are to be performed on it, these results can be exported, or **"minted"**. User data processed and manifested in the form of **"minted reputation"** can be stored, exchanged, and used in many different forms, such as [**Verifiable Credentials**](/glossary#credential), and **NFTs**. Verifiable credentials and NFTs both have unique features and offer different benefits. Let's see what they can be used to achieve. ## Non-Fungible Reputation Tokens A **Non-fungible Reputation Token** is just an NFT with the necessary reputation data associated with it in the form of metadata. Some advantages that such tokens can offer with regards to reputation assessment. * Easy to transfer and prove ownership * Easy to store since it lives in a wallet, like any other asset ## Verifiable Credentials Verifiable credentials **(VCs)** are a broad category of data representations that store verified information regarding a subject. This information can be customized to a great degree and used to make reputation related deductions and judgements. Advantages that a verifiable credential offers: * Extremely flexible, can be stored and processed in different forms * Information can be selectively disclosed and shared (Refer [**here**](https://w3c-ccg.github.io/data-minimization/#selective-disclosure)) * [**DID**](/glossary#did) compatible by design (See example [**here**](https://w3c.github.io/vc-data-model/#example-1-a-simple-example-of-a-verifiable-credential)) Due to the fact that credentials can be stored in different locations without affecting their verifiability, the data and reputation assessment results generated using **Orange** can be used **across blockchains**, and across **different platforms**. # Self-Sovereignty and Privacy VCs and NFTs to represent reputation for later verification ## Encrypted Data Transmission In the Orange protocol, any data that is fetched from a [**Data Provider**](/glossary#data-provider) **(DP)** is encrypted using an [**Model Provider**](/glossary#model-provider) 's **(MP)** public key. This means the data remains secure as it enters the system and is sent to the **MP** to be processed. In the [future](/future/decentralized-collaboration-network), Orange will integrate zero-knowledge proofs and the private computation technology to enhance its security. ## Verifiable Credentials Verifiable credentials are an integral part of decentralized identity and reputation. They contain and carry any necessary data that needs to be shared between two parties, while also carrying with it any data that is necessary to prove that the contents: 1. have been verified and signed by a certain issuer 2. have not been tampered with This logic is carried out using signature and cryptographic proof verification. Reputation reports and scores are produced in the form of downloadable credentials. They are directly linked to a user's DID, and a record of the credential's status exists on-chain. That way, any entity within the ecosystem can verify the claims made by the user, and assess their credibility by verifying the party that issued the credential. ### User Authorization To establish the relationship between a subject and any associated data, the Orange protocol uses [**Decentralized Identifiers**](/glossary#did) **(DIDs)** that link wallet addresses from multiple chains. Each calculation request **MUST** carry signature data with it for it to be valid. This ensures no data can be used or associated with a user without their authorization. {% hint style="info" %} A user uses their private key to sign messages when giving authorization for an action {% endhint %} Actions that require user authorization: * Sending calculation requests for a wallet address or DID * Accessing credential data ### Selective Disclosure Selective disclosure is an inherent property of verifiable credentials and can be implemented fairly easily in a system. This will become beneficial when in the future, Orange issued verifiable credential may contain multiple types of information, while not all fields are necessarily to be shared. Say you need to prove your credibility in a particular situation, and you have a verifiable credential that was issued by an entity in the network using Orange. For example, ```javascript { "iss": "did:ont:AXdmdzbyf3WZKQzRtrNQwAR91ZxMUfhXkt", "sub": "{\"data\":{\"provider_did\":\"did:ont:AS1QrBpgiPtPoggSU4YRyYNFBtCRnBMaDU\",\"method\":\"queryXdaysSumWithDefi\",\"data\":\"\"},\"algorithm\":{\"provider_did\":\"did:ont:testap\",\"method\":\"calc30xWithDefi\",\"score\":\"775\"}}", "exp": 1634537432, "nbf": 1633673433, "iat": 1633673433, "jti": "urn:uuid:af4599ed-eb8e-43e2-8fd5-1784cfe9c218", "vc": { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://ontid.ont.io/credentials/v1", "context1", "context2" ], "type": [ "VerifiableCredential", "OscoreCredential" ], "credentialStatus": { "id": "4f7f159ac4b9913bb185fdf1895705f61b7d0cc6", "type": "AttestContract" }, "proof": { "created": "2021-10-08T06:10:33Z", "proofPurpose": "assertionMethod" } } } ``` In this case, it's possible that you take the proof from the credential, and the `score` field to generate a **presentation** that contains that single field only, while also including details regarding who it's meant for (a particular DID or wallet address) so it can not be tampered and re-used. These actions are recorded on-chain for future verification. Refer to the [**W3C recommendation**](https://www.w3.org/TR/vc-data-model/) on verifiable credentials and presentations for more details on implementation. The flexibility that credentials provide, when combined with zero-knowledge proofs, is an important development as far as data interoperability and reputation management in P2P networks is concerned. ### Non-custodial The system doesn't store any data that can be identified and connected to a user, more formally referred to as Personally Identifiable Information (PII). A user may choose to download the result of their calculation as a file, generate a verifiable credential, or mint an NFT, but all of the data remains in their control. Without authorization, it cannot be reused for any other purpose. Thus, a user maintains complete control over how their data is processed and shared. # Architecture System infrastructure and components ## High-level Infrastructure The Orange system receives invocation requests from applications with specific models and datasets. First, it invokes the model specified in the invocation request by sending a request to the service set up by the **Model Provider (MP).** Next, based on the selected [**Data Provider**](/glossary#data-provider) **(DP)** and [**dataset**](/glossary#datasets), the system fetches data using an interface provided by them. After the calculation is complete and a result is generated, the system stores the result temporarily till it is fetched by the application. {% hint style="info" %} The system processes model invocation requests in the form of **tasks.** Each task corresponds to an individual [**Decentralized Identifier**](/glossary#did) **(DID)** **or wallet address.** Refer to the [**integration guide here**](/developers/within-your-system) for details. {% endhint %} The application can then proceed to fetch the result in its raw form (data object), or send a request to export it in the form of a verifiable credential or NFT. The following figure illustrates how the different components that make up the Orange system are connected and interact with each other. ![](/files/PGmg0IqmD0WbykCporZM) Let's go over each component individually. #### GraphQL API Server The interface for applications to interact with the Orange system. It serves the following purposes: * Fetching details of registered [**Model Providers**](/glossary#model-provider) **(MP)** and [**Data Providers**](/glossary#data-provider) **(DP)** * Fetching details on publicly available models and datasets * Sending calculation requests * Fetching the generated results #### DP Manager A service module that **DPs** primarily interact with. The **DP manager** performs the following functions: * Preliminary verification and docking * Data interface invocation to fetch and query data #### MP Manager A service module that **MPs** primarily interact with. Enables the following features: * Preliminary verification and docking * Execution request handling * **WASM based:** Fetches a binary file for the model and performs service execution in an integrated execution environment * **Custom:** Invokes a standalone server deployed by the **MP** for service execution. Invocation via a **RESTful/RPC API**. #### Dispatcher A service module that basically handles all the requests from applications. It interacts with other components to perform a number of functions: * Fetches data from a specified **DP** after receiving a data request * Sends execution requests to a specified **MP** after receiving calculation requests * Sends the results generated by the **MP** to the **reputation minting service** for further processing #### Reputation Minting Service A service that takes the calculation results produced by **MPs** and generates a specified form of verifiable proof. Some examples would be: * Verifiable Credentials * NFTs **Blockchain** Represents the ledger network where records are maintained. For instance, * Record of a verifiable credential issued to a [**DID**](/glossary#did) * Deploying NFT contracts that mint tokens based on the reputation assessment reports received from the Orange system # Model Providers Design models that capture reputation Each system has reputation and identity needs specific to their use case. The main difference lies in the way reputation is generated. The Orange protocol defines a role for the party that adds a method of calculation, an model, to the system for calculating and assigning reputation markers to different entities within the ecosystem. It is referred to as an **Model Provider**, or **MP**. An model defines the parameters it takes and the operations it performs with each one of them. MPs have total control over the way they design models to generate reputation. They may generate singular scores, multiple scores with specific properties, or even reports with rich attributes. {% hint style="info" %} **Model Providers** may choose to keep their model **private** and accessible only to themselves on the Orange platform. Any model or service, unless made **public**, cannot be viewed or selected by other users in the Orange network. {% endhint %} ## Why become a MP? As Model Providers design their custom models, they can choose to make them available for other parties to use and integrate to their systems. Systems with similar requirements need not each design their own model if they can find and use one that demonstrably works. # Data Providers Provide data used to capture reputation Ledgers essentially operate upon the data that they collect. All actions are stored in the form of transactions in a P2P network. Generally speaking, most data remains limited to the system it was collected in. To create a true on-chain identity protocol that does not need to depend on off-chain data and credentials to establish the reputation of an entity, on-chain data needs to be accessible throughout the Web3 space, and not just stay limited within the respective ledger networks. A fundamental building block of Orange protocol is data that can be taken from different ledger networks and be made available throughout a whole system of ledger networks. The role of a **Data Provider**, or **DP** is defining schemas that act as interfaces between systems such that their data can be accessed outside their ledger network conveniently and used as input for models designed by different **MPs**. {% hint style="info" %} **Data Providers** may choose to keep their data **private** and accessible only to themselves on the Orange platform. Any data, unless made **public**, cannot be requested by other users in the Orange network. {% endhint %} ## Why become a DP? The basic nature of ledgers results in data being collected in P2P networks. Let's say you decide to become a DP and build schemas using the data on your network. This data is now available for the entire Orange ecosystem to be uniformly accessed and processed using the public models. # Assess Reputation for Your dApp Users An SDK to integrate Orange to your dApp {% hint style="warning" %} The "algorithm" and "AP" in method and variable names refer to "model" and "MP" respectively. {% endhint %} You can invoke the models of your choice available via Orange by sending invocation requests from your dApp to the system using the [Orange Server SDK](https://github.com/orange-protocol/orange-sdk-go). The general sequence in which you would call the methods to send an invocation request by specifying an model and a dataset is: 1. Call **`GetAlgorithmProviders`** and **`GetDataProviders`** to go through the available model and data providers. 2. Choose an MP and DP, and call **`GetAlgorithmMethods`** and **`GetDataMethods`** to fetch the method details on available models and datasets. 3. Choose an MP method and a DP method ensuring the schemas match, then call **`RequestOrangeScore`** to send an invocation request along with authorized and signed wallet information. 4. Call **`GetUserTask`** to fetch the invocation results, or the status of a task. The results can be exported in the form of [**Verifiable Credentials**](/glossary#credential). Refer to the [**verifiable credential docs here**](https://www.w3.org/TR/vc-data-model/#concrete-lifecycle-example) for more details on how that can be implemented. ## SDK intro The Orange server uses GraphQL for its interface design. You can use the methods defined below to perform actions such as fetching MP and DP schema details and sending calculation requests using a model-data pair for specific wallets and DIDs. {% hint style="info" %} To use the SDK you need a DID for your dApp. You can get one by creating a wallet using [ONTO app](https://onto.app/en/download/?mode=app). {% endhint %} ## Initialization Add this dependency in the `go.mod` file in your project. ``` github.com/orange-protocol/orange-sdk-go latest ``` ## Schema definition The major schemas defined for the interface are described below. ```graphql type AlgorithmProvider{ name:String! type:String! introduction:String! did:String! createTime:Int! title:String! provider:String! invokeFrequency:Int! apiState:Int! author:String! popularity:Int! delay:Int! icon:String! } type DataProvider { name:String! type:String! introduction:String! did:String! createTime:Int! title:String! provider:String! invokeFrequency:Int! apiState:Int! author:String! popularity:Int! delay:Int! icon:String! } type ProviderMethod { name:String! paramSchema:String! resultSchema:String! } type UserTasks { taskId:String! userDID:String! apDID:String! apName:String! apMethod:String! dpDID:String! dpName:String! dpMethod:String! createTime:String! updateTime:String! taskStatus:String! taskResult:String resultFile:String issueTxhash:String } input RequestOrangeScoreReq{ appdid:String! data:RequestOrangeScoreData! sig:String! } input RequestOrangeScoreData { userdid:String! apdid:String! apmethod:String! dpdid:String! dpmethod:String! overwriteOld:Boolean! wallets:[UserWallet!]! } input UserWallet{ chain:String! address:String! pubkey:String! sig:String! } # Currently defined queries type Query { getAllAlgorithmProviders:[AlgorithmProvider!]! getAllDataProviders:[DataProvider!]! getAlgorithmMethods(did:String!):[ProviderMethod!]! getDataMethods(did:String!):[ProviderMethod!]! getUserTask(key:String!,taskId:Int!):UserTasks } type Mutation { requestOrangeScore(input:RequestOrangeScoreReq):Int! } ``` ## Interface methods ### 1. Fetch details for all available MPs Returns the details of all the currently registered model providers. **Method:** **`GetAlgorithmProviders`** **Parameters:** none **Returns: `[]*AlgorithmProvider`** ```go type AlgorithmProvider struct { Name string `json:"name"` Type string `json:"type"` Introduction string `json:"introduction"` Did string `json:"did"` CreateTime int64 `json:"createTime"` Title string `json:"title"` Provider string `json:"provider"` InvokeFrequency int64 `json:"invokeFrequency"` APIState int64 `json:"apiState"` Author string `json:"author"` Popularity int64 `json:"popularity"` Delay int64 `json:"delay"` Icon string `json:"icon"` } ``` ### 2. Fetch available methods for an MP Returns all the currently available models and the associated schemas as defined by an MP. **Method:** **`GetAlgorithmMethods`** **Parameters** * **`apdid`-** The DID of specified MP **Returns: `[]*ProviderMethod`** ```go type ProviderMethod struct { Name string `json:"name"` ParamSchema string `json:"paramSchema"` ResultSchema string `json:"resultSchema"` } ``` ### 3. Fetch details for all available DPs Returns the details of all the currently registered data providers. **Method:** **`GetDataProviders`** **Parameters:** none **Returns: `[]*DataProvider`** ```go type DataProvider struct { Name string `json:"name"` Type string `json:"type"` Introduction string `json:"introduction"` Did string `json:"did"` CreateTime int64 `json:"createTime"` Title string `json:"title"` Provider string `json:"provider"` InvokeFrequency int64 `json:"invokeFrequency"` APIState int64 `json:"apiState"` Author string `json:"author"` Popularity int64 `json:"popularity"` Delay int64 `json:"delay"` Icon string `json:"icon"` } ``` ### 4. Fetch available data methods for a DP Returns all the currently available datasets and the associated schemas as defined by a DP. **Method:** **`GetDataMethods`** **Parameters** * **`dpdid`-** The DID of specified DP **Returns: `[]*ProviderMethod`** ```go type ProviderMethod struct { Name string `json:"name"` ParamSchema string `json:"paramSchema"` ResultSchema string `json:"resultSchema"` } ``` ### 5. Send a request to run the model with selected data Sends a request to generate the score or report for the specified wallet addresses using the specified model and dataset, or MP and DP method respectively. Returns a **`taskId`**. {% hint style="info" %} Calculation requests are handled asynchronously. You can use the returned task ID to fetch the generated result.\ \ Please note that certain types of data or volume may take some time to fetch, and so the calculation may take **up to an hour** in certain **extreme** cases after a request is sent successfully. {% endhint %} **Method:** **`RequestOrangeScore`** **Parameters** * **`*RequestOrangeScoreReq`-** defined below ```go type RequestOrangeScoreReq struct { AppDid string `json:"appDid"` // DID of your dApp Data RequestOrangeScoreData `json:"data"` // request data, specified as below Sig string `json:"sig"` // signature: dApp's DID signed with its private key } type RequestOrangeScoreData struct { Userdid string `json:"userDid"` // DID of the user Apdid string `json:"apdid"` // DID of the MP Apmethod string `json:"apmethod"` // MP method name Dpdid string `json:"dpdid"` // DID of the DP Dpmethod string `json:"dpmethod"` // DP method name overwriteOld bool `json:"overwriteOld"` // whether override existing task Wallets []*UserWallet `json:"wallets"` // user's wallet details, specified as below } type UserWallet struct { Chain string `json:"chain"` // name of the chain Address string `json:"address"` // linked wallet address Pubkey string `json:"pubkey"` // wallet public key Sig string `json:"sig"` // signature: user's DID signed with their private key } ``` **Returns: `int64`** ### 6. Fetch result/status for a task **Method:** **`GetUserTask`** **Parameters** * **`key`-** API key * **`taskId`** - task ID **Returns: `*UserTasks`** ```go type UserTasks struct { TaskID string `json:"taskId"` UserDid string `json:"userDID"` ApDid string `json:"apDID"` ApName string `json:"apName"` ApMethod string `json:"apMethod"` DpDid string `json:"dpDID"` DpName string `json:"dpName"` DpMethod string `json:"dpMethod"` CreateTime string `json:"createTime"` UpdateTime string `json:"updateTime"` TaskStatus string `json:"taskStatus"` TaskResult *string `json:"taskResult"` // score points ResultFile *string `json:"resultFile"` // credential file IssueTxhash *string `json:"issueTxhash"` // transaction hash for the credential on ontology } ``` ## Sample invocation Refer to the sample code below that invokes the **`GetAlgorithmProviders`** method. ```go func TestOrangeSDK_GetAlgorithmProviders(t *testing.T) { sdk, err := NewOrangeSDK("http://localhost:8080/query") assert.Nil(t, err) aps, err := sdk.GetAlgorithmProviders() assert.Nil(t, err) assert.NotNil(t, aps) assert.Greater(t, len(aps), 0) } ``` # How to Start ### 1. Background To make it easier for developers to start at Orange Protocol, a proxy template is provided, with wrapper data & module interface in Orange system. Thus, every developer can get started quickly as a Proxy Provider. ### 2. Proxy Provider Introduction
Proxy wrapper helps provide a unified interface for different providers, hiding API keys, embedding request data signature verification and decryption, response data signing and encryption.
### 3. How to be an Orange proxy provider If you want to be an Orange proxy provider, you need to follow these steps: 1. Register the provider in Orange system.
2. Fill in the provider information in Orange system.
**Note**: the "Signing Address" is used to sign the response message and decrypt the response message as a module provider. 3. The register information will be reviewed by Orange system. If approved, the provider will be activated. #### 3.1 Orange proxy wrapper 1. Get Orange proxy wrapper project from [Github](https://github.com/orange-protocol/orange-provider-wrapper) ``` git clone https://github.com/orange-protocol/orange-provider-wrapper.git cd orange-provider-wrapper go build ``` Generally, you don't need to modify the code of the proxy wrapper, but you can customize the provider information if you need to connect to the api which requests formats that are not supported by the provider wrapper. 2. Edit the config.json file A sample config.json looks like below: ``` { "orange_did":"did:etho:1ae43df6f4c5621e2b156162e958c80a67ee4f5f", "keystore":"./keystore", "wallet_pwd":"123456", "chain_id":5851, "chain_rpc":"http://polaris1.ont.io:20339", "contract_address":"0x18d3dB10B18369691c86e7EF99cBd9B290BaD87A", "api_configs":[ { "provider_type":"dp", "verify_request":true, "server_path":"/balance1", "has_api_key":true, "api_key_location":"header", "api_key_name":"x-api-key", "api_key":"test", "api_url":"http://localhost:8088/sampleGetUrlDP", "api_method":"GET", "param_type":"url", "failed_keywords":[] }, { "provider_type":"dp", "verify_request":false, "server_path":"/balance2", "has_api_key":true, "api_key_location":"header", "api_key_name":"x-api-key", "api_key":"test", "api_url":"http://localhost:8088/sampleGetBodyDP", "api_method":"POST", "param_type":"body", "failed_keywords":[] },{ "provider_type":"ap", "verify_request":true, "server_path":"/score", "has_api_key":true, "api_key_location":"header", "api_key_name":"x-api-key", "api_key":"test", "api_url":"http://localhost:8088/sampleAP", "api_method":"POST", "param_type":"body", "failed_keywords":[] } ] } ``` * orange\_did: the DID of the provider in Orange system, which will be published on Orange website. * keystore: the keystore directory of the provider, which contains the private key of the provider. * wallet\_pwd: the password for the wallet stored in the keystore directory. * chain\_id: the chain id of orange contract deployed. * chain\_rpc: chain rpc. * contract\_address: orange contract address. The `chain_id,chain_rpc and contract_address` will also be published on Orange website. * api\_configs: the api configuration of the provider. * provider\_type: "ap" for module provider, "dp" for data provider. * verify\_request: whether to verify the request message signature. * server\_path: the server path of the wrapper service. * has\_api\_key: whether the api requires api key. * api\_key\_location: the location of the api key. The only supported value is "header" for now. * api\_key\_name: the name of the api key. * api\_key: the value of the api key. * api\_url: the api url. * api\_method: the api method, "GET" or "POST". * param\_type: the type of the api parameter, "url" or "body". * failed\_keywords: the keywords of the response message which will cause the request to fail. #### 3.2 Create sign wallet and register did 1. Create wallet run the following command in your terminal ``` ./orange-provider-wrapper --operation new-wallet ``` the standard ethereum wallet file will be generated in the keystore directory with the password you set in config.json. 2. Register did run the following command in your terminal ``` ./orange-provider-wrapper --operation register-did ``` ***NOTE***: You need to transfer some gas to the wallet address you just created. #### 3.3 Proxy data provider If you want to be a data provider, you just need to : 1. Get a data source api. For example: ``` http://sampleDataSourceApi/sampleGetUrlDP?address=0x123456 ``` with apikey :`x-api-key:test` in request header add "api\_configs" section in config.json: ``` { "provider_type":"dp", "verify_request":true, "server_path":"/balance1", "has_api_key":true, "api_key_location":"header", "api_key_name":"x-api-key", "api_key":"test", "api_url":"http://sampleDataSourceApi/sampleGetUrlDP", "api_method":"GET", "param_type":"url", "failed_keywords":[] } ``` The proxy wrapper will listen to the GET /balance1 path and forward requests to data source api with api key 2. Create dataset in Orange
Fill in the dataset information
Choose "GET" and input the wrapper url `http://wrapper_address/balance1` Add param "address" with value "User Address"
This will actually create a dataset with url `http://sampleDataSourceApi/sampleGetUrlDP?address=$DEFAULT_USER_ADDRESS` if you choose the "POST" method, you need to add the param "body" with the request body with ``` { "address":"$DEFAULT_USER_ADDRESS" } ``` Currently, Orange supports * User Address: the default address of a logged in user. * Twitter Handle: the Twitter handle of a logged in user.(if bound) * Discord ID: the Discord ID of a logged in user.(if bound) * Customer Value: any customer string value. (for example: "ethereum" or "eth") **Parameter Schema & Output Schema** schema of the input parameter and output data, used for match dataset and module.(module's parameter schema should exactly match the dataset's output schema) #### 3.4 Proxy module provider Similar to the dataset. 1. Get a module api. 2. Add "api\_configs" section in config.json and set `provider_type` to "ap". 3. Create a new module in Orange. [![](https://github.com/orange-protocol/orange-provider-wrapper/raw/main/doc/images/beProvider6.png)](https://github.com/orange-protocol/orange-provider-wrapper/blob/main/doc/images/beProvider6.png) 4. Fill the module information ### 4. Audit Orange will audit your provider, dataset and module information. If approved, your provider will be activated and listed on Orange website. [![](https://github.com/orange-protocol/orange-provider-wrapper/raw/main/doc/images/beProvider8.png)](https://github.com/orange-protocol/orange-provider-wrapper/blob/main/doc/images/beProvider8.png) # Become a Data Provider Setting up and docking a DP service {% hint style="info" %} Please refer to [Go ](https://github.com/orange-protocol/orange-dp-sample)and [Java ](https://github.com/orange-protocol/orange-java-dp-example)code samples from respective links. {% endhint %} ## Prerequisites ### ONT ID Each DP must have a unique decentralized identifier (DID) for signing and encrypting data contained in response messages, so the MP can confirm the authenticity and security of the data. At present, it must be an ONT ID. You can get one by creating a wallet using [ONTO app](https://onto.app/en/download/?mode=app). > You can use one and the same DID to set up a DP and an MP. ### Orange Provider SDK The SDK in [Go](https://github.com/orange-protocol/orange-provider-go-sdk) or [Java ](https://github.com/orange-protocol/orange-provider-java-sdk)is needed for signature and data encryption. Below instructions are illustrated in Go. ### Wallet You need to include a wallet file in the local directory of your project for signature and data encryption. ## Compose Datasets and Build Methods {% hint style="info" %} Note that as a **Data Provider**, the method of synchronization or collection you choose to compose datasets is entirely up to you. The Orange system uses the interface defined and shared by you to fetch and then process any data. {% endhint %} Discrete useful data can be combined to create **datasets.** Each dataset can contain mutually related data that can be processed in specific ways to generate specific elements of reputation. Both on-chain and off-chain data are accepted. One DP can provide multiple datasets to Orange users. Every dataset must have an associated method. A method is an abstract definition or reference to a dataset that is useful when querying and fetching data. Each method needs to have a name, and a parameter and result schema associated with it. * The name is used to refer to a particular method * The parameter schema defines the useful data that needs to be passed as input to fetch any relevant data pertaining to the particular method * The result schema defines the structure of the response that will be generated and returned when a certain method is selected ## Create Interfaces for Data Access As a **DP**, you need to set up an externally accessible interface with specific endpoints that can be used to fetch data. These endpoints will be called when the **MP** makes data requests to the Orange system. Currently Orange supports DPs to use **RESTful** and **GraphQL** API formats. ### **Parameters** The interface can retrieve data using these parameters: ``` "$API_KEY" // The API key assigned to DP when registered "$ARRAY" // Array type, see details below "$CHAIN_NAME" // Network that user's wallet is connected to. E.g., "eth","bsc" "$USER_ADDRESS" // User wallet address "$ENCRYPTED" // See details below "$USER_DID" // DID of API caller, by default it's the DID of the WASM execution environment "$DEFAULT_CHAIN_NAME" // Name of the network that "$DEFAULT_USER_ADDRESS" is on "$DEFAULT_USER_ADDRESS" // See details below "$AP_DID" // DID of MP "$ORANGE_DID" // DID of Orange system ``` **`$ARRAY`** You can pass multiple values for `$CHAIN_NAME` and `$USER_ADDRESS` in the form of an array using `$ARRAY` in the following structure: ``` assets:$ARRAY[{chain:$CHAIN_NAME,address:$USER_ADDRESS}]6 ``` Then it will be automatically converted to this format: ``` assets:[{chain:"",address:""},{chain:"",address:""},...] ``` **`$ENCRYPTED`** To configure whether to encrypt the data in the [response](#response). The default value is `true`. The MP will pass `false` if data should not be encrypted. **`$DEFAULT_USER_ADDRESS`** When user DID conforms to the method for Ethereum (did:etho), it's the address used for login; when user DID conforms to the method for Ontology (did:ont), it's the first wallet address added to Orange ### **Request** **RESTful POST** For POST requests, parameters should be included in the request body in JSON: ```http {"user_did": $AP_DID,"address": $DEFAULT_USER_ADDRESS,"chain": $DEFAULT_CHAIN_NAME,"encrypt": $ENCRYPTED} ``` **RESTful GET** For GET requests, parameters should be included in the request URL: ```http ?user_did=$AP_DID&address=$DEFAULT_USER_ADDRESS&chain=$DEFAULT_CHAIN_NAME&encrypt=$ENCRYPTED ``` **GraphQL** Orange's DP uses GraphQL API format. An example of parameters in a request: ```graphql { "query":"query{ queryUserNFTAssets(input:{ key:$API_KEY, user_did:$USER_DID, address:$DEFAULT_USER_ADDRESS, require_chains:[\"eth\",\"bsc\"], xdays:180, encrypt:$ENCRYPTED }){ data{ data{ first_nft_days, trade_counts_opensea_in_xdays, has_nft_in_opensea, nft_kinds_in_xdays, bsc_first_nft_days, bsc_nft_kinds_in_xdays }, sig }, encrypted } }", "variables":{} } ``` ### Request Authentication (**in development**) You can choose to authenticate API requests by requiring the MP to include a signature created using Orange system DID in requests. This is an example of a signature: ```go f, err := didsdk.VerifySig(requestJson.CallererDID, msgbytes, sigbytes) if err != nil || !f { fmt.Printf("VerifySig failed:%s\n", err.Error()) c.JSON(http.StatusBadRequest, gin.H{"error": fmt.Errorf("invalid signature")}) return } ``` ### Response ```go { "data":{ "data":{}, "sig": } "encrypted": } ``` If in the request, the value for `$ENCRYPTED` is `true`, then in the response the `data` field (at the same level with the`encrypted` field) is empty, and the `encrypted` field takes the encrypted result of the data. If the value for `$ENCRYPTED` is `false`, the `data` field takes the data itself without encryption and the `encrypted` field is empty. ## Publish Interface When your interface is ready to be accessed on the mainnet, you can publish it on the Orange platform for developers to discover and use it. You can do it in the [Reputation Studio](https://app.orangeprotocol.io/). **Step 1:** Click on the **"Connect Wallet"** button on the top right to connect your wallet. You can find a detailed guide [here](https://docs.orangeprotocol.io/support/reputation-studio-guide). **Step 2:** Click on the **Menu** button and select **"Management"**. Choose **"My Datasets"**. **Step 3:** Click on the **"Create Profile"** button and fill out the form to create your profile as an MP. **Step 4:** Click on the **"Create Dataset"** and fill out the information following the steps indicated on the page. Then you can either click **"Save"** to save the draft, or click **"Publish"** to submit your dataset for review and publication. ## Receive Requests When a user wants to generate a reputation score using your data, the Orange system sends a request to the associated MP first, and then the MP sends a request to your DP API to fetch the data. ## Sign Requested Data When you send a response to the MP, you need to to sign the response using your DID. To do so, you need the Orange [Go SDK](https://github.com/orange-protocol/orange-provider-go-sdk) and a wallet. ### Import SDK ```go import( orangeSDK "github.com/orange-protocol/orange-provider-go-sdk" orangeOnt "github.com/orange-protocol/orange-provider-go-sdk/ont" ) ``` ### Initialize SDK ```go didsdk, err := orangeOnt.NewOrangeProviderOntSdk("./wallet.dat", "123456", "TESTNET") if err != nil { panic(err) } ``` **Parameters** * path of the wallet file * wallet password * network info: `TESTNET` or `MAINNET` ### **Example** For example, a data API returns the token balance of an address: ```go { "balance":"" } ``` Sign the balance data: ```go balanceData := BalanceData{Balance:"1000000"} //mock result //1. Marshal json into bytes dataToSign ,err:= json.Marshal(balanceData) if err != nil{ c.JSON(http.StatusInternalServerError,gin.H{"error":err.Error()}) return } //2. Sign the bytes with your DID using the wallet sig, err := didsdk.SignData(dataToSign) if err != nil { c.JSON(http.StatusInternalServerError,gin.H{"error":err.Error()}) return } //3. Combine the data and signature dataWithSig := RespData{ Data: balanceData, Sig: hex.EncodeToString(sig), } ``` ## Encrypt Requested Data To ensure that only the MP can access the datasets, you need to encrypt the datasets passed in response messages using the public key associated to the MP's DID. The Orange system does not decrypt or store datasets. ```go if requestJson.Encrypt { //1. Marshal json into bytes databytes, err := json.Marshal(dataWithSig) if err != nil { c.JSON(http.StatusInternalServerError,gin.H{"error":err.Error()}) return } //2. Encrypt bytes using MP DID enctrypted, err := didsdk.EncryptDataWithDID(databytes, requestJson.UserDID) if err != nil { c.JSON(http.StatusInternalServerError,gin.H{"error":err.Error()}) return } //3. Encode the encrypted data to Hex string enhex := hex.EncodeToString(enctrypted) c.JSON(200, gin.H{ "provider_did":selfDID, "data": nil, "encrypted":enhex, }) }else{ c.JSON(200, gin.H{ "provider_did":selfDID, "data": dataWithSig, "encrypted":nil, }) } ``` After the signing and encryption, the response message is ready for sending to the MP. You can read about how an MP works in the next section. # Become a Model Provider Setting up an MP service {% hint style="info" %} Please refer to [Go ](https://github.com/orange-protocol/orange-ap-sample)and [Java ](https://github.com/orange-protocol/orange-java-ap-example)code samples from respective links. {% endhint %} ## Prerequisites ### ONT ID Each Model Provider must have a unique decentralized identifier (DID) to decrypt the data included in request messages. At present, it must be an ONT ID. You can get one by creating a wallet using [ONTO app](https://onto.app/en/download/?mode=app). > You can use one and the same DID to set up a DP and an MP. ### Orange Provider SDK An SDK in [Go](https://github.com/orange-protocol/orange-provider-go-sdk) or [Java ](https://github.com/orange-protocol/orange-provider-java-sdk)is needed for signature and data encryption. Below instructions are illustrated in Go. ### Wallet You need to include a wallet file in the local directory of your project for decryption and signature. ## Design Models and Build Methods {% hint style="info" %} Usually one model works with one dedicated dataset, so you need to design the model based on your dataset. Or, you can also choose to design and publish your model on the Orange platform and offer a bounty to attract a DP. {% endhint %} Models define the way data is used to determine the reputation for a user. You can create and customize models to define the operations that are performed on the data and the weightage that is assigned to data. One MP can provide multiple models to Orange users. Every model must have an associated method. A method is an abstract definition or reference to a model that is useful when querying and fetching data. Each method needs to have a name and a parameter (dataset) associated with it. * The name is used to refer to a particular method * The parameter schema defines the useful data that needs to be passed as input to calculate reputation scores using the model pertaining to the particular method ## Create Interfaces for Model Access **MPs** need to set up an externally accessible interface with specific endpoints that can be used to fetch models. These endpoints will be called when model requests are made to the Orange system. The endpoint design depends on the design of the associated dataset, so only **RESTful** API is supported. ### **Request** Requests should be made with parameters of the following in JSON: ```json { "provider_did":"", "data":, "encrypted":"" } ```
ParameterDescription
provider_didDID of DP
dataData acquired from DP for calculation using the model. Usually it's empty in the production environment due to security concerns, only used in a debug environment.
encryptedHex string of data encrypted by DP using public key of MP's DID
### **Response** The response should be a score in JSON representing the user's reputation: ```json { "score":number } ``` ## Publish Interface When your interface is ready to be accessed on the mainnet, you can publish it on the Orange platform for developers to discover and use it. You can do it in the [Reputation Studio](https://app.orangeprotocol.io/). **Step 1:** Click on the **"Connect Wallet"** button on the top right to connect your wallet. You can find a detailed guide [here](https://docs.orangeprotocol.io/support/reputation-studio-guide). **Step 2:** Click on the **Menu** button and select **"Management"**. Choose **"My Models"**. **Step 3:** Click on the **"Create Profile"** button and fill out the form to create your profile as an MP. **Step 4:** Click on the **"Create Model"** and fill out the information following the steps indicated on the page. Then you can either click **"Save"** to save the draft, or click **"Publish"** to submit your model for review and publication. ## Handle API Requests ### Decrypt Request Messages Since the data in the request is encrypted, you need first to decrypt the data. You need the Orange [Go SDK](https://github.com/orange-protocol/orange-provider-go-sdk) and a wallet to decrypt a request using your DID. #### Import SDK ```go import( orangeSDK "github.com/orange-protocol/orange-provider-go-sdk" orangeOnt "github.com/orange-protocol/orange-provider-go-sdk/ont" ) ``` #### Initialize SDK ```go didsdk, err := orangeOnt.NewOrangeProviderOntSdk("./wallet.dat", "123456", "TESTNET") if err != nil { panic(err) } ``` **Parameters for initialization:** * path of the wallet file * wallet password * network info: `TESTNET` or `MAINNET` #### **Example** ```go requestJson := &BalanceReq{} if err := c.ShouldBindJSON(requestJson); err != nil { c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()}) return } encryptMsg, err := hex.DecodeString(requestJson.Encrypted) if err != nil { fmt.Printf("DecodeString encryptMsg failed:%s\n", err.Error()) c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()}) return } // Decrypt the message with SDK decryptedbts, err := didsdk.DecryptData(encryptMsg) if err != nil { fmt.Printf("DecryptMsg failed:%s\n", err.Error()) c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()}) return } ``` ### Verify DP Signature After decryption, you'll get the data and the DP's signature to the data. To verify the authenticity of data, you need to verify DP's signature: ```go //1. Convert json to bytes msgbytes, err := json.Marshal(dataWithSig.Data) if err != nil { fmt.Printf("Marshal msgbytes failed:%s\n", err.Error()) c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()}) return } //2. Deseriliaze signature sigbytes, err := hex.DecodeString(dataWithSig.Sig) if err != nil { fmt.Printf("DecodeString sigbytes failed:%s\n", err.Error()) c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()}) return } //3. Verify signature with SDK f, err := didsdk.VerifySig(requestJson.ProviderDID, msgbytes, sigbytes) if err != nil || !f { fmt.Printf("VerifySig failed:%s\n", err.Error()) c.JSON(http.StatusBadRequest, gin.H{"error": fmt.Errorf("invalid signature")}) return } ``` ## Generate Responses Now you can use the data to calculate a reputation score and send it back to the Orange system. # Issue Reputation NFTs {% hint style="info" %} To issue a reputation NFT, you must have already published at least one reputation calculation model and related dataset on Orange. Learn how to publish a [model](/developers/become-a-model-provider) and [dataset](/developers/become-a-data-provider). {% endhint %} **Step 1:** Navigate to the [Reputation Studio](/user-guides/reputation-studio-overview) -> Menu -> Management -> Issued NFTs. **Step 2:** Click on the "**New NFT**" button on the top right. ![](/files/UCJnaSfccSb0qK0GBNj5) **Step 3:** Select a model for your NFT. Then click on the "**Next**" button. {% hint style="info" %} The model used here must be a one you have published in the Model explorer. You don't need to select the dataset used here since the system will automatically retrive the datsaet you associated with the model. {% endhint %} ![](/files/sjNcRidRFBACGYKqSy7L) **Step 4:** Fill in NFT details. The information will be shown to users after the NFT is published on the "**NFT Collection**" page. You can refer to details of [Crypto Whale](https://app.orangeprotocol.io/nft/1) as an example. Click on the "**Publish**" button when the content is ready. {% hint style="warning" %} Once published, the details cannot be changed except the threshold score. Double check all information before you publish the NFT. {% endhint %} ![](/files/b8ZoY7ZdL4Bc8dszdGN8) **Step 5:** The team will review your submitted content soon. The status of your NFT will be changed from "Under Review" to "Published" once the review is finished, and users can claim your NFT from the "NFT Collection" Page. ![](/files/aK2ThPFrzA0P0WtOfMfY) # Get Campaign Info using API Orange provides open APIs implemented using the [GraphQL](https://graphql.org/) protocol to allow you to get campaign information. {% hint style="info" %} When sending requests, you need to include an URL, which is represented in the doc with`http:///query`. To obtain the actual URL, please contact us using [Discord](https://discord.gg/ZC7FVUDypE) or [Twitter](https://twitter.com/OrangeProtocol). {% endhint %} ## Method List | Method Name | Description | | ----------------------------------------------------------- | ------------------------------------------------------- | | [getOrangeByNFTTokenID](#1-getorangebynfttokenid) | Gets campaign details by the ID of the relevant NFT | | [getOrangeByCampaignID](#getorangebycampaignid) | Gets campaign details by the campaign ID | | [getOrangeByCampaignHostName](#getorangebycampaignhostname) | Gets campaign details by the name of the campaign owner | ### getOrangeByNFTTokenID Gets campaign details by the ID of the relevant NFT. #### Parameters
NameTypeDescription
tokenIDIntNFT token ID
chainStringchain name (e.g. eth, polygon, bsc)
#### Returns ``` type GetOrangeByNFTTokenIDResp{ campaignInfo:OrangeCampaignItem! nftInfos:NFTINfo! claimTime:Int! owner:Participant! } ``` {% hint style="info" %} To view the full list of variables, please refer to [Structure of Data in Returns](#structure-of-data-in-returns). {% endhint %} **GraphQL Schema** ``` query{ getOrangeByNFTTokenID(tokenID:53,chain:"polygon"){ campaignInfo{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime,tasks{taskTitle,isReputationTask,reputationItem{DatasetName, DatasetProvider,DatasetDescription,DatasetTotalUses,DatasetCreateTime,DatasetStatus, Datasources,ModelName,ModelProvider,ModelDescription,ModelTotalUses,ModelCreateTime, ModelStatus,ModelType,ModelLowestScore,ModelHighestScore,EligibleLevelToClaim }}}, nftInfos{chain,nftContractAddress}, claimTime, owner{walletAddress,did} } } ``` #### Examples **Golang** ``` package main import ( "fmt" "strings" "net/http" "io/ioutil" ) func main() { url := "http:///query" method := "POST" payload := strings.NewReader("{\"query\":\"query{\\n getOrangeByNFTTokenID(tokenID:53,chain:\\\"polygon\\\"){\\n campaignInfo{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime,tasks{taskTitle,isReputationTask,reputationItem{DatasetName,\\n DatasetProvider,DatasetDescription,DatasetTotalUses,DatasetCreateTime,DatasetStatus,\\n Datasources,ModelName,ModelProvider,ModelDescription,ModelTotalUses,ModelCreateTime,\\n ModelStatus,ModelType,ModelLowestScore,ModelHighestScore,EligibleLevelToClaim\\n }}},\\n nftInfos{chain,nftContractAddress},\\n claimTime,\\n owner{walletAddress,did}\\n }\\n}\",\"variables\":{}}") client := &http.Client { } req, err := http.NewRequest(method, url, payload) if err != nil { fmt.Println(err) return } req.Header.Add("Content-Type", "application/json") res, err := client.Do(req) if err != nil { fmt.Println(err) return } defer res.Body.Close() body, err := ioutil.ReadAll(res.Body) if err != nil { fmt.Println(err) return } fmt.Println(string(body)) } ``` **Java** ``` OkHttpClient client = new OkHttpClient().newBuilder() .build(); MediaType mediaType = MediaType.parse("application/json"); RequestBody body = RequestBody.create(mediaType, "{\"query\":\"query{\\n getOrangeByNFTTokenID(tokenID:53,chain:\\\"polygon\\\"){\\n campaignInfo{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime,tasks{taskTitle,isReputationTask,reputationItem{DatasetName,\\n DatasetProvider,DatasetDescription,DatasetTotalUses,DatasetCreateTime,DatasetStatus,\\n Datasources,ModelName,ModelProvider,ModelDescription,ModelTotalUses,ModelCreateTime,\\n ModelStatus,ModelType,ModelLowestScore,ModelHighestScore,EligibleLevelToClaim\\n }}},\\n nftInfos{chain,nftContractAddress},\\n claimTime,\\n owner{walletAddress,did}\\n }\\n}\",\"variables\":{}}"); Request request = new Request.Builder() .url("http:///query") .method("POST", body) .addHeader("Content-Type", "application/json") .build(); Response response = client.newCall(request).execute(); ``` **JavaScript** ```javascript var myHeaders = new Headers(); myHeaders.append("Content-Type", "application/json"); var graphql = JSON.stringify({ query: "query{\n getOrangeByNFTTokenID(tokenID:53,chain:\"polygon\"){\n campaignInfo{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime,tasks{taskTitle,isReputationTask,reputationItem{DatasetName,\n DatasetProvider,DatasetDescription,DatasetTotalUses,DatasetCreateTime,DatasetStatus,\n Datasources,ModelName,ModelProvider,ModelDescription,ModelTotalUses,ModelCreateTime,\n ModelStatus,ModelType,ModelLowestScore,ModelHighestScore,EligibleLevelToClaim\n }}},\n nftInfos{chain,nftContractAddress},\n claimTime,\n owner{walletAddress,did}\n }\n}", variables: {} }) var requestOptions = { method: 'POST', headers: myHeaders, body: graphql, redirect: 'follow' }; fetch("http:///query", requestOptions) .then(response => response.text()) .then(result => console.log(result)) .catch(error => console.log('error', error)); ``` ### getOrangeByCampaignID Gets campaign details by the campaign ID. #### Parameters | Name | Type | Description | | ---------- | ---- | ----------- | | campaignID | Int | campaign ID | #### Returns ``` type GetOrangeByCampaignIDResp{ campaignInfo:OrangeCampaignItem! participants:[Participants!]! nftInfos:[NFTINfo!]! } ``` {% hint style="info" %} To view the full list of variables, please refer to [Structure of Data in Returns](#structure-of-data-in-returns). {% endhint %} #### GraphQL **Schema** ``` query{ getOrangeByCampaignID(campaignID:52){ campaignInfo{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime,tasks{taskTitle,isReputationTask,reputationItem{DatasetName, DatasetProvider,DatasetDescription,DatasetTotalUses,DatasetCreateTime,DatasetStatus, Datasources,ModelName,ModelProvider,ModelDescription,ModelTotalUses,ModelCreateTime, ModelStatus,ModelType,ModelLowestScore,ModelHighestScore,EligibleLevelToClaim }}}, participants{chain,totalNumber,details{walletAddress,did}}, nftInfos{chain,nftContractAddress} } } ``` #### Examples **Golong** ```go package main import ( "fmt" "strings" "net/http" "io/ioutil" ) func main() { url := "http:///query" method := "POST" payload := strings.NewReader("{\"query\":\"query{\\n getOrangeByCampaignID(campaignID:52){\\n campaignInfo{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime,tasks{taskTitle,isReputationTask,reputationItem{DatasetName,\\n DatasetProvider,DatasetDescription,DatasetTotalUses,DatasetCreateTime,DatasetStatus,\\n Datasources,ModelName,ModelProvider,ModelDescription,ModelTotalUses,ModelCreateTime,\\n ModelStatus,ModelType,ModelLowestScore,ModelHighestScore,EligibleLevelToClaim\\n }}},\\n participants{chain,totalNumber,details{walletAddress,did}},\\n nftInfos{chain,nftContractAddress}\\n }\\n}\",\"variables\":{}}") client := &http.Client { } req, err := http.NewRequest(method, url, payload) if err != nil { fmt.Println(err) return } req.Header.Add("Content-Type", "application/json") res, err := client.Do(req) if err != nil { fmt.Println(err) return } defer res.Body.Close() body, err := ioutil.ReadAll(res.Body) if err != nil { fmt.Println(err) return } fmt.Println(string(body)) } ``` #### Java ```java OkHttpClient client = new OkHttpClient().newBuilder() .build(); MediaType mediaType = MediaType.parse("application/json"); RequestBody body = RequestBody.create(mediaType, "{\"query\":\"query{\\n getOrangeByCampaignID(campaignID:52){\\n campaignInfo{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime,tasks{taskTitle,isReputationTask,reputationItem{DatasetName,\\n DatasetProvider,DatasetDescription,DatasetTotalUses,DatasetCreateTime,DatasetStatus,\\n Datasources,ModelName,ModelProvider,ModelDescription,ModelTotalUses,ModelCreateTime,\\n ModelStatus,ModelType,ModelLowestScore,ModelHighestScore,EligibleLevelToClaim\\n }}},\\n participants{chain,totalNumber,details{walletAddress,did}},\\n nftInfos{chain,nftContractAddress}\\n }\\n}\",\"variables\":{}}"); Request request = new Request.Builder() .url("http:///query") .method("POST", body) .addHeader("Content-Type", "application/json") .build(); Response response = client.newCall(request).execute(); ``` **JavaScript** ```javascript var myHeaders = new Headers(); myHeaders.append("Content-Type", "application/json"); var graphql = JSON.stringify({ query: "query{\n getOrangeByCampaignID(campaignID:52){\n campaignInfo{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime,tasks{taskTitle,isReputationTask,reputationItem{DatasetName,\n DatasetProvider,DatasetDescription,DatasetTotalUses,DatasetCreateTime,DatasetStatus,\n Datasources,ModelName,ModelProvider,ModelDescription,ModelTotalUses,ModelCreateTime,\n ModelStatus,ModelType,ModelLowestScore,ModelHighestScore,EligibleLevelToClaim\n }}},\n participants{chain,totalNumber,details{walletAddress,did}},\n nftInfos{chain,nftContractAddress}\n }\n}", variables: {} }) var requestOptions = { method: 'POST', headers: myHeaders, body: graphql, redirect: 'follow' }; fetch("http:///query", requestOptions) .then(response => response.text()) .then(result => console.log(result)) .catch(error => console.log('error', error)); ``` ### getOrangeByCampaignHostName Gets campaign details by the name of the campaign owner. #### Parameters | Name | Type | Description | | ---- | ------ | ------------------------- | | name | String | name of the campaign host | #### Returns ``` type GetOrangeByCampaignHostNameResp{ campaignInfos:[OrangeCampaignItem!]! } ``` {% hint style="info" %} To view the full list of variables, please refer to [Structure of Data in Returns](#structure-of-data-in-returns). {% endhint %} #### GraphQL **Schema** ``` query{ getOrangeByCampaignHostName(name:"Dework"){ campaignInfos{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime} } } ``` #### Examples **Golong** ```go package main import ( "fmt" "strings" "net/http" "io/ioutil" ) func main() { url := "http:///query" method := "POST" payload := strings.NewReader("{\"query\":\"query{\\n getOrangeByCampaignHostName(name:\\\"Dework\\\"){\\n campaignInfos{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime}\\n }\\n}\",\"variables\":{}}") client := &http.Client { } req, err := http.NewRequest(method, url, payload) if err != nil { fmt.Println(err) return } req.Header.Add("Content-Type", "application/json") res, err := client.Do(req) if err != nil { fmt.Println(err) return } defer res.Body.Close() body, err := ioutil.ReadAll(res.Body) if err != nil { fmt.Println(err) return } fmt.Println(string(body)) } ``` **Java** ```java OkHttpClient client = new OkHttpClient().newBuilder() .build(); MediaType mediaType = MediaType.parse("application/json"); RequestBody body = RequestBody.create(mediaType, "{\"query\":\"query{\\n getOrangeByCampaignHostName(name:\\\"Dework\\\"){\\n campaignInfos{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime}\\n }\\n}\",\"variables\":{}}"); Request request = new Request.Builder() .url("http:///query") .method("POST", body) .addHeader("Content-Type", "application/json") .build(); Response response = client.newCall(request).execute(); ``` **JavaScript** ```javascript var myHeaders = new Headers(); myHeaders.append("Content-Type", "application/json"); var graphql = JSON.stringify({ query: "query{\n getOrangeByCampaignHostName(name:\"Dework\"){\n campaignInfos{campaignID,campaignURL,campaignName,campaignHost,campaignStartTime,campaignEndTime}\n }\n}", variables: {} }) var requestOptions = { method: 'POST', headers: myHeaders, body: graphql, redirect: 'follow' }; fetch("http:///query", requestOptions) .then(response => response.text()) .then(result => console.log(result)) .catch(error => console.log('error', error)); ``` ## Structure of Data in Returns ### CampaignItem ``` type OrangeCampaignItem{ campaignID:Int! // unique campaign ID campaignURL:String! // URL of the campaign campaignName:String! campaignHost:String! // Owner of the campaign campaignStartTime:Int! // Unix timestamp campaignEndTime:Int! // Unix timestamp tasks:[OrangeTaskItem!]! // campaign tasks } ``` ### TaskItem ``` type OrangeTaskItem{ taskTitle:String! // task title isReputationTask:Boolean! // if the task requires to invoke a reputation model reputationItem:OrangeReputation // if yes, returns task details as listed below } ``` ``` type OrangeReputation{ DatasetName:String! DatasetProvider:String! DatasetDescription:String! DatasetTotalUses:Int! DatasetCreateTime:Int! DatasetStatus:String! Datasources:String! ModelName:String! ModelProvider:String! ModelDescription:String! ModelTotalUses:Int! ModelCreateTime:Int! ModelStatus:String! ModelType:String! ModelLowestScore:Int! ModelHighestScore:Int! EligibleLevelToClaim:Int! } ``` ### Participant ``` type Participants{ chain:String! totalNumber:Int! details:[Participant!]! } ``` ``` type Participant{ walletAddress:String! // participant's wallet address did:String! // participant's DID } ``` ### NFTINfo ``` type NFTINfo{ chain:String! nftContractAddress:String! } ``` # Introduction Orange Pass Orange Pass is a Chrome extension designed to protect and authenticate users' Web2.0-related information using Zero-Knowledge Proofs, storing the proof on the blockchain or providing it to third-party services. ### Why Orange Pass In the traditional data verification and validation process, the Prover submits their information to the Verifier. The Verifier retrieves this data and collaborates with the data source to perform authentication checks. In this model, the Verifier acts as an intermediary or broker. Each party in this scenario faces unique challenges: for the Prover, there is a risk of exposing too much personal information; for the data source, despite being a trusted provider, it cannot offer personalised verification services; for the Verifier, they have access to all customers' private data with full visibility, posing significant risks of data breaches. Orange Pass is designed to solve this problem. By using Orange Pass, the Prover can securely and quickly prove to a Verifier his information on any web2 website without compromising the privacy of his data. #### Features * **Privacy Preserving:** Utilize Transport Layer Security(TLS) and Zero Knowledge Proof (ZKP) technologies to ensure users' information and actions are not exposed. * **Tamper-Proof Information**: Employ cryptographic schemes such as digital signatures and on-chain storage to ensure users' information and actions cannot be altered. * **Fast and user-friendly:** Without much interaction, users can generate proof in seconds and present it to any third party. ### System Architecture Basically three parties are involved in generating proofs: * **Prover**: Browser extension, which initiates proof on behalf of the user, such as proving that the amount of funds in a certain exchange is greater than 100 USD. * **Verifier**: The validator, which acts on behalf of the third party who wants to verify user information on a web2 website. * **Server**: The web2 service provider, which has the user's information.
Orange Pass has two different modes, MPC mode and Proxy mode. For performance reasons, the Orange Pass defaults to Proxy Mode. MPC Mode is only used in cases where certain APIs do not support proxy access. #### MPC Mode The Prover and Verifier act together as the client, performing MPC (Multi-Party Computation) calculations and communicating with the Server. The Verifier holds part of the key, allowing data verification without decrypting the data, ensuring both data privacy and verifiability. Details can be found [here](#mpc-mode). #### Proxy Mode The Prover acts as the client, communicating with the Server through the Verifier's proxy. The Verifier records all communication between the Prover and the Server but does not hold the key, so it cannot decrypt the communication data. Details can be found [here](#proxy-mode). ### Extension Backend
The extension backend verifies whether the attestation passes based on the schema configuration. If it passes, the attestation is signed and returned to the plugin. The extension can send the signed attestation to third-party applications or invoke a smart contract to store it on the blockchain. # MPC Mode ### Introduction The **Multi-Party Computation (MPC)** in this project is primarily used to enable secure collaboration between the **Prover** and the **Notary** for encryption and decryption operations in a TLS connection, ensuring data privacy and verifiability.
1. The Prover requests data from the Server via TLS while collaborating with the Verifier in a secure and privacy-preserving Multi-Party Computation (MPC) process. 2. The Prover selectively discloses data to the Verifier. 3. The Verifier validates the data.
The Verifier and Prover jointly compute the key for TLS communication with the Server. However, since the Verifier only holds a portion of the key, it cannot decrypt the ciphertext.
MPC Mode allows the Prover to selectively disclose data to the Verifier. Before sharing, the Prover can redact sensitive data to protect privacy. This capability can be combined with **Zero-Knowledge Proofs (ZKP)** (see [ZKP](/orangepass/introduction/zero-knowledge-proof)). Through ZKPs, the Prover can demonstrate specific attributes or properties of the redacted data without revealing the data itself. This enables the Verifier to confirm certain characteristics or conditions of the data without accessing its actual content. Thus, selective disclosure combined with zero-knowledge proofs provides a method to ensure data usability while preserving privacy. *** ### Attestation Generation Sequence Diagram
#### 1. TLS Session Stage * The Prover (P) initiates an MPC-TLS connection request to the Notary (N). * The Prover sends TLS handshake data to the Notary. * The Notary verifies the handshake data and records session parameters, establishing a secure foundation for subsequent operations. #### 2. Data Submission Stage * The Prover submits the **TranscriptCommitConfig** configuration to the Notary, including encoded commitments or hash ranges. * The Notary generates a **Merkle Tree Root** based on the submitted data for data integrity and consistency verification. #### 3. Attestation Generation Stage * The Notary constructs the **AttestationBody**, incorporating connection information, keys, and commitment data. * The Notary signs the attestation body with its private key, generating a **signed attestation**. * The Notary returns the signed attestation to the Prover. #### 4. Presentation Building Stage * The Prover selects the data range to disclose (sent/received data). * The Prover generates a **TranscriptProof** and combines it with an **IdentityProof**. * The Prover sends the completed **Presentation** to the Verifier. #### 5. Verification Stage * The Verifier validates the received presentation: * Verifies the signature's validity to ensure the attestation has not been tampered with. * Checks the consistency of the commitment to confirm data integrity. * Reconstructs a partial transcript (**PartialTranscript**) to complete the verification process. # Proxy Mode ### Introduction In Proxy Mode, users communicate with a target server through a browser plugin and a proxy server.
The Proxy Server establishes a "tunnel" between the browser plugin and the target server. Users communicate data through this tunnel, and the Proxy Server logs all data packets sent and received via the tunnel. Since the Proxy Server does not possess the encryption key, it cannot decrypt the communication data. After the TLS handshake is completed, the user can begin sending data to the target server. At this point, the `createRequest` method of the provider is called to generate the data and its associated redaction policy. Before data transmission, the data is validated using the same rules as the server to ensure successful claim creation. To achieve data desensitization, users must send data in a specific manner: * **TLS Key Update Method** (default, high efficiency, supports only TLS 1.3, and applies only to data sent from the user to the server): * The user sends data in segments, each encrypted with a different TLS session key. The Proxy Server only obtains partial keys, thus can only decrypt partial data. * **Zero-Knowledge Proof (ZKP)** Method (redaction, see [ZKP](/orangepass/introduction/zero-knowledge-proof)): * Using zero-knowledge proofs, the user can prove to the verifier that a specific encrypted block can be decrypted into a particular plaintext without revealing the key used for encryption. *** ### Detailed Process Flowchart
1. **Initialize Connection** * **Description**: The process begins with initializing the connection, configuring necessary communication parameters to prepare for establishing a secure communication channel. * **Output**: Proceeds to the tunnel establishment stage. 2. **Establish Tunnel** * **Description**: Based on the initialized connection, a secure communication tunnel is established to ensure the security of data transmission. * **Output**: Proceeds to the TLS handshake stage. 3. **TLS Handshake** * **Description**: The TLS protocol is used to complete the handshake process, establishing an encrypted communication channel to ensure the confidentiality and integrity of subsequent data transmission. * **Output**: Proceeds to the data transmission and redaction stage. 4. **Data Transmission and Redaction Stage** * This stage includes the following sub-steps: * **4.1 Segmented Data Encryption**: * Data is segmented and encrypted to protect its security during transmission. * **4.2 Hide Sensitive Information**: * Sensitive information is redacted or hidden to prevent unauthorized access and protect privacy. * **4.3 Use TLS Key Update or ZKP**: * TLS key update mechanisms or zero-knowledge proof techniques are used to further enhance the security and privacy of data transmission. * **Output**: Encrypted and redacted data, proceeding to the transmission record preparation stage. 5. **Prepare Transmission Record** * **Description**: A transmission record is generated, containing necessary metadata and encrypted information for subsequent verification. * **Output**: Transmission record, proceeding to the claim request submission stage. 6. **Submit Claim Request** * **Description**: The transmission record and related claim request are submitted to the verifier, triggering the verification process. * **Output**: Proceeds to the verification and signing stage. 7. **Verification and Signing Stage** * This stage includes the following sub-steps: * **7.1 Verify Tunnel Parameters**: * The communication tunnel parameters are checked to ensure the connection's security and consistency. * **7.2 Compare Transmission Record**: * The submitted transmission record is compared with expected data to confirm data integrity. * **7.3 Decrypt Data**: * Encrypted data is decrypted for further verification. * **7.4 Call Service Verification Function**: * A specific service verification function is called to check the data's validity and legitimacy. * **Output**: Verification result and signature, proceeding to the result return stage. 8. **Return Result** * **Description**: The verification result (including the signature) is returned to the requester, completing the process. * **Output**: Process ends, returning the verification result. *** ### UML Sequence Diagram
1. **Initialize Connection** * **Description**: The Client sends an `initRequest` to the Verifier to start the interaction process. * **Verifier Response**: The Verifier returns an `initResponse`, confirming initialization completion. * **Output**: Proceeds to the TLS tunnel creation stage. 2. **Create TLS Tunnel** * **Description**: The Client sends a `createTunnelRequest` to negotiate the establishment of a TLS tunnel. * **Verifier Response**: The Verifier returns a `createTunnelResponse`, confirming the tunnel creation parameters. * **Output**: Proceeds to the TLS handshake stage. 3. **TLS Handshake** * **Description**: The Client performs a TLS protocol handshake with the TLS Tunnel to establish a secure encrypted communication channel. * **TLS Tunnel Response**: The TLS Tunnel returns a handshake completion confirmation, indicating the channel is ready. * **Output**: Proceeds to the encrypted data transmission stage. 4. **Encrypted Data Transmission** * **Description**: The Client sends segmented encrypted data (`Encrypted Data (Segmented)`) through the TLS Tunnel. * **TLS Tunnel Response**: The TLS Tunnel receives the target server's response and returns it to the Client. * **Output**: Proceeds to the data generation request stage. 5. **Generate Data Request** * **Description**: The Client sends a `createRequest` to the Service Provider to generate data. * **Service Provider Response**: The Service Provider returns the generated data along with a `Redaction Policy` to guide data processing or privacy protection. * **Output**: Proceeds to the claim request submission stage. 6. **Submit Claim Request** * **Description**: The Client sends a `claimTunnelRequest` to the Verifier, including the transmission record (`Transmission Record`). * **Output**: Triggers the verification process. 7. **Verification Process** * **7.1 Verify Tunnel Parameters**: * The Verifier checks the TLS Tunnel parameters to ensure the connection's security and consistency. * **7.2 Decrypt and Compare Data**: * The Verifier decrypts the received data and compares it with the transmission record to confirm data integrity. * **7.3 Call Service Verification**: * The Verifier calls `assertValidProviderReceipt` on the Service Provider to validate the data's legitimacy. * The Service Provider returns the verification result (`Verification Result`). * **Output**: Verification result, proceeding to the result return stage. 8. **Return Result** * **Description**: The Verifier returns a `Signed Claim` or an error message to the Client based on the verification result. * **Output**: Process ends. # Zero-Knowledge Proof ### What Zero-Knowledge Proof is In cryptography, a **Zero-Knowledge Proof (ZKP)** is a protocol that allows one party (the prover) to demonstrate to another party (the verifier) the truth of a statement without disclosing any additional information beyond the fact that the statement is true. The core idea is that proving possession of certain information is straightforward by revealing it, but the challenge of ZKP lies in proving possession without disclosing any details of that information. In privacy-preserving multi-party computation (MPC) or proxy modes, ZKP is often combined with **selective disclosure (data redaction)** to safeguard user data privacy. *** ### Data Desensitization Process Data desensitization involves protecting data privacy by concealing or replacing sensitive information while maintaining the data's utility. Below is an example of the data desensitization process: 1. **Sensitive Information Replacement**: * User Alice desensitizes encrypted data containing sensitive information by replacing sensitive parts with placeholders (e.g., `*`). * Example: * Original plaintext: `Hello Alice, your balance is 2,500USD` * Redacted plaintext: `Hello *****, your balance is 2,500USD` 2. **Encrypted Data Processing**: * Suppose the encrypted ciphertext is `xyz1234567890`. * Based on the redaction positions in the plaintext, the corresponding positions in the ciphertext are replaced with an equal number of `*` characters, resulting in the redacted ciphertext: `xyz*****7890`. *** ### Generation and Verification of Zero-Knowledge Proof The following outlines the process for Alice and Bob to use ZKP to verify redacted data: 1. **Generating the ZKP**: * Alice generates a zero-knowledge proof to demonstrate that the redacted ciphertext (e.g., `xyz*****7890`) can be decrypted into content resembling `Hello *****, your balance is 2,500 USD`. * The decrypted plaintext may slightly differ from the original or redacted plaintext, which is expected. 2. **Sending the Proof**: * Alice sends the ZKP proof, the redacted ciphertext (`decryptedRedactedCiphertext`), and the redacted plaintext (`redactedPlaintext`) to Bob. 3. **Verification Process**: * Upon receiving the ZKP, Bob performs the following steps: 1. **Matching Check**: * Verifies whether the redacted ciphertext matches the redacted plaintext provided by Alice (i.e., checks if characters correspond or are `*`). 2. **Applying Redaction Rules**: * Bob applies the same redaction rules to his own copy of the ciphertext, based on the positions of `*` in the redacted plaintext. 3. **Verifying the ZKP**: * Uses Bob’s redacted ciphertext and Alice’s provided redacted ciphertext as inputs to validate the zero-knowledge proof. Through this process, Bob can confirm that Alice’s balance is 2,500 USD without learning her username or other sensitive information. *** ### Summary Zero-knowledge proofs, combined with data desensitization techniques, provide a method to verify data attributes while preserving privacy. In MPC or proxy scenarios, this approach ensures security and privacy by concealing sensitive information (e.g., usernames) and using ZKP to prove data correctness. This process is suitable for scenarios requiring high privacy protection, such as finance, healthcare, or legal applications. # Use in Orange Human Score Orange Pass has already been integrated into the Orange Human Score. Users can use Orange Pass there to prove their information on traditional web2 websites (such as exchanges like Binance) to Orange Human Score without leaking private data, thereby obtaining a higher score. Here we show you step by step how to use the Orange Pass in the Orange Human Score. To ensure a smooth experience, please follow the instructions below. Before proceeding to the next step, search for Orange Pass in the Chrome extension store and download and install it. #### STEP 1 Launch the Orange Pass extension.
#### STEP 2 Log in to Orange Human Score and select a verification that you want to generate an attestation, here using Binance as an example.
#### STEP 3 Select 'Account Ownership' and click Attest. Before this, users need to new a chrome tab, visit and log in to binance.
The browser will open a new tab and redirect to the Binance homepage. In the lower right corner of this page, you can see the entire verification progress.
The verification will be completed after a few seconds. If the conditions are met, the verification item will be marked and the corresponding score will be calculated.
Other verifications follow a similar process. ***NOTE*** 1. The Attestation contains a User Hash, which represents the user's account identifier in the third-party application (e.g., Binance). This is not the user's actual ID and cannot be reverse-engineered to reveal the real user ID. The same User Hash should correspond to only one recipient. 2. If the Attestation does not meet the corresponding schema, the verification will fail. # Developer Guides Setting up and docking a DP service Integrating the Orange Pass typically only requires calling the browser extension, verifying, and saving the attestation data returned by the extension. ## Frontend ### Main Steps To perform verification with Orange Pass, follow these steps: 1. Install the Orange Pass Chrome extension. 2. Call the methods provided by the Orange Pass extension to initiate proof. 3. Orange Pass opens the corresponding third-party page and executes the proof process. 4. The extension obtains the proof result and returns it to the page. 5. The page sends the proof result to its backend, which verifies whether the relevant data in the proof meets the requirements and updates the relevant status. 6. The frontend updates the frontend page based on the status updated by the backend. #### Installing the Orange Pass Chrome Extension To perform verification, users must first ensure that the extension is installed. You can determine whether the extension is installed by checking if the `window.orangePass` object is injected into the page. If the extension is not installed, guide the user to install it. #### Calling Methods Provided by the Orange Pass Extension to Initiate Verification The injected `window.orangePass` object contains methods to initiate verification. The relevant type definitions are as follows: ``` // Verification result interface VerifyResult { recipient: string; verifier_address: string; verifier_signature: string; data_hash: string; schema_id: string; task_id: string; user_hash: string; } // window.orangePass type definition interface OrangePass { start: (schemaId: string, recipient: string, proxyFirst?: boolean) => Promise; } ``` The parameter definitions for the start method are as follows:
ParameterDefinition
schemaIdThe schema ID of the content to verify
recipientEthereum address, indicating ownership of the proof
proxyFirstWhether to use proxy mode; optional; defaults to true
The specific usage is as follows ``` const startOrangePass = async () => { if (!window.orangePass) { // If the extension is not installed, guide to install it return; } // Execute proof and obtain the proof result const result = await window.orangePass.start( '***', '0x***', true, ); } ``` #### Orange Pass Opens the Corresponding Third-Party Page to Execute the Proof Process When the `window.orangePass.start` method is called, the proof request is sent to the Orange Pass extension. The extension will use the provided `schemaId` parameter to retrieve the specific schema configuration, which records all the data required for the proof. The core configuration parameters of the schema are as follows:
ParameterDefinitionExample
pageUrlThe page that needs to be opened for verificationhttps://www.binance.com/
apiUrlThe API endpoint that needs to be used for verificationhttps://www.binance.com/bapi/balance
responseMatchesConditions that need to be met in the API response""balance":\s*"(?.+?)""
responseRedactionsFields that need to be exposed in the API response"$.data.balance"
The core process is as follows 1. Retrieve the corresponding schema configuration using the schemaId, obtaining data such as pageUrl and apiUrl. 2. Open the third-party page at pageUrl. 3. Listen for requests to the apiUrl endpoint, using zero-knowledge proof technology to prove that the data returned by the apiUrl endpoint meets the requirements. 4. After verifying that the data returned by the apiUrl endpoint meets the requirements (e.g., Binance balance greater than 10 USDT), generate the proof. #### How to obtain the schemaId? Check all verifiable items on the Orange Pass official website and copy their schemaId. The Orange Pass official website is still under development.
schema_idschema_nameschema_description
0x11cfba7609b799ef88da1e2a98b1f204cd966084c9877449f0d0ba72777c1559binance registerBinance Account Ownership
0xc3c0ba7388eaa69bde72ce5eb12034b822b94c6778b67844df44c09ccd7e107cokex registerOKX Account Ownership
0x8f21116770efb7978bb1c4e944da0141e48eab6ef02ca565abc96f75fb59da14binance_kycBinance KYC Status
0xf2b160647a2c6fe42b5b80bb557538f3dddbfd494f89e9a5fe14acce1f8172abokex_kycOKX KYC Status
0x84705b16778a6166365b14f01cdbb3bdfac27a514c7ba7941e092dcafaf595babybit_registerBybit Account Ownership
0x86052f3dd2a49b58bba8fdb7ae3d811b1041ba904c7321b9c5d861bce6577743bybit_kyc KYCBybit KYC Status
0xe16b1529bba7c77df2623408533b2708ee93ce03df41be4b14bfdca36a79aabcgate_registerGate Account Ownership
0x98fff7fe5fa719ed76f9524dc1c1406e1a17d664f124dcef5f45c188620f3678gate_kycGate KYC Status
0x8f9587fcce9bec6eae226eb8a92b68b79e2923b30453a1c4f50032691a6d847cbinance_balance_0Binance Account balance > $0
0xed477f90ff03a79e539817028a5f417c19b3213da8e956d3f64f157a91f53610bybit_balance_0Bybit Account balance > $0
0x5d5cf2e2f64015ff992dfb381fb19090feaf5b064993b55abd2858b97647db6fgate_balance_0Gate Account balance > $0
0x4c0601d2c9fff3c7a7bbadd649c3e2b26c8ffc6ea99e11da4d3b7cf65974c31cokex_balance_0OKX Account balance > $0
0x21cfba7609b799ef88da1e2a98b1f204cd966084c9877449f0d0ba72777c1512kucoin_kycKuCoin KYC Status
#### The Extension Obtains the Proof Result and Returns It to the Page After obtaining the proof result, the extension will return the result to the page: 1. If the proof meets the requirements, the third-party verification page will automatically close, and the browser window will redirect to the page that initiated the verification. 2. If the proof does not meet the requirements or if there are other errors, the third-party verification page will not close automatically. It will display the error message on the third-party verification page while also throwing an error to the initiating verification page, which developers can catch and handle accordingly. #### The Page Sends the Proof Result to Its Backend, Which Validates Whether the Proof Data Meets the Requirements and Updates the Relevant Status Once a proof is successfully obtained, the page needs to send the proof to its backend, which will validate its validity (signature verification). For instructions on how the backend performs verification, refer to the relevant backend Markdown. The verification data sent to the backend is as follows:： ``` interface VerifyResult { recipient: string; verifier_address: string; verifier_signature: string; data_hash: string; schema_id: string; task_id: string; user_hash: string; } ``` After the verification passes (signature verification), it can be proved that the user indeed meets the requirements corresponding to this schema\_id. The core relevant field descriptions are as follows:
ParameterFunction
schema_idThe schema ID of the content to verify, e.g., Binance balance greater than 10 USDT
verifier_signatureThe signature of the result, indicating that it passed the Orange Pass verification
recipientEthereum address, indicating ownership of the proof, preventing others from using the proof
user_hashHash value of the user ID who performed the verification in the third-party application; for instance, if verifying related to Binance, it would be the hash of the Binance ID to prevent generating the proof repeatedly with the same account
The logic following the proof verification is handled by the DApp-related backend itself. For example, after verifying the Binance balance greater than 10 USDT, the backend can change the relevant verification status to true. #### The Frontend Updates Its Page Based on the Status Updated by the Backend After sending the proof to the backend and receiving full verification, the frontend can request the latest data from the backend to update the frontend page. For instance, if the user's Binance balance is greater than 10 USDT, the UI should also be updated to reflect the status of the completed certification. ## Backend The frontend will receive the Attestation data returned by Orange Notary, which can be submitted to the backend service requiring verification. The backend service is responsible for validating the Attestation's authenticity, ensuring that the signature address of the Attestation is the official address of Orange Notary's production environment. ### APIs #### Notary (MPC Mode) | Name | Path | Method | | --------------------- | ---------------------- | ------ | | Get Signing Address | /notary/signingAddress | POST | | Generate Attestation | /notary/genAttestation | POST | | Get Supported Schemas | /notary/schemas | POST | 1. **Get Signing Address** Return the signing address for the notary Path : /notary/signingAddress Method : POST Parameter : Response : ``` { "code": "", } ``` 2. **Generate Attestation** Return the attestation based on schema data Path : /notary/genAttestation Method : POST Parameter : ``` { "schema_id": "", "data": "", "reciepint": "", } ``` Response : ``` { "data": { "recipient": "", "verifier_address": "", "verifier_signature": "", "data_hash": "", "schema_id": "", "task_id": "", "user_hash": "", } } ``` 3. **Get Supported Schemas** Return the supported schemas for the notary Path : /notary/schemas Method : POST Parameter : ``` { "conditions":{ "wheres":[ // remove this if you want to return all schemas { "field_name":"schema_id", "field_op":"eq", "field_value":"" } ], "orders":[ { "field_name":"schema_id", "order":"desc" } ] } } ``` Response : ``` { "data":[ { "ID":, "SchemaName":"", "NSchema":"" , "SchemaID":"", "Category":"", "Owner":"", "CreatedTime":"", } ] } ``` #### Proxy (Proxy Mode) | Name | Path | Method | | -------------------- | --------------------- | ------ | | Get Signing Address | /proxy/signingAddress | POST | | Generate Attestation | /proxy/genAttestation | POST | 1. **Get Signing Address** Return the signing address for the notary Path : /proxy/signingAddress Method : POST Parameter : Response : ``` { "code": "", } ``` 2. **Generate Attestation** Return the attestation based on schema data Path : /proxy/genAttestation Method : POST Parameter : ``` { "schema_id": "", "data": "", "reciepint": "", } ``` Response : ``` { "data": { "recipient": "", "verifier_address": "", "verifier_signature": "", "data_hash": "", "schema_id": "", "task_id": "", "user_hash": "", } } ``` #### 1. Golang example 1. Calculate the hash of the attestation ``` type Attestation struct { Recipient string `json:"recipient"` VerifierAddress string `json:"verifier_address"` DataHash string `json:"data_hash"` SchemaID string `json:"schema_id"` TaskID string `json:"task_id"` UHash string `json:"user_hash"` } func GetAttestationHash(attestation *Attestation) ([]byte, error) { taskBytes, err := hexutil.Decode(attestation.TaskID) if err != nil { return nil, err } uhashBytes, err := hexutil.Decode(attestation.UHash) if err != nil { return nil, err } siBytes, err := hexutil.Decode(attestation.SchemaID) if err != nil { return nil, err } dhBytes, err := hexutil.Decode(attestation.DataHash) if err != nil { return nil, err } atHash := crypto.Keccak256Hash( taskBytes, uhashBytes, siBytes, common.LeftPadBytes(common.HexToAddress(attestation.Recipient).Bytes(), 32), dhBytes, common.LeftPadBytes(common.HexToAddress(attestation.VerifierAddress).Bytes(), 32), ).Bytes() return atHash, nil } //verify the signature for message func ETHVerifyNotarySig(from, sigHex string, msg []byte) bool { fromAddr := ethcomm.HexToAddress(from) sig := hexutil.MustDecode(sigHex) if len(sig) < 64 { return false } // https://github.com/ethereum/go-ethereum/blob/55599ee95d4151a2502465e0afc7c47bd1acba77/internal/ethapi/api.go#L442 if sig[64] != 27 && sig[64] != 28 { return false } sig[64] -= 27 pubKey, err := crypto.SigToPub(msg, sig) if err != nil { return false } recoveredAddr := crypto.PubkeyToAddress(*pubKey) return strings.EqualFold(fromAddr.Hex(), recoveredAddr.Hex()) } ``` #### 2. Verify by smart contract 1. We also provide a smart contract for attestation verification. For Binance Smart Chain testnet, the contract address can be found in the [explorer](https://docs.ivymaker.io/user-guides/create-and-migrate).
the parameter format should be: ``` ["","","","","","",""] ```
# Private Policy **Effective Date: July 10, 2025** At Orange Protocol, we are committed to safeguarding your privacy. This Privacy Policy outlines how we handle information related to your use of Orange Pass through our website, app.orangeprotocol.io (the “Site”). ### Data Collection We do not collect or store any personal data of our users on our servers. All cryptographic proofs and keys related to your on-chain reputation are generated locally on your device and remain under your control. However, we may collect certain non-personal information automatically when you access our Site, such as: * Your IP address * Browser type * Operating system * Device information This information is used solely to enhance our services and understand Site usage. Since we do not collect any personal data, we do not use such information for any purpose. The non-personal information we automatically collect is used exclusively to: * Analyze and improve our Site * Enhance our services ### Cookies Upon your first visit to Orange, a cookie is sent to your computer that uniquely identifies your browser. A “cookie” is a small file containing a string of characters that is sent to your computer when you visit a website. We use cookies to improve the quality of our service and to better understand how people interact with us. Orange does this by storing user preferences in cookies and by tracking user trends and patterns of how people search. Most browsers are initially set up to accept cookies. You can reset your browser to refuse all cookies or to indicate when a cookie is being sent. However, some Orange features or services may not function properly without cookies. ### Information Sharing As we do not collect any personal data, we do not share such information with: * Third-party service providers * Affiliates * Business partners ### Security We implement reasonable security measures to protect the information related to your use of Orange Protocol, including: * Ensuring the security of our Site * Providing guidance on best practices for users to safeguard their cryptographic keys and proofs * Employing technical and organizational measures to protect the non-personal information we collect ### Changes to this Policy Please note that this Privacy Policy will change from time to time. We expect most such changes to be minor, but there may be changes that are more significant. Regardless, we will post those changes on this page and, if the changes are significant, we will also provide a more prominent notice. Each version will be noted at the top of the page. Prior versions of this Privacy Policy will be kept in an archive for you to view. ### Contact Us If you have any questions or concerns about this Privacy Policy, please contact us at . # Reputation Studio Overview Create and manage your reputation, datasets and models The Reputation Studio is an interface for reputation owners and data/model providers to interact with the Orange protocol. Reputation owners can create reputation credentials and mint reputation NFTs based on the on-chain behaviors of the wallet addresses linked to their accounts, as well as off-chain information associated with their DIDs such as verified Web2 service accounts. Data/model providers can use the Reputation Studio to publish models and datasets in the Model Explorer, and issue reputation NFTs based on the models and datasets provided. This guide introduces the sign-in process and the functions of each section. ## Sign In Users need to sign in with a wallet address. Select the "**Launch App**" button on the top right corner of the orange webpage to enter the Reputation Studio. Then click on the "**SIGN IN**" and select your wallet. ![](/files/0775MN5tcamnTYjmzHtq) **MetaMask:** > Make sure you have installed [MetaMask](https://metamask.io/download/) in your browser and created / imported a wallet. Just one click on the "**Sign**" button in the window of MataMask. ![](/files/qxmR1uZrRYCoCPGkdbTv) **ONTO Wallet:** > Make sure you have installed [ONTO Wallet](https://onto.app/en/download/?mode=app) on your phone. **Step 1:** Open ONTO app, go to “**Settings**” and turn on the **Identity Mode**. Tap on the “**Scan**” button on the bottom to scan the code provided by Orange. ![](/files/JQGnjvukJnJE68vs9uML) **Step 2:** Confirm you ONT ID and enter the password using ONTO. Then authorize any required credential and finish the sign in process. ![](/files/FujJqL7VKnRdtear9MEE) ## Campaigns Orange NFTs are collectibles issued by Orange as souvenirs of your reputation achievements. Here you can claim NFTs issued by Orange when your reputation meets their respective requirements. Please find a detailed guide [here](/user-guides/claim-orange-nfts). ![](https://lh6.googleusercontent.com/NLUcCtk4Aot78iWlwexlh1yf-yhKp4i8OTrQFNmwjkLu0NtR3VO8wW4G-vwRcaZw9-oSyr7tqUWHh-t66A0qizIbeFvackMD9ao6K-d2ALwbeH__NZc_yj73SRZw3zvZGuDqccZ0-8OMuZUYgF1dhU0) ## Model Explorer You can browse all public datasets and models here, and select a datset & model pair to generate reputation credentials for different purposes. ![](https://lh3.googleusercontent.com/Bh6a67mq591-3J9NDPPQzITFVmjqQKF3c4Za7NtmpXXkLPtoz7kY-7XwTp6x2Qj68uLMexvUDj-bKAj91aQIDYvONNorg2PK1cc_suk-z3-tHrvTsE_nNzmwldsG8pSAbtHQRTp1aOKVvnfzcY645CM) ![](https://lh3.googleusercontent.com/1xoRfSmUv7N4rabUUH0MKQ6m9U_F9B2Fm8nvJ-qBpfLx-4p4RgwfN-n9j5SMhITVOzKIs3nMJnsyeTCVlY5JaNhOPTCjacry-TbAIGLgdw8kyoT2IkVvfdO3YDipNPbCxCc7hj7bOBQK622zyu-X7T0) ## My Reputation To access this section, select "**My Reputation**" in the drop-down menu on the top right corner of the page. ![](https://lh4.googleusercontent.com/fpd7BMw6tSUFAHSFWUY2D_yMhAjBL_Z854LAalzSRg0SYb8s5V29ciHqh3093RytYqAKfTKfHCVyNfvCpYB_Nl3RG7ZLRRK9QXkdLvSUg6t5S1zc2dUnQuIsXrT1zRE5bw5-9WB2UoSyMhjgDefPE-k) ### My Credentials Credentials contain reputation assessment results. You can share them with dApps and services to prove certain eligibility. To create a new credential, first click on the “**Generate Reputation**” button at the top right. Then choose a model, a dataset and a wallet. Click “**Proceed**” to submit the request and click **“Generate Reputation**” to confirm the choice. After a few minutes you will be able to check the result in the “**My Credentials**”. {% hint style="info" %} Before you can generate a reputation credential, you need to **add at least one wallet** to your Orange account. Please read about how to do it [here](#wallets). {% endhint %} ![](https://lh5.googleusercontent.com/bVz3wjpjgjQP5x9BRzVxQW04K6adn_u3OIlwPpg9xKzbEYBPzojzPNTrlL1yRZkfKRp0AkJwIxt7WDZbRpRsdxBcqbJeaFIZQBsEXcerQRJVwH08Ql6OJ0IfD1Um9D72Kz8MqgUR-nfMpj-cgjq-7qI) ### My NFTs Here you can view the Web3 Citizen, NFT Collector and Crypto Whale NFTs you claimed from the "**Campaigns**”. ![](/files/YzjWe1TMf5B4jYNnknBx) ## My Campaigns To access this section, select "**My Campaigns**" in the drop-down menu on the top right corner of the page. ![](https://lh3.googleusercontent.com/4WofijXbn_utc1CJC_4p8RimvnqHMdgF9xE1RMGAUcD0YObjWn6Ynyt_L-6gyiGQqN0DIs-rz2SuCrDzaMPbjgEvgj_nvFUFtGNdVTCO_gsdVI2j-oMkfRdc58SOh0P_IxgH-lRvKlUHBFl2HMB49Y0) ### Claimed NFT Here you can view the campaign NFTs you claimed from the "**Campaigns**" page. ![](/files/X2PF5qwxu2Zn25lJ744Y) ### Campaign in process Here you can view the campaign you are in process from the "**Campaigns**" page. ![](https://lh6.googleusercontent.com/FBUNPMwcbJO3ewiBIuBLn-64RcU-9eHTfXDbgFQUHOyOlDILGIllJU78YToIQQkqI7H11qbUkFzLy0FApGyO0MufJRmKETWCKMne58Xp1MBLsoaRp0pSnXop-H_nd79_FJs_BCkjnDJrUvb2FoT9Mac) ### Joined Whitelist Here you can view the campaign you are in the whitelist from the "**Campaigns**" page. ![](https://lh3.googleusercontent.com/enO7yKk59vtNsq1xkUJiREFQHb82VMJCm65Dn4SzV-z6Vnqm_LWRF8Hdwxc5lstnozTePkumE_AIVkR21y5PqcCC1GOuNcmkz0y0jSgskb8KJzvLCfINKRVFhg4qLd2e290BA5B9BKXZi2yG06dJlYM) ## Management To access this section, select "**Management**" in the drop-down menu on the top right corner of the page. ![](https://lh5.googleusercontent.com/7hAiwlgOCMFOmAFe2aIH-VxT62R-ZUPj_7tuaTRtY_VZ3teWTQWdukERbnR_ywRCeoNPwxOdJCU4q_pZ0wAw5j5-sa4x3DLhcqxhCuPi77fGc9jwhwli9clKGyW9IMXzrr-4Bhdng8kwqOEenek3U3U) ### Wallets Since reputation is generated based on the data associated with wallet addresses, you need to add at least one wallet here. You can add a new wallet address (only via [MetaMask](https://metamask.io/download/) for now) by clicking "**+ Add Wallet**" and proceed according to prompts on the page. You can control whether a particular address is taken into account when generating reputation by switching on and off the "**Visible**" toggle. ![](https://lh6.googleusercontent.com/rXouNDip0mG780kqpkAJu2M_vN8mfCJ7dfywtTCTEySiwNPQ-4qmvTMCQCvVGKDXgQQPEyHTU91LBUs5ctKKMQxptQ0B75-bKrP5ssmMKLz3VkKLFLOlHb6s5RBpIKOAI4Xh-doj0ROXHtGpXX2yRAs) ### Verification Here you can link accounts of other platforms to your Orange account and authorize Orange to access relevant data for reputation generation. ![](https://lh6.googleusercontent.com/ewVV-WFkr5yBNxERIL_V-4tHpYAqigZEcVHCyrKkjDgBME20zcoKdlPEjh34cqD-tOQ1tnJJ4p-7N6j9mOaSBWiS78ATxknxjH1LmlvOUJhBrpvEO8ZTAh1k_ObZleAU5WxDvncOjLShb20m9D2ZGOg) ### My Models Developers can apply to publish their models on the Orange platform here. Please read the detailed [guide](/developers/become-a-model-provider). ![](https://lh5.googleusercontent.com/_8cWbsbW7FsTuyYvKC6Ni5yIa-8SOuCOy9NQVLY4obqjW37VxlhfNtfY4syEejf08sNMC7KmERwmp4mDf4udfhT1pBIsCnmwBUw_8ksvo4GbY8SX2-S26pmi10CtSg6VaQKIXieb9Zq1ijJ-5SKRq_4) ### My Datasets Developers can apply to publish their models on the Orange platform here. Please read the detailed [guide](/developers/become-a-data-provider). ![](https://lh3.googleusercontent.com/dQLOpe9RAMrmy50asmyLNGCAAdYvOCWpEOE6mh1HYSutZ5SNnZEg1XSm45Et35CJUUo11JjqM_Mj9yEvbMQBAxdlngDMaRB-K2HDG84WSKZBhRsrOeOmRS_Kdwst8KO81zTZ6EPneBJd3LgWgMMmtOw) ### Issued NFTs Developers can check issued NFTs based on their published models. ![](https://lh3.googleusercontent.com/nkqKtGVSxyDZKgeGD1UMkjtEEP0fBRkuxdi_wVqeJq70P7OzGNINarmx33wIKR2NJ36T0OiKMQMUaW_mKIJvEOuRs_uGxLYRS4bThAuCRNOh-BY-yo_9_b5RX43UK1KuOJesAp4D9TedvHCY6BKjBn4) # Claim Orange NFTs Orange NFTs are collectibles issued by Orange as portable proofs of your reputation achievements. {% hint style="info" %} Before you can follow this guide to claim an Orange NFT, you need to [sign in](/user-guides/reputation-studio-overview#sign-in) and[ add a wallet](/user-guides/reputation-studio-overview#wallets) to the Orange platform. {% endhint %} **Step 1:** Select the "**Campaigns**" on the top of the page to view available campaigns. Click on the campaign you are interested in to check the specific details and task requirements. Here we take the "CRYPTO WHALE" as an example. ![](https://lh6.googleusercontent.com/NLUcCtk4Aot78iWlwexlh1yf-yhKp4i8OTrQFNmwjkLu0NtR3VO8wW4G-vwRcaZw9-oSyr7tqUWHh-t66A0qizIbeFvackMD9ao6K-d2ALwbeH__NZc_yj73SRZw3zvZGuDqccZ0-8OMuZUYgF1dhU0) **Step 2:** Read "Who Is Eligible" to find out which reputation credential you need to generate before claiming the NFT, and the minimum required reputation score. ![](https://lh6.googleusercontent.com/jmagl6w4aYpo5Oif4LMgna4MgjBVEYaaIU08IWG07bTUicuwjzzWmlgiJWYI0YLecUHgMAsjNhQRDwg7NI0upJnBDJdDQGxhIzWFy3V28nIne70BS1lpDDFiVFff4eKDAnGuq-s39TZj4fppWkmNUKM) **Step 3:** Join the campaign to check the steps of the required tasks. ![](https://lh3.googleusercontent.com/raLMKoDeaBVc4E93BSFsOqG07n8TCHaVdr76h26gg0G4VI4MxuBei0D4YAScPFOtUXxiPVK4ShmnbLbpo5GXQ_PUfhcWksTY6Qm5Bf2eJrYhWrzv5Ytz2w0ifEts5AiIBGIbbXiPbNRzouKpn5t0q1g) **Step 4:** Follow the task guidelines to accomplish all the required tasks. ![](https://lh6.googleusercontent.com/5E6-4HhwKCvT01SoiGFHwggB1V-O0jUuss0X-gG12_RCuGzGW5iC49QksPoxMCmHM48XnfJnjP-yBGDxzSsSgjhQyQxdSmJoBC0T1u-WKXFSv5xdHSjAl1vXo9-FfcNuiVvjsAgU-pdqbraawQ1dCi4) **Step 5:** Click “**Claim**”, select a network that you would like to mint the NFT and switch to the corresponding wallet in the MetaMask plugin, then click “**Claim**” again to confirm the mint. Click "**Confirm**" in the window of MetaMask wallet plugin. Hooray! The NFT is minted. You can find it from **My Reputation - My NFTs** and/or **My Campaigns - Claimed NFT.** (Web3 Citizen, NFT Collector and Crypto Whale will be displayed in “**My NFTs**”, other NFTs will be displayed in “**Claimed NFT**”.) ![](https://lh4.googleusercontent.com/9k1GMz7hU7uw4ZxPURvu8VfWOsNx4_PloJstkA1ib82i2fcjyoGilfLa5hSUo3WNp19NNWZ6X_BFz3ZW-SOJXtZC5WCB1cRGf4IiBOWeoKKTV8pMmNMyQpascM5qK1r3zu_Ggrmy65AvEbyXVsBum2E) ![](/files/1yXuEb0jXqguwnWCNre8) ![](/files/LjjIS6kWkJLWMiZTTaNO) # OScore **OScore** is an on-chain credit score for programmable creditworthiness which is designed based on the Orange protocol. Its workflow illustrates how an **MP** and a **DP** work together in the Orange system. ## OScore Model OScore can represent one's credit standing in DeFi systems. It is calculated using many different pieces of transaction data, including: * Payment history * Liquidation history * Amounts owed and repaid * Credit mix * Length of credit history It implements a customized model and quantification of on-chain behavior and interactions with existing DeFi protocols using Orange. This ensures the scoring methodology remains empirically sound and statistically valid. ## Data Synchronization Consider the following diagram illustrating OScore's transaction data synchronization flow from **Ethereum,** which is the **DP** in this context. ![](/files/-MhBy8v-2OiBKdezunaC) #### Geth Node * An Ethereum sync node #### ETH Sync Service * Synchronization service that listens and monitors transactions via the sync node * Stores the relevant transaction data in a database * Stores block data for contract executor to fetch #### Contract Executor * Listens to contract events via the sync node * Logs relevant event data in a database #### Database * Stores transaction and event data This data is stored in the database and fetched via an interface by the Orange system when the OScore model is invoked. Applications send invocation requests using an SDK. You can refer to the [**example here**](/developers/within-your-system#5-send-a-request-to-run-the-algorithm-with-selected-data)**.** # Reputation NFT Based Voting Mechanism Snapshot is a tool for projects to create spaces where they can conduct off-chain voting on proposals. In Snapshot, any project can apply Orange's reputation NFT based voting mechanism as the space voting strategy to democratize the voting process. Snapshot users who want to vote on a proposal using this mechanism need to claim reputation NFTs on Orange to demonstrate their voting power. ## Dataset, Model and NFT Orange supports users to generate reputation proofs in the form of verifiable credentials (VCs) and NFTs. VCs are created based on the user selected dataset and model pair, containing a reputation score. Users with scores higher than respective thresholds can claim NFTs, so their reputation can be used in more scenarios. Orange provides 3 NFTs, [Crypto Whale](https://app.orangeprotocol.io/nft/1), [NFT Collector](https://app.orangeprotocol.io/nft/2), and [Web3 Citizen](https://app.orangeprotocol.io/nft/3), that evaluate user reputation using various standards. For example, the NFT Collector is generated using datasets and model aiming to evaluate active NFT users based on their asset holdings and related actions: Datasets: * Timestamp of the user’s first NFT transaction * Number of transactions on OpenSea within 180 days * Types of ERC721 & BEP721 NFTs owned * Value of ERC721 & BEP721 NFTs owned Model: * [NFT Asset Evaluation Model](https://app.orangeprotocol.io/market/mp/did:ont:AZDsadgHuep1BnxU4XKZtAMhqBtHdxxVwz/Orange/calcNFTAsset) However, these models are for general purposes. Snapshot space owners are recommended to provide data and models to Orange and issue custom NFTs, so the accordingly generated reputation results are more tailored to their needs. {% hint style="info" %} Learn more about how to provide [data](/developers/become-a-data-provider) & [model](/developers/become-a-model-provider), and how to [issue NFTs](/developers/issue-reputation-nfts). {% endhint %} ## Use Reputation for Voting ### Claim NFT Before claiming an NFT, users first generate a VC using the associated model and dataset. The API endpoints used to fetch datasets and models are saved in the Orange system. Upon receiving a request of generating a VC, the system first invokes the model by sending a request to the model API. Next, the MP retrieves datasets from dataset APIs to complete the calculation. Now with a valid VC, users can claim an NFT. If the reputation score has been validated to have reached the required threshold, a mint transaction will be sent to the selected blockchain and the score will be stored as the NFT metadata. ### Fetch Reputation Score When a user initiates the vote action, the Snapshot server will access the reputation score stored on-chain as the NFT metadata based on the user's wallet address. This score will then be used for calculating the voting result, and be listed in the vote details. # Decentralized Collaboration Network The Orange system currently uses a centralized task dispatching mechanism when invoking models. This is an initial approach to kick start the platform and get the system running in early stages of the network. Moving into the future, the system will be revamped to establish a **collaborative network architecture** in a decentralized way. The dispatching mechanism of the calculation tasks will be implemented in the form of on-chain systems and smart contracts, thereby making the overall dispatching process completely transparent. Also, the number of data sources from which data is fetched to calculate a particular instance of reputation will also be extended to a decentralized data organization and provisioning approach. Simultaneously, the system will support a decentralized **multi-party computation model** with the results effectively being aggregated based on the models. Say for instance, statistically determining the median value of a set of numerical data points. This helps to make the calculation process and the final results more reliable. # Secure Computing Paradigm A TEE (Trusted Execution Environment) is a black box in a computer chip which protects code and data running in it from being tampered with or stolen by any external software, even privileged access software such as operating systems. At the same time, TEE provides remote verification functions, so that users can actively verify whether user behavior conforms to expectations and ensure that users do not obtain any private data while providing effective proof of work. Blockchain is essentially an open system. Anyone can query blockchain data through the public interface. Smart contracts are the carriers of blockchain applications, and the security of private data involved in smart contracts needs to be protected. Using the TEE Layer-2 privacy-preserving computation solution on the Ontology public blockchain, Orange will support a secure private smart contract execution environment, fully protecting data privacy and security during on-chain computing. # FAQs ## What role would I play in the Orange network? Every role contributes to further development of Web3 interoperability in their own way. **Model Providers** are generally platforms that have been working on reputation assessment within their systems. If that describes your system, you can join the Orange ecosystem and make your models accessible to others. **Data Providers** could be systems with data that has utility outside its native environment. Generating datasets and making them accessible via an interface to be used as input for modles is a great way to leverage the inherent cross-chain benefits of composability that blockchain brings. **dApps** are the primary players who use the public modles and datasets to generate reputation for their users. If you're working on a dApp and want to implement a decentralized reputation mechanism, you can go ahead and integrate Orange to your system using [**this SDK here**](/developers/within-your-system)**.**