diff --git a/.env.sample b/.env.sample deleted file mode 100644 index 02754bd6..00000000 --- a/.env.sample +++ /dev/null @@ -1,2 +0,0 @@ -ALGOLIA_API_KEY=213 -ALGOLIA_APP_ID=XYZ diff --git a/docs/faqs/content/verifier-on-chain-verification-gas-costs.md b/docs/faqs/content/verifier-on-chain-verification-gas-costs.md index 866e3aa3..7f1320e1 100644 --- a/docs/faqs/content/verifier-on-chain-verification-gas-costs.md +++ b/docs/faqs/content/verifier-on-chain-verification-gas-costs.md @@ -17,9 +17,16 @@ Can you explain the necessity of gas fees for on-chain verification? ## Answer -On-chain verification of zero-knowledge proofs (ZKPs) is a computationally intensive process that requires significant resources from the blockchain network. This process relies on advanced cryptographic techniques, specifically pairings cryptography, to ensure the validity and security of transactions without revealing underlying private information. +On-chain verification of zero-knowledge proofs (ZKPs) is a computationally intensive process that requires significant resources from the blockchain network. This process relies on advanced cryptographic techniques to ensure the validity and security of transactions without revealing underlying private information. -The computational complexity of these verifications is reflected in their gas costs, which serve as a payment for the computational resources consumed by the network to perform these operations. For a full verification flow, the gas costs are approximately 770k for v3 circuit proofs and around 700k for v2 circuit proofs. The verification step alone typically consumes about 500k gas. +The computational complexity of these verifications is reflected in their gas costs, which serve as a payment for the computational resources consumed by the network to perform these operations. For a full on-chain verifier flow, the gas costs are approximately **1.245 million gas**. At the current rate of 25 Gwei per Gas on Polygon, this equates to approximately **0.031125 POL** (less than one cent USD as of July 2025). + +The on-chain verification process typically consists of the following steps: + +- The **setZKPRequest** step, which takes approximately **325,000 gas** ([example transaction](https://polygonscan.com/tx/0x14f8ce081ced29317c4cb391e23c165411bb3da68498dd78d2270c65a387a969)). +- The **submitZKPResponseV2** step, which takes approximately **920,000 gas** ([example transaction](https://polygonscan.com/tx/0xf3e541bfcb8e3f0ee665e8c392ca94c5eec491ffea13cf83b42c28337ed9ea20)). + +A full history of transactions for the Universal Verifier contract on Polygon can be found [here](https://polygonscan.com/address/0xfcc86a79fcb057a8e55c6b853dff9479c3cf607c). Gas fees are a crucial component of on-chain verification processes, compensating network validators or miners for the computational power required to secure and execute these complex cryptographic operations. Without these fees, it would be challenging to incentivize the maintenance and security of blockchain networks, especially when performing specialized tasks such as ZKP verifications. diff --git a/docs/introduction.md b/docs/introduction.md index 4f36d56e..8a7b568e 100644 --- a/docs/introduction.md +++ b/docs/introduction.md @@ -20,7 +20,7 @@ Privado ID’s identity infrastructure facilitates trusted and secure relationsh ## Why Privado ID? -Privado ID, with the help of zero-knowledge proofs, lets users prove their identity without the need of exposing their private information. This ensures both the **Freedom of Expression** and **Privacy by Default** (user's identities are secured by zero-knowledge cryptography). +Privado ID, with the help of zero-knowledge proofs, lets users prove their identity without the need to expose their private information. This ensures both the **Freedom of Expression** and **Privacy by Default** (user's identities are secured by zero-knowledge cryptography). ## Core Concepts of Privado ID: Verifiable Credentials, Identity Holder, Issuer and Verifier @@ -42,7 +42,7 @@ The architecture of the framework is composed of three modules: Identity Holder, The simplest example of a Verifier is a bar that wants to verify if a client is over 18. In the real world, the Identity Holder would need to provide an ID and show all their personal information. With Privado ID, they only need to pass a proof. -A core concept here is the _trust_ that must exist between a Verifier and an Issuer: the fact that the information contained inside a VC is cryptographically verifiable doesn't guarantee it's true. The Issuer must be a trusted and reputable party so that Verifier can consume the VCs originated by that Issuer. +A core concept here is the _trust_ that must exist between a Verifier and an Issuer: the fact that the information contained inside a VC is cryptographically verifiable doesn't guarantee that it is true. The Issuer must be a trusted and reputable party so that Verifier can consume the VCs originated by that Issuer.
@@ -50,11 +50,11 @@ A core concept here is the _trust_ that must exist between a Verifier and an Iss ## Role of a Wallet -A [Wallet](./wallet/wallet-overview.md) plays a crucial role in the seamless exchange of VCs with the Issuer, on one hand, and proofs with the Verifier, on the other. As stated above, an Identity Holder carries their personal data, in the form of VC, within their wallet. At its core, the wallet stores the private key of a user, fetch VCs from the Issuer, and create zero-knowledge proofs to be presented to the Verifier. Being the carrier of the sensitive information, the Wallet has been designed to ensure that the identity of its Holder is protected and preserved, and no sensitive data can be revealed to the third party without the consent of the Holder. +A [Wallet](./wallet/wallet-overview.md) plays a crucial role in the seamless exchange of VCs with the Issuer, on one hand, and proofs with the Verifier, on the other. As stated above, an Identity Holder carries their personal data, in the form of VC, within their wallet. At its core, the wallet stores the private key of a user, fetches VCs from the Issuer, and create zero-knowledge proofs to be presented to the Verifier. Being the carrier of the sensitive information, the Wallet has been designed to ensure that the identity of its Holder is protected and preserved, and no sensitive data can be revealed to the third party without the consent of the Holder. ## What Can you Achieve Using Privado ID? -1. **Privacy using Zero-Knowledge Proofs**: An Identity Holder, using zero-knowledge proofs, can keep thier personal data private. During the process of VC verification, it just needs to show a proof that they are the owner of a VC that matches certain criteria without letting the Verifier know of the actual VC. For example, an Identity Holder can prove to a Verifier authority that they are above 18 years of age by presenting the proof without revealing their actual age. This ensures minimum data exposure and hence confirms the safety of any sensitive data. +1. **Privacy using Zero-Knowledge Proofs**: An Identity Holder, using zero-knowledge proofs, can keep their personal data private. During the process of VC verification, it just needs to show a proof that they are the owner of a VC that matches certain criteria without letting the Verifier know of the actual VC. For example, an Identity Holder can prove to a Verifier authority that they are above 18 years of age by presenting the proof without revealing their actual age. This ensures minimum data exposure and hence confirms the safety of any sensitive data. Another aspect of privacy comes from the fact that the Issuer would not be able to track the usage of VCs by an individual once it has been issued. 2. **Off-Chain and On-Chain Verification**: Verification of proofs can be done either off-chain or on-chain via Smart Contracts. For example, developers can set up a contract that airdrops tokens only to users that meet certain criteria based on their VCs. diff --git a/docs/issuer-node/issuer-node-api/agent/apis.md b/docs/issuer-node/issuer-node-api/agent/apis.md index 932408c2..4b285c56 100644 --- a/docs/issuer-node/issuer-node-api/agent/apis.md +++ b/docs/issuer-node/issuer-node-api/agent/apis.md @@ -14,7 +14,7 @@ keywords: - agent --- -The agent endpoint acts as a port to communicate messages between the mobile app and the server. The user, using the agent endpoint, can access the functionality through his/her mobile app. +The agent endpoint acts as a port to communicate messages between the mobile app and the server. The user, using the agent endpoint, can access the functionality through their mobile app. The core feature of message-based communication initiation in messaging specification is the process of looking up the two main properties of each identity: @@ -26,9 +26,9 @@ The [JWZ](/docs/wallet/wallet-sdk/polygonid-sdk/iden3comm/jwz.md) is generated w ## Agent Endpoint -**Function**: endpoint to send a JWZ token from the user's mobile app. +**Function**: Endpoint to send a JWZ token from the user's mobile app. -**How it Works**: the user's app sends a JWZ token in the request body. +**How it Works**: The user's app sends a JWZ token in the request body. The Issuer Node responds by sending a response message that contains details related to Verifiable Credential and Issuer. It also includes metadata such as: @@ -36,8 +36,8 @@ The Issuer Node responds by sending a response message that contains details rel - `to`: to which Issuer's DID the message is sent. - `id`: a random UUID generated for a transaction. - `threadID`: part of the JWZ token. -- `typ`: the way of communication between protocol and mobile. -- `type`: the way of communication between protocol and mobile. +- `typ`: the way of communication between protocol and mobile. Also indicates how the message is formatted and should be processed +- `type`: the way of communication between protocol and mobile. Specifies what kind of operation or response the message represents A typical response looks like this: diff --git a/docs/issuer-node/issuer-node-api/claim/apis.md b/docs/issuer-node/issuer-node-api/claim/apis.md index 8f4493ed..e00c8aec 100644 --- a/docs/issuer-node/issuer-node-api/claim/apis.md +++ b/docs/issuer-node/issuer-node-api/claim/apis.md @@ -29,15 +29,15 @@ A credential ID is assigned to a Verifiable Credential when it is created by an ## Create Credential -**Function**: endpoint to create a Verifiable Credential for a user. +**Function**: Endpoint to create a Verifiable Credential for a user. -**How it Works**: the DID (identifier string retrieved from calling the `Create Identity` endpoint) is passed as a path variable in the request URL. This is your DID identifier that you use as an issuer of credentials. +**How it Works**: The DID (identifier string retrieved from calling the `Create Identity` endpoint) is passed as a path variable in the request URL. This is your DID identifier that you use as an issuer of credentials. The following parameters are passed in the body of the request: - `credentialSchema`: it is a template for a Verifiable Credential that guarantees the structure of a credential. This way, an Issuer, a Holder, and a Verifier can reference the data in a known way. Further details on the `credentialSchema` can be found in the [Create Custom Schema](../../../issuer/schema.md) section. - `type`: the type of the credential schema sent. -- `credentialSubject`: contains DID (Decentralized Identifier), i.e. `did`, of the user and the fields related to the data to be attested. You should have previously obtained this identifier from the user by performing a "basic auth" step, this can be done through the [Authentication/QRcode step](https://issuer-admin.polygonid.me/#get-/v1/authentication/qrcode). +- `credentialSubject`: contains DID (Decentralized Identifier), i.e. `did`, of the user and the fields related to the data to be attested. You should have previously obtained this identifier from the user by performing a "basic auth" step, this can be done through the [Authentication / QRcode step](https://issuer-admin.polygonid.me/#get-/v1/authentication/qrcode). - `expiration`: Date of expiry of the Verifiable Credential. :::note @@ -52,11 +52,11 @@ The Issuer Node responds by sending a response message that contains the string ## Get Credential -**Function**: endpoint to retrieve a Verifiable Credential based on its Credential ID (CID). This way, you can retrieve a credential issued by an Issuer based on this credential's ID. +**Function**: Endpoint to retrieve a Verifiable Credential based on its Credential ID (CID). This way, you can retrieve a credential issued by an Issuer based on this credential's ID. -**How it Works**: the DID (the identifier string retrieved from calling the `Create Identity` endpoint) and the Claim ID, i.e.`id` (or CID) of the Verifiable Credential (retrieved from calling the `Create Claim` endpoint) are passed as path variables in the request URL. +**How it Works**: The DID (the identifier string retrieved from calling the `Create Identity` endpoint) and the Claim ID, i.e.`id` (or CID) of the Verifiable Credential (retrieved from calling the `Create Claim` endpoint) are passed as path variables in the request URL. -The endpoint requires to pass the issuer `did` and the Verifiable Credential `CID` as path variables in the request URL. +The endpoint requires passing the issuer `did` and the Verifiable Credential `CID` as path variables in the request URL. The server responds by sending the following data about the Verifiable Credential: @@ -93,9 +93,9 @@ The server responds by sending the following data about the Verifiable Credentia ## Get Credentials -**Function**: endpoint to retrieve all the Verifiable Credentials issued by an Issuer. +**Function**: Endpoint to retrieve all the Verifiable Credentials issued by an Issuer. -**How it Works**: the DID (the identifier string retrieved from calling the `Create Identity` endpoint) is passed as path variables in the request URL. +**How it Works**: The DID (the identifier string retrieved from calling the `Create Identity` endpoint) is passed as path variables in the request URL. You can retrieve a set of credentials based on different filters or criteria. These criteria can be added as the query-string parameters in the request URL. These filters (and their data types) are listed below: @@ -122,9 +122,9 @@ In order to communicate with the Web Wallet or the Wallet App, the Issuer Node m ::: -**Function**: endpoint to generate a Universal Link. The user can then click this link and accept credentials to his/her wallet. +**Function**: Endpoint to generate a Universal Link. The user can then click this link and accept credentials to their wallet. -**How it Works**: the Issuer DID (identifier string retrieved from calling the `Create Identity` endpoint) and credential Identifier (or `cid` retrieved from the `Create Credential` endpoint) are passed as path variables in the request URL. +**How it Works**: The Issuer DID (identifier string retrieved from calling the `Create Identity` endpoint) and credential Identifier (or `cid` retrieved from the `Create Credential` endpoint) are passed as path variables in the request URL. The Issuer Node responds by sending a response message that contains a JSON which carries the following fields: @@ -137,9 +137,9 @@ The Issuer Node responds by sending a response message that contains a JSON whic ## Revoke Credential -**Function**: endpoint to revoke a Verifiable Credential +**Function**: Endpoint to revoke a Verifiable Credential -**How it Works**: the Issuer DID (The identifier string retrieved from calling the `Create Identity` endpoint) and `nonce` of the VC to be revoked (Revocation Nonce) are passed as a path variable in the request URL. +**How it Works**: The Issuer DID (The identifier string retrieved from calling the `Create Identity` endpoint) and `nonce` of the VC to be revoked (Revocation Nonce) are passed as a path variable in the request URL. The server responds by showing the Revocation Status of the credential. @@ -147,9 +147,9 @@ The server responds by showing the Revocation Status of the credential. ## Get Revocation Status -**Function**: endpoint to retrieve the Revocation Status of the Verifiable Credential. +**Function**: Endpoint to retrieve the Revocation Status of the Verifiable Credential. -**How it Works**: the DID (The identifier string retrieved from calling the `Create Identity` endpoint) and `nonce` (Revocation Nonce) are passed as a path variable in the request URL. For the credential to be marked "revoked", we need to publish the state first on-chain, and then wait for 5 confirmation blocks. +**How it Works**: The DID (The identifier string retrieved from calling the `Create Identity` endpoint) and `nonce` (Revocation Nonce) are passed as a path variable in the request URL. For the credential to be marked "revoked", we need to publish the state first on-chain, and then wait for 5 confirmation blocks. The server responds by sending the following details: diff --git a/docs/issuer-node/issuer-node-api/identity/apis.md b/docs/issuer-node/issuer-node-api/identity/apis.md index 103dc94b..f037e1a2 100644 --- a/docs/issuer-node/issuer-node-api/identity/apis.md +++ b/docs/issuer-node/issuer-node-api/identity/apis.md @@ -14,7 +14,7 @@ keywords: - Identity --- -The identity endpoint is used to create and retrieve identities for a user/issuer. Privado ID supports the creation of identities in the form of DIDs (Decentralized Identifiers). A user can have multiple DIDs. +The identity endpoint is used to create and retrieve identities for a user and issuer. Privado ID supports the creation of identities in the form of DIDs (Decentralized Identifiers). A user can have multiple DIDs. :::note @@ -28,7 +28,7 @@ A DID can be represented as: did: did method: did method-specific identifier. ``` -This is a standard form of expressing a Decentralised Identifier as defined by the W3C DID Core 1.0 Specifications. +This is a standard form of expressing a Decentralized Identifier as defined by the W3C DID Core 1.0 Specifications. ## Create Identity @@ -40,13 +40,13 @@ An example of a `didMetaData` passed in the request body of the `Create Identity ``` { - "didMetadata":{ - "method": "polygonid", - "blockchain":"polygon", - "network": "amoy", - "type": "BJJ" - }, - "credentialStatusType": "Iden3commRevocationStatusv1.0", + "didMetadata": { + "method": "iden3", + "blockchain": "privado", + "network": "main", + "type": "BJJ" + }, + "credentialStatusType": "Iden3ReverseSparseMerkleTreeProof" } ``` @@ -59,7 +59,10 @@ A few variations of the metadata can be: - blockchain: + - "privado" + - "billions" - "polygon" + - "linea" - "eth" - network: @@ -74,8 +77,8 @@ A few variations of the metadata can be: :::info Identity Types -As you can see above, there are two options for Identity types: Baby Jubjub and Ethereum DID. -Baby Jubjub keys are used to create regular identities, but that method can't create an identity out of an Ethereum address. Instead, users can choose the "ETH" type to use Ethereum accounts to authenticate, prove statements and control identity. It is important to note that the Ethereum address must have funds to publish its state onchain. +As you can see above, there are two options for Identity types: Baby JubJub and Ethereum DID. +Baby JubJub keys are used to create regular identities, but that method can't create an identity out of an Ethereum address. Instead, users can choose the "ETH" type to use Ethereum accounts to authenticate, prove statements and control identity. It is important to note that the Ethereum address must have funds to publish its state onchain. Read more about Identity types on [Iden3 Docs](https://docs.iden3.io/getting-started/identity/identity-types/). @@ -83,7 +86,8 @@ Read more about Identity types on [Iden3 Docs](https://docs.iden3.io/gettin The Issuer Node responds by sending a response message that contains: -- `identifier`: Identifier of the Issuer in the standard DID format. For example: `did:polygonid:polygon:amoy:2qNBWSAsyvaGBpqQVHk3E4cgChaN6ogaZnYCQUyoRQ` +- `identifier`: Identifier of the Issuer in the standard DID format. For example: +`did:iden3:privado:main:2qNBWSAsyvaGBpqQVHk3E4cgChaN6ogaZnYCQUyoRQ` - `identity state`: It is the state of the identity and contains fields that include `claimsTreeRoot` (Verifiable Credentials are added to the Claims Tree and its root is calculated), `state` (state of identity), and `status` (whether the status of the identity state is confirmed or pending). `identity state` also contains the timestamp when the identity was created (`createdAt`) or updated(`modifiedAt`). @@ -101,7 +105,7 @@ The Issuer Node responds by sending a response message that contains: - `identifier`: Identifier of the Issuer in the standard DID format. For example: -`did:polygonid:polygon:amoy:2qNBWSAsyvaGBpqQVHk3E4cgChaN6ogaZnYCQUyoRQ` +`did:iden3:privado:main:2qNBWSAsyvaGBpqQVHk3E4cgChaN6ogaZnYCQUyoRQ` API Reference diff --git a/docs/issuer-node/issuer-node-api/introduction.md b/docs/issuer-node/issuer-node-api/introduction.md index 99e6850f..7b87545a 100644 --- a/docs/issuer-node/issuer-node-api/introduction.md +++ b/docs/issuer-node/issuer-node-api/introduction.md @@ -25,7 +25,7 @@ The Issuer Node APIs provide the following functionalities: - Manage Authentication Connections - Call Agent Endpoint using the Wallet -These API can be tested locally on a Issuer Node. +These APIs can be tested locally on a Issuer Node. :::note diff --git a/docs/issuer-node/issuer-node-guide.md b/docs/issuer-node/issuer-node-guide.md index c5f92cfd..686e4a5c 100644 --- a/docs/issuer-node/issuer-node-guide.md +++ b/docs/issuer-node/issuer-node-guide.md @@ -26,39 +26,54 @@ To create a credential, you require a schema that contains its JSON vocabulary s You can create your own schemas and import them to the Issuer Node. Here's how you can do that: -1. Click on **Import Schema**: +**1.** Click on **Import Schema**:
-2. Then you provide the schema URL: +

+ + +**2.** Then you provide the schema URL:
-3. After you pasted the schema URL, you can click on **Preview import**. +

+ + +**3.** After you pasted the schema URL, you can click on **Preview import**.
-4. The preview will show the details of the schema. You can also choose to see the attributes in a formatted way, as a JSON LD context or the JSON schema itself. +

+ + +**4.** The preview will show the details of the schema. You can also choose to see the attributes in a formatted way, as a JSON LD context or the JSON schema itself.
-5. Your new schema will be instantly added to your schema list. +

+ + +**5.** Your new schema will be instantly added to your schema list.
+

+ + ## Credentials -The Credentials main page shows information about all the credentials that have been granted. Each of one those credentials can be revoked by clicking on the 3 dots at the end of the row. +The Credentials main page shows information about all the credentials that have been granted. Each one of those credentials can be revoked by clicking on the 3 dots at the end of the row.
@@ -79,45 +94,59 @@ The main responsibility of an Issuer is to create and provide credentials to ID If you already have a connection with an identifier or you have its DID, you can issue a credential directly to it. -1. You can start by clicking on the **Issue credential** button or choosing the **Issue** action next to one of your Schema types. +**1.** You can start by clicking on the **Issue credential** button or choosing the **Issue** action next to one of your Schema types.
-2. Either paste an identifier DID or select one from the list: +

+ +**2.** Either paste an identifier DID or select one from the list:
-3. Now you will be prompted to choose which Schema Type you would like to create your credential with. +

+ +**3.** Now you will be prompted to choose which Schema Type you would like to create your credential with. +
-4. The credential we are trying to issue in this tutorial has one mandatory field: the **entryDate**. That would represent the day when the person would have joined the DAO. +

+ +**4.** The credential we are trying to issue in this tutorial has one mandatory field: the **entryDate**. That would represent the day when the person would have joined the DAO.
-5. Click on **Issue credential directly** and the credential is sent to the Holder. +

+ +**5.** Click on **Issue credential directly** and the credential is sent to the Holder. + ### Generating a Credential link -1. You can start by clicking on the **Issue credential** button or choosing the **Issue** action next to one of your Schema types. +**1.** You can start by clicking on the **Issue credential** button or choosing the **Issue** action next to one of your Schema types.
-2. There are some available options for this credential: an expiring date and a maximum number of issuances. +

+ +**2.** There are some available options for this credential: an expiring date and a maximum number of issuances.
+

+ :::note If you clicked on the **Issue credential** button, you will later be prompted to choose which Schema Type you would like to create your credential with. @@ -128,13 +157,15 @@ If you clicked on the **Issue credential** button, you will later be prompted to ::: -3. The credential we are trying to issue in this tutorial has one mandatory field: the **entryDate**. That would represent the day when the person would have joined the DAO. +**3.** The credential we are trying to issue in this tutorial has one mandatory field: the **entryDate**. That would represent the day when the person would have joined the DAO.
-4. After you click on **Create credential link**, you will have access to the credential link: +

+ +**4.** After you click on **Create credential link**, you will have access to the credential link:
@@ -176,6 +207,8 @@ This area of the Issuer Node UI shows all the current connections with ID Holder
+

+ You can also check the details about each of those connections, issue credentials directly or remove them by clicking on the 3 dots next to each connection. The Details page shows some useful information, such as identifier(DID), creation date and issued credentials. Some other available actions are direct issuance, credential revocation and removal. @@ -194,12 +227,16 @@ To add a new identity, click on **Add identity**
+

+ Fill in the name and details related to this identity. Clicking **Add identity** would add a new identity for your issuer node.
+

+ To switch between different identities for the issuer node, click on the switch and select the desired identity.
diff --git a/docs/issuer/cred-issue-methods.md b/docs/issuer/cred-issue-methods.md index 9a66f786..69c55d05 100644 --- a/docs/issuer/cred-issue-methods.md +++ b/docs/issuer/cred-issue-methods.md @@ -5,11 +5,11 @@ sidebar_label: Credential Issuance Methods description: Description of the Credential Issuance Methods. keywords: - docs - - polygon id + - privado id - credential - method - SIG - - Baby Jubjub + - Baby JubJub - MTP - Merkle Tree - Proof @@ -27,7 +27,7 @@ There are two ways those credentials can be issued: using **BJJ key Signature** ### SIG Method: Issuance of Credentials with Baby JubJub(BJJ) Key Signatures -The credential is not added to the Issuer’s Merkle tree, instead a **Baby Jubjub (BJJ)** signature is used which is then verified upon presentation. With this method, issuers can issue a large number of credentials without needing to spend any gas to issue the credentials. +The SIG method provides an efficient way to issue credentials without incurring blockchain transaction costs. In this approach the credential is not added to the Issuer’s Merkle tree, instead a **Baby JubJub (BJJ)** signature is used which is then verified upon presentation. With this method, issuers can issue a large number of credentials without needing to spend any gas to issue the credentials.
@@ -35,10 +35,27 @@ The credential is not added to the Issuer’s Merkle tree, instead a **Baby Jubj ### MTP Method: Issuance of Credentials with Merkle Tree Proof -The validation of the proof is done against the state published on-chain. No personal information is stored on-chain. A key difference with this method is that the identity state has to be published on-chain (the hash of the merkle trees), since the [Identity State Transition function](https://docs.iden3.io/protocol/spec/#identity-state-update) has to be executed. +The MTP method provides on-chain verifiable credentials through Merkle Tree structures. The validation of the proof is done against the state published on-chain. No personal information is stored on-chain. A key difference with this method is that the identity state has to be published on-chain (the hash of the merkle trees), since the [Identity State Transition function](https://docs.iden3.io/protocol/spec/#identity-state-update) has to be executed. Another important difference is that through this method smart contracts can issue credentials. The estimated cost of calling this function is approximately 2 million gas on average ( 0.36 MATIC in the Polygon PoS mainnet as of June 2023). Furthermore, credential issuance batching could be done to optimize the gas cost of the issuance process.
+ + +## When to Use Each Method + +### Choose SIG Method When: +- You need to issue credentials at scale without gas costs +- Off-chain verification is sufficient for your use case +- You want faster credential issuance +- Smart contract integration is not required +- Example:- Digital Event Ticketing System, Corporate ID Badge System etc. + +### Choose MTP Method When: +- You need on-chain verification capabilities +- Smart contracts need to issue or verify credentials +- You require the highest level of security and immutability +- Batch processing can optimize gas costs for multiple credentials +- Example:- Certification Platform, Supply Chain Compliance etc. \ No newline at end of file diff --git a/docs/issuer/credential-marketplace.md b/docs/issuer/credential-marketplace.md index 6d663dc0..825e8048 100644 --- a/docs/issuer/credential-marketplace.md +++ b/docs/issuer/credential-marketplace.md @@ -5,7 +5,7 @@ sidebar_label: Credential Marketplace description: "Features of the Credential Marketplace" keywords: - docs - - polygon id + - privado id - credential - marketplace - issuer @@ -20,7 +20,7 @@ It also offers an environment for issuers to display the credentials they are of The marketplace is convenient for all the players in the self-sovereign identity environment: it is trustworthy for the verifier as it provides a curated set of trusted issuers and brings potential new customers for issuers. -The Credential Marketplace provides visibility for everyone involved in the decentralized identity business, be they an issuer, verifier, wallet provider, trust network, or system integrator, The ecosystem page, coming together with Marketplace, gathers all those participants and presents a comprehensive description of their businesses. +The Credential Marketplace provides visibility for everyone involved in the decentralized identity business, be they an issuer, verifier, wallet provider, trust network, or system integrator. The ecosystem page, coming together with Marketplace, gathers all those participants and presents a comprehensive description of their businesses. ## Credential Marketplace Walkthrough diff --git a/docs/issuer/display-method.md b/docs/issuer/display-method.md index 48bc7222..7f43656a 100644 --- a/docs/issuer/display-method.md +++ b/docs/issuer/display-method.md @@ -19,32 +19,79 @@ keywords: - digital identity --- +## Overview -# Custom Display Methods +Custom Display Methods define the visual presentation and branding of verifiable credentials issued through the Privado Issuer Node. They enable organizations to create professional, branded credentials that maintain consistency across all issued documents while building trust with credential holders. -**What are Custom Display Methods?** -They define how a credential is presented to its holder. For instance, a university may issue digital diplomas in a specific layout (with the university’s logo, official colors, etc.) that is visually appealing. A Custom Display Method ensures consistency and brand adherence across all issued credentials. +### Key Benefits ---- +- **Brand Consistency**: Ensure all credentials follow your organization's visual identity +- **Professional Appearance**: Create visually appealing credentials that enhance credibility +- **Customization**: Tailor the look and feel to match specific use cases or credential types +- **User Trust**: Professional presentation increases confidence in credential authenticity +- **Reusability**: Create once and apply to multiple credential schemas -## Example Use Case - -**Scenario**: A company wants to issue secure digital certificates as Verifiable Credentials for its employees' achievements or training. Instead of generic text-based credentials, they want a branded, visually appealing credential that includes: +--- -- Company logo -- Employee photo -- Distinct color scheme -- Signature of the HR manager +## Custom Display Methods -By creating a Custom Display Method and referencing it during credential issuance, they ensure each certificate is displayed exactly as intended, maintaining brand identity and professionalism. +**What are Custom Display Methods?** +They define how a credential is presented to its holder. For instance, a university may issue digital diplomas in a specific layout (with the university’s logo, official colors, etc.) that is visually appealing. A Custom Display Method ensures consistency and brand adherence across all issued credentials. +### Example: KYC Age Verification Display Method + +**Assets Required:** +- Issuer logo (64x64px PNG) +- KYC background (320x200px JPEG) +- Brand colors from Issuer guidelines + +**metadata.json:** +```json +{ + "title": "KYC Age Credential", + "description": "Know Your Customer Verification", + "issuerName": "PrivadoID Issuer", + "titleTextColor": "#f2743a", + "descriptionTextColor": "#f2743a", + "issuerTextColor": "#f2743a", + "backgroundImageUrl": "ipfs://QmecKDMotkM8a6vxw35CB7iHfToBJnzJrPcmA3gHit9jt9", + "logo": { + "uri": "ipfs://QmWkSgmHbKRfhndWqHwVgfVpZSrWNiWZMTHb6k5KxY8ySc", + "alt": "Logo PrivadoID Issuer" + } +} +``` + +**Credential Issuance:** +```json +{ + "credentialSchema": "https://raw.githubusercontent.com/iden3/claim-schema-vocab/main/schemas/json/KYCAgeCredential-v3.json", + "type": "KYCAgeCredential", + "credentialSubject": { + "id": "", + "birthday": 19960424, + "documentType": 2 + }, + "expiration": 1735689600, + "displayMethod": { + "id": "", + "type": "Iden3BasicDisplayMethodV1" + } +} +``` --- ## Building a Display Method +Restrictions: + +1. `backgroundImageUrl` and `logo` only support .png and .jpeg formats. +2. Maximum length for `title` is 60 characters. +3. Maximum length for `description` is 120 characters. + ### Step 1: Fill Out Metadata 1. Open the [Display Method Builder](https://display-method-dev.privado.id/). -2. Enter all required metadata fields (name, description, type, etc.) as guided by the [Display Method Documentation](https://docs.privado.id/docs/issuer/display-method/). +2. Enter all required metadata fields (tile, description, issuer name, etc.) 3. Make sure to follow any restrictions or formatting requirements. ![Display Method Builder](../../static/img/display_methods/1.png) @@ -59,6 +106,7 @@ By creating a Custom Display Method and referencing it during credential issuanc 3. This link uniquely references your Display Method and will be used in the Issuer Node. ![Obtain the IPFS Link](../../static/img/display_methods/2.png) + --- ## Usage of a Display Method in Issuer Node @@ -130,5 +178,6 @@ Below is a summary of the relevant API endpoints to manage Display Methods and s ## Conclusion -With these steps, you can create, manage, and apply custom Display Methods to credentials in the Privado Issuer Node. By leveraging custom layouts, organizations, and institutions can ensure consistent branding and meaningful designs for their verifiable credentials. This not only adds professionalism but also improves the user’s trust and recognition of your issued credentials. +Custom Display Methods provide a powerful way to enhance the presentation and branding of verifiable credentials. By following the guidelines and best practices outlined in this documentation, organizations can create professional, trustworthy credentials that serve their users effectively while maintaining brand consistency and technical excellence. +The combination of flexible design capabilities, robust technical architecture, and comprehensive management tools makes Display Methods an essential component of any professional credential issuance system. Whether you're issuing educational certificates, professional licenses, or corporate credentials, Display Methods ensure your credentials make the right impression while maintaining the highest standards of security and usability. \ No newline at end of file diff --git a/docs/issuer/features.md b/docs/issuer/features.md index ffde5c19..1c9bf8b3 100644 --- a/docs/issuer/features.md +++ b/docs/issuer/features.md @@ -5,7 +5,7 @@ sidebar_label: Features description: Issuer main features. keywords: - docs - - polygon id + - privado id - issuer node - claim - verifiable credentials @@ -20,18 +20,18 @@ This feature enables the creation of Ethereum-controlled identities. Ethereum ac The representation of the DID for this case follows the same canonical form, where the identifier `2qCU58EJgrELSJT6EzT27Rw9DhvwamAdbMLpePztYq` actually originates from the Ethereum address: ``` -did:polygonid:polygon:amoy:2qCU58EJgrELSJT6EzT27Rw9DhvwamAdbMLpePztYq +did:iden3:privado:main:2qCU58EJgrELSJT6EzT27Rw9DhvwamAdbMLpePztYq ``` :::note -Due to its public nature, the Ethereum Polygon DID doesn't support private profiles. +Due to its public nature, the Ethereum Privado DID doesn't support private profiles. ::: ## Revocation Status -Mobile applications can get the Revocation Status of a particular credential by requesting that information straight from the Issuer Node. However, if the Issuer Node is offline for some reason, that communication would not work. The Reverse Hash Service and the On-chain Revocation Status are two solutions for this issue. +Mobile applications can get the Revocation Status of a particular credential by requesting that information directly from the Issuer Node. However, if the Issuer Node is offline for some reason, that communication would not work. The Reverse Hash Service and the On-chain Revocation Status are two solutions for this issue.
@@ -49,7 +49,7 @@ As the diagram shows, the Issuer Node sends the revocation information to the RH ### On-chain Revocation -On-chain Revocation status leverages the blockchain decentralized storage to make the revocation information permanent on the network. That means that, even if the Issuer Node or the Reverse Hash Service is down, the data is still available on-chain. +On-chain Revocation status leverages the blockchain decentralized storage to make the revocation information permanent on the network. This means that, even if the Issuer Node or the Reverse Hash Service is down, the data is still available on-chain.
@@ -57,8 +57,8 @@ On-chain Revocation status leverages the blockchain decentralized storage to mak ## Non-merklized credentials -Non-merklized credentials are specially important for on-chain issuers, because smart contracts built on Solidity can't fetch JSON-LD schemas directly via HTTP or IPFS. +Non-merklized credentials are especially important for on-chain issuers, because smart contracts built on Solidity can't fetch JSON-LD schemas directly via HTTP or IPFS. Here is an example of [a non-merklized schema](https://github.com/iden3/claim-schema-vocab/blob/main/schemas/json-ld/player-nonmerklized.jsonld). Compare it to [this merklized one](https://github.com/iden3/claim-schema-vocab/blob/main/schemas/json-ld/kyc-v4.jsonld). Notice that the schema is defined by utilizing an `iden3_serialization` attribute. -Read more about non-merklized credentials on the [Iden3 documentation](https://docs.iden3.io/protocol/non-merklized/). +Read more about non-merklized credentials in the [Iden3 documentation](https://docs.iden3.io/protocol/non-merklized/). diff --git a/docs/issuer/issuer-configuration.md b/docs/issuer/issuer-configuration.md index e78a3462..58d5c942 100644 --- a/docs/issuer/issuer-configuration.md +++ b/docs/issuer/issuer-configuration.md @@ -79,7 +79,7 @@ privado: ``` :::note -Configuring Privado Idenity Chain (privado:main) is necessary as identities on the Privado ID Web Wallet and the Privado ID Wallet App are asociated to this chain. This configuration ensures issuance of credentials to these identities. +Configuring Privado Idenity Chain (privado:main) is necessary as identities on the Privado ID Web Wallet and the Privado ID Wallet App are associated to this chain. This configuration ensures issuance of credentials to these identities. ::: Notes about **rhsSettings** mode: diff --git a/docs/issuer/issuer-core.md b/docs/issuer/issuer-core.md index 449e3fbf..b72160c2 100644 --- a/docs/issuer/issuer-core.md +++ b/docs/issuer/issuer-core.md @@ -16,7 +16,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; # Issuer Node API -The Issuer Node API is ideal for users who for ** who want to create solutions based on Privado ID functionalities and might be interested in having access to low level information** such as Merkle Trees. +The Issuer Node API is ideal for users ** who want to create solutions based on Privado ID functionalities and might be interested in having access to low level information** such as Merkle Trees.
diff --git a/docs/issuer/issuer-demo.md b/docs/issuer/issuer-demo.md index 4ba4e711..d27f31ed 100644 --- a/docs/issuer/issuer-demo.md +++ b/docs/issuer/issuer-demo.md @@ -5,7 +5,7 @@ sidebar_label: Demo Issuer description: Demonstration of an Issuer. keywords: - docs - - polygon id + - privado id - issuer - claim - demo diff --git a/docs/issuer/issuer-node-ui.md b/docs/issuer/issuer-node-ui.md index e001930d..9bfbd0d8 100644 --- a/docs/issuer/issuer-node-ui.md +++ b/docs/issuer/issuer-node-ui.md @@ -5,7 +5,7 @@ sidebar_label: Overview description: Issuer Node UI description and its components. keywords: - docs - - polygon id + - privado id - issuer node - claim - verifiable credentials @@ -25,19 +25,19 @@ The Issuer Node UI provides the full experience of having an Issuer Node with al ## Issuer Node Components -The [Issuer Node](https://github.com/0xPolygonID/issuer-node) comprises the following components and each one of these components can be either dockerized or launched as a separate service. +The [Issuer Node](https://github.com/0xPolygonID/issuer-node) comprises the following components, and each one of these components can be either dockerized or launched as a separate service. -- **Issuer Application** to issue Verifiable Credentials and communicate with users' wallets. +- **Issuer Application** Used to issue Verifiable Credentials and communicate with users' wallets. -- **Vault** (optional): Based on [HashiCorp](https://www.hashicorp.com/), the Vault is used in the Issuer Node for providing key management services. It is utilized to protect the user sensitive data by securing their private key. The Vault has been provided with a plugin called `vault-plugin-secrets-iden3`; this plugin is used to sign the data with Baby Jubjub Keys that are stored in the Vault. +- **Vault** (optional): Based on [HashiCorp](https://www.hashicorp.com/), the Vault is used in the Issuer Node for providing key management services. It is utilized to protect the user-sensitive data by securing their private keys. The Vault has been provided with a plugin called `vault-plugin-secrets-iden3`; this plugin is used to sign the data with Baby Jubjub Keys that are stored in the Vault. -- **Redis**: [Redis](https://redis.io/) is used for caching the schemas that we use in the Issuer Node. The schemas are downloaded from IPFS and stored on Redis. This way, every time the Issuer Node issues a credential, it doesn't need to fetch the schemas from an external source; it can fetch it directly from Redis. This boosts the performance of the application. +- **Redis**: [Redis](https://redis.io/) is used for caching the schemas that we use in the Issuer Node. The schemas are downloaded from IPFS and stored on Redis. This way, every time the Issuer Node issues a credential, it doesn't need to fetch the schemas from an external source; it can fetch them directly from Redis. This boosts the performance of the application. -- **DB**: This container is used as the data source for the Issuer Node. In our implementation of the Issuer Node, we have used Postgres as the database. It is where all the data related to issued credentials are stored. +- **DB**: This container is used as the data source for the Issuer Node. In our implementation of the Issuer Node, we have used PostgreSQL as the database. It is where all the data related to issued credentials are stored. :::note -In a testing environment, you can run the Vault, Redis, and Postgres services inside a docker. For production environments, you are advised to secure these services first before using them. +In a testing environment, you can run the Vault, Redis, and PostgreSQL services inside a Docker. For production environments, you are advised to secure these services first before using them. ::: diff --git a/docs/issuer/issuer-overview.md b/docs/issuer/issuer-overview.md index 6581c076..bb3b7539 100644 --- a/docs/issuer/issuer-overview.md +++ b/docs/issuer/issuer-overview.md @@ -62,7 +62,7 @@ There are basically two ways the Issuer Node can be operated: ### Issuer Node API -The [Issuer Node API](issuer-core.md) is designed for developers and integrators looking to build custom solutions leveraging Privado ID's functionalities. It is ideal for those who might be interested in having access to low-level information** such as Merkle Trees. +The [Issuer Node API](issuer-core.md) is designed for developers and integrators looking to build custom solutions leveraging Privado ID's functionalities. It is ideal for those who might be interested in having access to low-level information such as Merkle Trees.
@@ -70,7 +70,7 @@ The [Issuer Node API](issuer-core.md) is designed for developers and integrators ### Issuer Node UI -The [Issuer Node UI](issuer-node-ui.md) provides the full experience of having an Issuer Node with all its capabilities in a easy-to-use interface for handling essential functions such as issuing and revoking credentials, publishing states, managing schemas, connections and identities. Powered by the Issuer Node API, it offers full control of these features without requiring direct API use. +The [Issuer Node UI](issuer-node-ui.md) provides the full experience of having an Issuer Node with all its capabilities in an easy-to-use interface for handling essential functions such as issuing and revoking credentials, publishing states, managing schemas, connections and identities. Powered by the Issuer Node API, it offers full control of these features without requiring direct API use.
diff --git a/docs/issuer/on-chain-issuer/on-chain-overview.md b/docs/issuer/on-chain-issuer/on-chain-overview.md index 7fb775a2..935b6834 100644 --- a/docs/issuer/on-chain-issuer/on-chain-overview.md +++ b/docs/issuer/on-chain-issuer/on-chain-overview.md @@ -12,7 +12,7 @@ keywords: - smart contract --- -The On-chain Issuer is a way of issuing credentials by leveraging the full power of a smart contract. As it is commonly known, a smart contract is software that resides in a blockchain network, meaning that its code and data aren’t necessarily stored in a server, but rather distributed in a decentralized manner. Therefore, an on-chain issuer could be considered a decentralized issuer, as all the underlying logic of the credentials is written on a smart contract with its inherent publicity. +The On-chain Issuer issues credentials by leveraging the full power of a smart contract. As it is commonly known, a smart contract is software that resides in a blockchain network, meaning that its code and data aren’t necessarily stored in a server, but rather distributed in a decentralized manner. Therefore, an on-chain issuer could be considered a decentralized issuer, as all the underlying logic of the credentials is written on a smart contract with its inherent publicity. This issuance method then serves as an alternative to the [Issuer Node](/docs/issuer/issuer-overview.md), whose implementation depends on a dedicated setup and its own infrastructure. @@ -20,7 +20,7 @@ The fact that all this logic is present on the blockchain enables credential iss ## On-chain issuance -On-chain issuance is trustless or trust-minimized, depending on smart contract business logic. It reduces dependency on non-auditable decisions for issuing credentials. +On-chain issuance is either trustless or trust-minimized, depending on smart contract business logic. It reduces dependency on non-auditable decisions for issuing credentials. The properties of smart contracts make them good candidates to act as trusted attestation services since the attestation mechanism is transparent and auditable to everyone. This serves as an alternative to a number of centralized issuers for use cases when an Identity needs to issue credentials about themselves or their activity, which can be verified by the smart contract logic. In simple words, you can see everything happening: all the logic used to generate the credential is live on the blockchain and ready to be checked and verified. @@ -59,7 +59,7 @@ In fact, on-chain issuers enable two categories of credentials: public and priva A public credential will leverage all the available data of a particular address and aggregate it to generate a claim, such as a reputation score, linked to an identity. There is no personal information revealed and it can be made available on-chain. -In this case, the value is in the aggregation of large amounts of information into ready-to-use credentials that are linked to an identity. This way, the identity holder could prove his assets without disclosing the Ethereum accounts that control these assets. +In this case, the value is in the aggregation of large amounts of information into ready-to-use credentials that are linked to an identity. This way, the identity holder could prove ownership of assets without disclosing the Ethereum accounts that control these assets. Some interesting examples of public use cases would be: diff --git a/docs/issuer/on-chain-issuer/on-chain-tutorial.md b/docs/issuer/on-chain-issuer/on-chain-tutorial.md index f7de65cf..43821318 100644 --- a/docs/issuer/on-chain-issuer/on-chain-tutorial.md +++ b/docs/issuer/on-chain-issuer/on-chain-tutorial.md @@ -23,26 +23,26 @@ The difference between these two approaches: - [demo](https://github.com/0xPolygonID/onchain-merklized-issuer-demo) - [contract](https://github.com/0xPolygonID/contracts/blob/main/contracts/examples/IdentityExample.sol) -1. The **on-chain non-merklized issuer** can use information from the blockchain (such as balance, token ownership, etc.) to issue a credential directly on the blockchain. This approach is decentralized and trustless - no need to trust an issuer to act honestly, because it's enforced by the smart contract and auditable on chain. But it comes with a few limitations: max 4 data fields in the credential and data is public. More about [**non-merklized credentials**](https://docs.iden3.io/protocol/non-merklized/). +2. The **on-chain non-merklized issuer** can use information from the blockchain (such as balance, token ownership, etc.) to issue a credential directly on the blockchain. This approach is decentralized and trustless - no need to trust an issuer to act honestly, because it's enforced by the smart contract and auditable on chain. But it comes with a few limitations: max 4 data fields in the credential and data is public. More about [**non-merklized credentials**](https://docs.iden3.io/protocol/non-merklized/). - [demo](https://github.com/0xPolygonID/onchain-nonmerklized-issuer-demo) - [contract](https://github.com/0xPolygonID/contracts/blob/main/contracts/examples/BalanceCredentialIssuer.sol) -This guide presents an example of how to use the **on-chain merklized issuer**. We created a small application, where we communicate with Metamask to retrieve the user's balance and a claim about this balance is generated via the on-chain issuer. In this case, the credential will be created locally and stored to **on-chain issuer**. +This guide presents an example of how to use the **on-chain merklized issuer**. This tutorial demonstrates the implementation through a practical application, where we communicate with Metamask to retrieve the user's balance and a claim about this balance is generated via the on-chain issuer. In this case, the credential will be created locally and stored to **on-chain issuer**. There are two main components in this application: 1. On-chain merklized issuer ([demo](https://github.com/0xPolygonID/onchain-merklized-issuer-demo)|[contract](https://github.com/0xPolygonID/contracts/blob/main/contracts/examples/IdentityExample.sol)) -1. Front-end component for communication with Metamask +2. Front-end component for communication with Metamask ## Requirements: 1. Node js => 18.x -1. Go => 1.20.x -1. npm => 9.x.x -1. docker => 20.x -1. docker-compose => 2.23.x -1. Polygon ID wallet app -1. [Ngrok](https://ngrok.com/) +2. Go => 1.20.x +3. npm => 9.x.x +4. docker => 20.x +5. docker-compose => 2.23.x +6. Privado ID wallet app +7. [Ngrok](https://ngrok.com/) ## How to run the On-chain Issuer @@ -52,7 +52,7 @@ There are two main components in this application: git clone https://github.com/0xPolygonID/onchain-merklized-issuer-demo ``` -1. Deploy an on-chain merklized issuer contract. You can use [this sample](https://github.com/0xPolygonID/contracts/blob/main/contracts/examples/IdentityExample.sol) or create your own smart contract with custom logic. +2. Deploy an on-chain merklized issuer contract. You can use [this sample](https://github.com/0xPolygonID/contracts/blob/main/contracts/examples/IdentityExample.sol) or create your own smart contract with custom logic. Clone smart contracts repository: @@ -80,13 +80,13 @@ You can find more information on how to deploy a smart contract using Hardhat [< go run utils/convertor.go --contract_address= ``` -1. Run ngrok on 8080 port. +2. Run ngrok on 8080 port. ```bash ngrok http 8080 ``` -1. Fill the .env config file with the proper variables: +3. Fill the .env config file with the proper variables: @@ -116,11 +116,12 @@ SUPPORTED_STATE_CONTRACTS="137=0x624ce98D2d27b20b8f8d521723Df8fC4db71D79D" 1. Run docker-compose: ```bash - docker-compose build - docker-compose up -d + docker compose build + docker compose up -d ``` -1. Go to: http://localhost:3000 +2. Navigate to the application interface: +> http://localhost:3000 Don't forget to download and install the Polygon ID wallet app before you go the next steps. @@ -188,12 +189,12 @@ You can use already deployed demos: ## How to verify the balance claim -1. Visit the [Query builder website](https://schema-builder.polygonid.me/query-builder/). +1. Visit the [Query builder website](https://tools.privado.id/query-builder/). 2. You now need to define the query. Verify credential from onchain merklized issuer: - - **URL**: ipfs://QmbbTKPTJy5zpS2aWBRps1duU8V3zC84jthpWDXE9mLHBX ([Schema builder link](https://schema-builder.polygonid.me/schemas/7b470cbc-0d97-4022-9c70-e393e6ebc0d5)) + - **URL**: ipfs://QmbbTKPTJy5zpS2aWBRps1duU8V3zC84jthpWDXE9mLHBX ([Schema builder link](https://tools.privado.id/schemas/7b470cbc-0d97-4022-9c70-e393e6ebc0d5)) - **Schema type**: BalanceCredential - **Attribute field**: balance @@ -210,13 +211,13 @@ You can use already deployed demos:
-4. Click on Approve. After which, the process of generating the proof is starts: +4. Select Approve to initiate the proof generation process
-5.Finally, the proof is generated. The verifier will check the revocation status and some additional information. The proof is then sent and validated by the verifier. You will receive the following response on the Query builder website +5. Finally, the proof is generated. The verifier will check the revocation status and some additional information. The proof is then sent and validated by the verifier. You will receive the following response on the Query builder website
diff --git a/docs/issuer/refresh-service/customization.md b/docs/issuer/refresh-service/customization.md index 4169fada..7a1683de 100644 --- a/docs/issuer/refresh-service/customization.md +++ b/docs/issuer/refresh-service/customization.md @@ -5,7 +5,7 @@ sidebar_label: Customization description: Customization of refresh service keywords: - docs - - polygon id + - privado id - issuer node - claim - verifiable credentials @@ -29,4 +29,4 @@ Utilize the [flexible HTTP package](https://github.com/0xPolygonID/refresh-servi For ultimate customization, consider implementing the refresh service from scratch to tailor it precisely to your specific needs. -Implementing a refresh service from scratch can be useful when you have your own isuer node implementation or have special data processing logic, etc. Check out the [current implementation of the refresh service](/docs/issuer/refresh-service/overview#refresh-service-current-implementation) to create your own. +Implementing a refresh service from scratch can be useful when you have your own issuer node implementation or have special data processing logic, etc. Check out the [current implementation of the refresh service](/docs/issuer/refresh-service/overview#refresh-service-current-implementation) to create your own. diff --git a/docs/issuer/refresh-service/overview.md b/docs/issuer/refresh-service/overview.md index 1d920b00..fdf0eac9 100644 --- a/docs/issuer/refresh-service/overview.md +++ b/docs/issuer/refresh-service/overview.md @@ -5,7 +5,7 @@ sidebar_label: Overview description: Overview of refresh service keywords: - docs - - polygon id + - privado id - issuer node - claim - verifiable credentials @@ -53,20 +53,22 @@ Example of refresh service implementation can be found [here](https://github.com ### Modules -1. **[HTTP Server](https://github.com/0xPolygonID/refresh-service/tree/main/server)**: the http server is a base layer for [iden3comm protocol](https://iden3-communication.io/). -2. **[Provider Module](https://github.com/0xPolygonID/refresh-service/tree/main/providers)**: this module receives information from external data providers. By itself, it is very flexible in settings, but you can always add your own implementation. -3. **[Package Manager](https://github.com/0xPolygonID/refresh-service/blob/main/packagemanager/packagemanager.go)**: the package manager handles ZWZ token within the iden3comm protocol. -4. **[Integration with the Issuer Node](https://github.com/0xPolygonID/refresh-service/blob/main/service/issuer.go)**: this module responsibles for communication with [issuer node](https://github.com/0xPolygonID/issuer-node/). +1. **[HTTP Server](https://github.com/0xPolygonID/refresh-service/tree/main/server)**: The http server is a base layer for [iden3comm protocol](https://iden3-communication.io/). +2. **[Provider Module](https://github.com/0xPolygonID/refresh-service/tree/main/providers)**: This module receives information from external data providers. By itself, it is very flexible in settings, but you can always add your own implementation. +3. **[Package Manager](https://github.com/0xPolygonID/refresh-service/blob/main/packagemanager/packagemanager.go)**: The package manager handles JWZ token within the iden3comm protocol. +4. **[Integration with the Issuer Node](https://github.com/0xPolygonID/refresh-service/blob/main/service/issuer.go)**: This module is responsible for communication with [issuer node](https://github.com/0xPolygonID/issuer-node/). ### Authentication module for setup iden3comm handler To be sure whether a user is the owner of the credentials they want to refresh, it is essential to implement an authentication module. To initiate the process, you should initialize the [Iden3comm package manager](https://github.com/0xPolygonID/refresh-service/blob/main/packagemanager/packagemanager.go). -In the context of a refresh service where JWZ tokens are verified, you will require the verification_key.json for the authV2 circuit. Additionally, to confirm the existence of the user in the issuer's state, one needs to know the issuer's state contract [addresses](https://docs.iden3.io/contracts/state/). +In the context of a refresh service where JWZ tokens are verified, you will require the verification_key.json for the authV2 circuit. Additionally, to confirm the existence of the user in the issuer's state, one needs to know the issuer's state contract [addresses](https://docs.iden3.io/contracts/contracts/). To authorise the user’s JWZ token, it is necessary to define a function that verifies proof and the issuer’s state. Once the authorization is complete, the refresh service will be aware of the user’s DID from the JWZ token. Now you can ensure that the credential being refreshed contains the same DID in the credential subject. -> **NOTE:** It is crucial to verify whether a user is the owner of the credential that potentially will be refreshed. Without this verification, an attacker could refresh and obtain a third-party credential. +:::note + It is crucial to verify whether a user is the owner of the credential that potentially will be refreshed. Without this verification, an attacker could refresh and obtain a third-party credential. +::: ### Integration with issuer node @@ -114,7 +116,9 @@ To implement credential refreshing in a client side, need to follow next algorit - After refreshing the credential, checks if the updated credential satisfies the proof request. If it does, generate a proof. If the credential still doesn't meet the proof request, the process repeats, selecting another credential with a refresh service and refreshing it. -> 💡 **NOTE:** If expired credentials are revoked, the current recommended algorithm will not process or update such credentials. +:::note +If expired credentials are revoked, the current recommended algorithm will not process or update such credentials. +::: ### Client behavior depending on the type of proof in a proof request @@ -126,7 +130,9 @@ To implement credential refreshing in a client side, need to follow next algorit **Merkle tree proof (MTP):** -> **NOTE:** The workflow for MTP is in development. However, you still can receive notifications about MTP proof on the mobile application after refreshing credential(-s) that have MTP proof are performed. +:::note +The workflow for MTP is in development. However, you still can receive notifications about MTP proof on the mobile application after refreshing credential(-s) that have MTP proof are performed. +::: 1. The holder should decline the proof request. This is because generating an MTP proof might require a significant amount of time to become ready 1. The `refreshService` informs the holder about the `pending` status. diff --git a/docs/issuer/refresh-service/setup-guide.md b/docs/issuer/refresh-service/setup-guide.md index 4eca00ac..9bff7340 100644 --- a/docs/issuer/refresh-service/setup-guide.md +++ b/docs/issuer/refresh-service/setup-guide.md @@ -5,7 +5,7 @@ sidebar_label: Setup guide description: Setup guide for refresh service keywords: - docs - - polygon id + - privado id - issuer node - claim - verifiable credentials @@ -16,22 +16,31 @@ keywords: import useBaseUrl from '@docusaurus/useBaseUrl'; -> **NOTE: Current implementation of [refresh service](https://github.com/0xPolygonID/refresh-service) works only with [issuer-node](https://github.com/0xPolygonID/issuer-node/).** +:::note + +Current implementation of **[refresh service](https://github.com/0xPolygonID/refresh-service)** works only with **[issuer-node](https://github.com/0xPolygonID/issuer-node/).** + +::: ## Preparation 1. Run the issuer-node locally by following the [quick-start installation guide](https://github.com/0xPolygonID/issuer-node/#quick-start-installation). -1. Clone the refresh service using the command `git clone git@github.com:0xPolygonID/refresh-service.git`. -1. Build JSON and JSONLD schemas, utilizing the provided examples: + +2. Clone the refresh service using the command +```bash +git clone git@github.com:0xPolygonID/refresh-service.git +``` + +3. Build JSON and JSONLD schemas, utilizing the provided examples: - [JSON](https://raw.githubusercontent.com/iden3/claim-schema-vocab/main/schemas/json/non-zero-balance.json) - [JSONLD](https://raw.githubusercontent.com/iden3/claim-schema-vocab/main/schemas/json-ld/non-zero-balance.jsonld) -Generate custom schemas through the [schema builder](https://schema-builder.polygonid.me/builder). Additional details can be found in the [schema builder documentation](/docs/issuer/schema-builder/). +Generate custom schemas through the [schema builder](https://tools.privado.id/builder). Additional details can be found in the [schema builder documentation](/docs/issuer/schema-builder/). ## Setup with custom data provider -Consider an example of integrating [polygon scan](https://polygonscan.com/) as a data provider for the refresh service. +Consider an example of integrating [Polygon Scan](https://polygonscan.com/) as a data provider for the refresh service. 1. Integrate the custom data provider into the [data provider module](https://github.com/0xPolygonID/refresh-service/tree/main/providers): @@ -74,7 +83,7 @@ func GetBalanceByAddress(address string) (map[string]any, error) { } ``` -1. Use the custom data provider within the refresh service: +2. Use the custom data provider within the refresh service: 1. Remove the default data provider: @@ -92,7 +101,7 @@ func GetBalanceByAddress(address string) (map[string]any, error) { } ``` - 1. Use the new polygon scan data provider: + 2. Use the new polygon scan data provider: ```go // confirm the credentialType matches a supported type in the refresh service, @@ -107,7 +116,7 @@ func GetBalanceByAddress(address string) (map[string]any, error) { } ``` -1. Populate the .env variables: +3. Populate the .env variables: ``` export IPFS_GATEWAY_URL="https://infura..." export SUPPORTED_RPC="137=https://infura..." @@ -115,13 +124,13 @@ func GetBalanceByAddress(address string) (map[string]any, error) { export SUPPORTED_ISSUERS="*=https://my-issuer-node.com" export ISSUERS_BASIC_AUTH="*=myuser:mypassword" ``` -1. Generate a blank config.yaml file: +4. Generate a blank config.yaml file: ```bash touch config.yaml ``` -1. Run the refresh service: +5. Run the refresh service: ```bash source .env @@ -130,7 +139,7 @@ go run . ## Setup with default provider -To integrate [polygon scan](https://polygonscan.com/) data provider with the default data provider, follow these general steps: +To integrate [Polygon Scan](https://polygonscan.com/) data provider with the default data provider, follow these general steps: 1. Create a `config.yaml` file with the following content: @@ -185,7 +194,7 @@ go run .
-2. Retrieve the credential through the PolygonID mobile application. If the expiration date in the credential request was set in the past, the credential is supposed to be expired: +2. Retrieve the credential through the PrivadoID mobile application. If the expiration date in the credential request was set in the past, the credential is supposed to be expired:
Expired credential @@ -194,7 +203,7 @@ go run .
-3. Visit [https://verifier-demo.polygonid.me/](https://verifier-demo.polygonid.me/) to create a proof request. This is necessary because [https://schema-builder.polygonid.me/query-builder](https://schema-builder.polygonid.me/query-builder) does not currently support the `xsd:positiveInteger` type: +3. Visit [https://verifier-demo.polygonid.me/](https://verifier-demo.polygonid.me/) to create a proof request. This is necessary because [https://tools.privado.id/query-builder](https://tools.privado.id/query-builder) does not currently support the `xsd:positiveInteger` type:
Proof request @@ -203,7 +212,7 @@ go run .
-4. Scan the QR using the PolygonID mobile application. During the refreshing process, you are expected to encounter the following message: +4. Scan the QR using the PrivadoID mobile application. During the refreshing process, you are expected to encounter the following message:
Refresh process diff --git a/docs/issuer/reverse-hash-service.md b/docs/issuer/reverse-hash-service.md index fabae8a6..6dbace78 100644 --- a/docs/issuer/reverse-hash-service.md +++ b/docs/issuer/reverse-hash-service.md @@ -5,7 +5,7 @@ sidebar_label: RHS Setup description: Reverse Hash Service Setup. keywords: - docs - - polygon id + - privado id - issuer node - rhs - reverse hash service @@ -14,7 +14,7 @@ keywords: import useBaseUrl from '@docusaurus/useBaseUrl'; -# Reverse Hash Service Set up +# Reverse Hash Service Setup Repository: https://github.com/iden3/reverse-hash-service @@ -32,12 +32,12 @@ Docker set up should only be used for testing purposes only ### Requirements - Unix-based operating system (e.g. Debian, Arch, Mac OS X) -- [Docker Engine](https://docs.docker.com/engine/) 1.27 +- [Docker Engine](https://docs.docker.com/engine/) 1.48 1. Start the services ```bash -docker-compose up -d +docker compose up -d ``` 2. Copy schema.sql to the db container @@ -52,13 +52,7 @@ docker cp schema.sql reverse-hash-service_db_1:/ docker exec -it reverse-hash-service_db_1 /bin/bash ``` -4. Create RHS DB - -```bash -createdb -U iden3 -h localhost rhs -``` - -5. Upload schema.sql inside on docker container +4. Upload schema.sql inside on docker container ```bash psql -h localhost -U iden3 -d rhs < schema.sql @@ -70,7 +64,7 @@ psql -h localhost -U iden3 -d rhs < schema.sql - Unix-based operating system (e.g. Debian, Arch, Mac OS X) - [Go](https://go.dev/) version 1.18 or higher -- [Postgres](https://www.postgresql.org/) +- [PostgreSQL](https://www.postgresql.org/) 1. Access PostgreSQL instance and create database @@ -84,7 +78,7 @@ createdb rhs && psql -d rhs < ./schema.sql export RHS_DB="host=localhost password=pgpwd user=postgres database=rhs" ``` -3. Build and run RHS servoce +3. Build and run RHS service ``` go build && ./reverse-hash-service diff --git a/docs/issuer/schema-builder.md b/docs/issuer/schema-builder.md index ab681e5c..8afa1111 100644 --- a/docs/issuer/schema-builder.md +++ b/docs/issuer/schema-builder.md @@ -5,7 +5,7 @@ sidebar_label: Schema Builder UI description: Create schemas intuitively by using the Schema Builder UI. keywords: - docs - - polygon id + - privado id - issuer node - claim - verifiable credentials @@ -18,7 +18,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; In order to create new types of credentials, it is necessary to generate JSON schemas. These are the underlying files that define the credential attributes. -[The Schema Builder](https://schema-builder.polygonid.me/) is a tool created to simplify the process of creating schemas by using an intuitive user interface and enabling everyone to check previously made schemas. +[The Schema Builder](https://tools.privado.id/) is a tool created to simplify the process of creating schemas by using an intuitive user interface and enabling everyone to check previously made schemas. Learn more about the Schema Explorer in the video below: @@ -28,12 +28,14 @@ Learn more about the Schema Explorer in the video below: ## Schema Explorer -[The Schema Builder landing page](https://schema-builder.polygonid.me/) presents a Schema Explorer, where you can find all previously created schemas and drill down your search for specific kinds of schemas. Not all schemas need to be created from scratch. +[The Schema Builder landing page](https://tools.privado.id/) presents a Schema Explorer, where you can find all previously created schemas and drill down your search for specific kinds of schemas. Not all schemas need to be created from scratch.
+
+ We highly recommend that you look for one of the available schemas before actually creating one. By doing so, you can save time for your project and leverage a full library of popular ready-to-use schemas. If you find a schema that is similar to what you need but you are not completely happy with its characteristics, you can always **fork it** and add your own attributes. @@ -41,12 +43,16 @@ If you find a schema that is similar to what you need but you are not completely
+
+ Forking a schema is similar to GitHub forks. It creates a copy of the schema and lets you define new attributes. So you build your own out of another one.
+
+ :::info The outcome of a forked schema shows its version and where it was forked from. @@ -60,15 +66,17 @@ The forked schema also shows its number of forks: ## Schema Builder -As previously stated, [the Schema Builder](https://schema-builder.polygonid.me/builder) is the easiest way to generate new types of credentials as it allows users to define the attributes, data types, and constraints for their schemas. The tool will then generate the necessary JSON-LD files and other artifacts required to implement the schema. +As previously stated, [the Schema Builder](https://tools.privado.id/builder) is the easiest way to generate new types of credentials as it allows users to define the attributes, data types, and constraints for their schemas. The tool will then generate the necessary JSON-LD files and other artifacts required to implement the schema.
-Schema form and its JSON outcome. -:::info +
+Above: the form view on the left and the generated JSON output on the right + +:::info If you already have access to a file containing a JSON schema or a URL where that schema might be located, you can always add it to the Schema Builder by clicking on the **Import Schema** button. Then you will be able to edit, create new JSON and JSON-LD files and publish it on IPFS.
@@ -76,7 +84,6 @@ If you already have access to a file containing a JSON schema or a URL where tha ![Import Schema](/img/import-schema.png)
- ::: Learn more about the Schema Builder in the video below: @@ -93,10 +100,12 @@ The first page of the Schema Builder flow lets you define the basic aspects of t
-- Title: a name for the schema. -- Schema Type: similar to (and in most cases coincides with) the schema name. The text provided in this field will become the name of the type in the JSON LD context associated with this schema. -- Version: this is important to register the current version of the schema, as it might be updated in the future. -- Description: a description of the schema should explain in simple terms what it will be used for. +
+ +- **Title**: a name for the schema. +- **Schema Type**: similar to (and in most cases coincides with) the schema name. The text provided in this field will become the name of the type in the JSON LD context associated with this schema. +- **Version**: this is important to register the current version of the schema, as it might be updated in the future. +- **Description**: a description of the schema should explain in simple terms what it will be used for. #### Attributes @@ -106,10 +115,12 @@ You can add multiple attributes to your schema. All of them need to have the fol
-- Name: the name of the attribute with a limited use of characters. -- Title: a more human-readable title for the attribute without restrictions for special characters or space. -- Data type: the kind of data the schema will support, such as integer, string, boolean etc. -- Description: a short human-readable explanation of the attribute. +
+ +- **Name**: the name of the attribute with a limited use of characters. +- **Title**: a more human-readable title for the attribute without restrictions for special characters or space. +- **Data Type**: the kind of data the schema will support, such as integer, string, boolean etc. +- **Description**: a short human-readable explanation of the attribute. Learn about the advanced features of the Schema Builder in the video below: diff --git a/docs/issuer/schema-exs.md b/docs/issuer/schema-exs.md index 438442a5..5e295261 100644 --- a/docs/issuer/schema-exs.md +++ b/docs/issuer/schema-exs.md @@ -5,7 +5,7 @@ sidebar_label: Schema examples description: Check a few schema samples. keywords: - docs - - polygon id + - privado id - issuer node - claim - verifiable credentials diff --git a/docs/issuer/schema.md b/docs/issuer/schema.md index a2e67e0b..cbc3c3ea 100644 --- a/docs/issuer/schema.md +++ b/docs/issuer/schema.md @@ -5,7 +5,7 @@ sidebar_label: Create Custom Schemas description: Learn how to create custom schemas manually. keywords: - docs - - polygon id + - privado id - issuer node - claim - verifiable credentials @@ -18,7 +18,7 @@ keywords: :::info -Polygon ID offers an intuitive, user-friendly interface to create schemas: the Schema Builder. [Here](schema-builder.md) you can find a tutorial for this tool. You can also access it on [https://schema-builder.polygonid.me/](https://schema-builder.polygonid.me/). +Privado ID offers an intuitive, user-friendly interface to create schemas: the Schema Builder. [Here](schema-builder.md) you can find a tutorial for this tool. You can also access it on [https://tools.privado.id/](https://tools.privado.id/). ::: @@ -71,14 +71,12 @@ The JSON-LD Context contains: - its unique identifier `@id` which is a public URL where the context can be resolved. If you are working on Github, you can fetch the URL directly from your published repository based on the file path. In this case it is - - `https://raw.githubusercontent.com/0xPolygonID/tutorial-examples/main/credential-schema/proof-of-dao-longevity.jsonld#ProofOfDaoLongevity` + [`here`](https://raw.githubusercontent.com/0xPolygonID/tutorial-examples/main/credential-schema/proof-of-dao-longevity.jsonld#ProofOfDaoLongevity) - the definition of the vocabulary with its URL In this case we create a field defined `vocab` and attach the URL that identifies the vocabulary. In this case it is - - `https://github.com/0xPolygonID/tutorial-examples/blob/main/credential-schema/proof-of-dao-longevity-vocab.md#` + [`here`](https://github.com/0xPolygonID/tutorial-examples/blob/main/credential-schema/proof-of-dao-longevity-vocab.md#) - The field that we want to include inside the credential, defined together with its identifier and its data type (all xsd data type are available) @@ -124,7 +122,7 @@ This is a document that contains the serialization rule and the instruction for - Add the URIs to your specific `jsonLdContext` and `jsonSchema`: - Inside `CredentialSubject` update the information related to your field: -```json {6,7,109,117,118} +```json {6,7,82-93} { "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", diff --git a/docs/issuer/setup-issuer-core.md b/docs/issuer/setup-issuer-core.md index 20aef0d0..9f54435e 100644 --- a/docs/issuer/setup-issuer-core.md +++ b/docs/issuer/setup-issuer-core.md @@ -17,7 +17,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -This article details the steps to set up your own Issuer Node API. +This documentation provides comprehensive instructions for setting up your own Issuer Node API. :::caution @@ -29,36 +29,43 @@ Below is the installation guide for Issuer Node v3. ## Installation -For an advance configuration of the Issuer Node (RHS, Ethereum Identities and more), visit the [Advanced Issuer Node configuration](issuer-configuration.md#Advanced-Issuer-Node-configuration) guide. +For an advanced configuration of the Issuer Node (RHS, Ethereum Identities and more), visit the [Advanced Issuer Node configuration](issuer-configuration.md#Advanced-Issuer-Node-configuration) guide. -**You have to first [clone the repository](https://github.com/0xPolygonID/issuer-node).** +**Prerequisites: Clone the repository from [GitHub](https://github.com/0xPolygonID/issuer-node).** ## Docker Mode Guide ### Requirements -- [Docker Engine](https://docs.docker.com/engine/) 1.27 +- [Docker Engine](https://docs.docker.com/engine/) 1.27 or higher - Makefile toolchain - Unix-based operating system (e.g. Debian, Arch, Mac OS X) - [Go](https://go.dev/) version 1.19 or higher +:::note + +Make sure Docker daemon is running in your background + +::: + ### Issuer Node API Setup (basic configuration building docker images) Before you start, ensure the `resolvers_setting_sample.yaml` in the root directory. For information on configuration, see [Setting up networks and chains](issuer-configuration.md#Advanced-Issuer-Node-configuration) in Advanced Configuration guide. Follow these steps to get started: -1. Configure Environment File: +#### 1. Configure Environment File: Copy the sample configuration file: ```bash cp .env-issuer.sample .env-issuer +cp .env-ui.sample .env-ui ``` -2. Set Environment Variables +#### 2. Set Environment Variables - Fill in the `.env-issuer` config file to match your environment, especially the ISSUER_SERVER_URL and any other relevant variables. + Configure the `.env-issuer` config file to match your environment, especially the ISSUER_SERVER_URL and any other relevant variables. _.env-issuer_ @@ -66,7 +73,7 @@ cp .env-issuer.sample .env-issuer ISSUER_SERVER_URL= ``` -3. Key Management System (KMS) Setup +#### 3. Key Management System (KMS) Setup The Issuer Node supports multiple Key Management System (KMS) options for securely creating, signing, and managing private keys. Depending on your setup, you can choose one or more of the following options: @@ -77,7 +84,7 @@ cp .env-issuer.sample .env-issuer To configure your KMS, refer to the [sample .env-issuer file](https://github.com/0xPolygonID/issuer-node/blob/main/.env-issuer.sample#L21) and update your .env-issuer config file accordingly to your selected KMS. Detailed instructions and guidance on how to choose the right option for your use case can be found on the [KMS Configuration section](./issuer-configuration.md/#kms-configuration). -3. Import Ethereum Private Key +#### 4. Import Ethereum Private Key Import your Ethereum private key into the KMS provider you have configured. The associated account must be funded for state transitions. For Amoy network you can request some testing Matic [here](https://www.alchemy.com/faucets/polygon-amoy). @@ -85,20 +92,25 @@ cp .env-issuer.sample .env-issuer make private_key= import-private-key-to-kms ``` -4. Start the Issuer Node API +#### 5. Deploy the Issuer Node API Build and run the Issuer Node API: ```bash make up && make build-api && make run-api ``` -**Issuer Node API specification ** - The Issuer Node API will be accessible at: - >http://localhost:3001 or http://:3001 +### API Access + +**Issuer Node API Specification** +Upon successful deployment, the Issuer Node API will be accessible at: +**Local Environment:** +> http://localhost:3001 +**Production Environment:** +> http://:3001 --- diff --git a/docs/issuer/setup-issuer-ui.md b/docs/issuer/setup-issuer-ui.md index 28dc8aaa..1d70291d 100644 --- a/docs/issuer/setup-issuer-ui.md +++ b/docs/issuer/setup-issuer-ui.md @@ -17,7 +17,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -This article details the steps to achieve full integration of the Issuer Node with the Privado ID APIs, as well as instructs on how to set up an intuitive user interface to manage credentials. +This article provides comprehensive instructions for implementing full integration of the Issuer Node with the Privado ID APIs, including deployment of an intuitive user interface for credential management. :::caution @@ -27,24 +27,24 @@ The content of the QR code provided by the Issuer or Verifier has changed since ## Docker Mode Guide -**For either one, you first have to [clone the repository](https://github.com/0xPolygonID/issuer-node).** +**Prerequisites: Complete the repository cloning process before proceeding [GitHub](https://github.com/0xPolygonID/issuer-node).** ### Requirements -- Have followed the [Core-API Standalone Mode Guide](setup-issuer-core.md#standalone-mode-guide). +- Successful completion of the [Core-API Standalone Mode Guide](setup-issuer-core.md#standalone-mode-guide). ### Setup -1. Env file configuration, copy `ui.env.sample` as `.env-ui`: +1. Environment Configuration, copy `ui.env.sample` as `.env-ui`: -2. Run the Issuer Node UI: +2. Deploy the Issuer Node UI: ```bash make run-all ``` -> **UI** - http://localhost:8088 +> **Access Point** - http://localhost:8088 Upon launching the UI for the first time, you'll be prompted to enter the name and details of the identity for your issuer node. Please note that you can create and manage multiple identities for your issuer node through the UI at a later stage. diff --git a/docs/issuer/source-code.md b/docs/issuer/source-code.md index ecd8f59a..559d3ef2 100644 --- a/docs/issuer/source-code.md +++ b/docs/issuer/source-code.md @@ -5,7 +5,7 @@ sidebar_label: Source Code description: Important library links. keywords: - docs - - polygon id + - privado id - issuer node - claim - verifiable credentials diff --git a/docs/issuer/vault-auth.md b/docs/issuer/vault-auth.md index 66309f92..b47e1c9f 100644 --- a/docs/issuer/vault-auth.md +++ b/docs/issuer/vault-auth.md @@ -4,7 +4,7 @@ title: Issuer Node and Vault Authentication description: Learn the two options for authenticating with Vault in the Issuer Node. keywords: - docs - - polygon id + - privado id - issuer node - vault - authentication @@ -26,17 +26,23 @@ To employ this method, follow these steps: 1. Set the following environment variable in the `.env-issuer` file: - `ISSUER_VAULT_USERPASS_AUTH_ENABLED=false` + ```bash + ISSUER_VAULT_USERPASS_AUTH_ENABLED=false + ``` Another option is to remove the `ISSUER_VAULT_USERPASS_AUTH_ENABLED` entry from the file to get the default value (false) 2. Run the command below to add the Vault token to the `.env-issuer` configuration file: + ```bash `make add-vault-token` + ``` After step 2, the `.env-issuer` configuration file should contain an entry similar to this: -`ISSUER_KEY_STORE_TOKEN=hvs.HW8Qup9s6LBUA0ff8Q1TO6Uc` +```bash +ISSUER_KEY_STORE_TOKEN=hvs.HW8Qup9s6LBUA0ff8Q1TO6Uc +``` Finally, start or restart the issuer node to ensure it includes the change in the file. @@ -57,16 +63,25 @@ Upon Vault startup, an initialization script is executed. Among its tasks, it cr 1. Set the following environment variables in the `.env-issuer` file: - `ISSUER_VAULT_USERPASS_AUTH_ENABLED=true` - - `ISSUER_VAULT_USERPASS_AUTH_PASSWORD=issuernodepwd` + ```bash + ISSUER_VAULT_USERPASS_AUTH_ENABLED=true + ISSUER_VAULT_USERPASS_AUTH_PASSWORD=issuernodepwd + ``` 2. Restart the issuer node if necessary. You might want to change the password for the `issuernode` user. To do this, follow these steps: -1. Execute `make new_password=new_password change-vault-password` -2. Update the value of the environment variable in the `.env-issuer` file: `ISSUER_VAULT_USERPASS_AUTH_PASSWORD=new_password` +1. Execute +```bash +make new_password=new_password change-vault-password +``` + +2. Update the value of the environment variable in the `.env-issuer` file: +```bash +ISSUER_VAULT_USERPASS_AUTH_PASSWORD=new_password +``` + 3. Restart the issuer node if necessary. :::tip Which Option to Choose? diff --git a/docs/js-sdk/js-sdk-components/iden3comm.md b/docs/js-sdk/js-sdk-components/iden3comm.md index c2c5d884..9c6749fc 100644 --- a/docs/js-sdk/js-sdk-components/iden3comm.md +++ b/docs/js-sdk/js-sdk-components/iden3comm.md @@ -85,7 +85,7 @@ Click here for the