Merge pull request #132 from 0xPolygonID/develop

Update main from develop

.prettierignore

@@ -3,5 +3,6 @@
 
 # Except these files
 !docs
+!scripts
 !src
 !docusaurus.config.js

README.md

@@ -175,6 +175,26 @@ service:
 npm run build
 ```
 
+### Image Maintenance
+
+To enhance the flexibility of centering and sizing images within our markdown files, we often utilize HTML. However, this approach complicates image maintenance. We provide two scripts to facilitate the management of images in our projects.
+
+#### Finding Unused Images
+
+This utility script assists in identifying static images that are no longer referenced within our documentation. To leverage this script, execute the following command from the project's root directory:
+
+```bash
+node scripts/find-unused-images.js
+```
+
+#### Identifying Broken Image Links
+
+This script is designed to locate references to images within our documentation that lack corresponding files in the static folder. To use this script, run the following command from the project's root directory:
+
+```bash
+node scripts/find-broken-image-links.js
+```
+
 ## Deployment
 
 If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the 

docs/faqs/content/issuer-node-404-error-verifying-credential.md

@@ -0,0 +1,160 @@
+---
+id: issuer-node-404-error-verifying-credential
+title: "Resolving Mobile App Credential Verification 404 Error"
+sidebar_label: Mobile App Verification 404 Error
+description: Explains how to address the 404 error encountered in the mobile app wallet during credential verification with the issuer node. Provides steps to ensure a stable URL and to update the issuer node URL in the database.
+keywords:
+  - faq
+  - issuer-node
+  - mobile app
+  - credential verification
+  - ngrok
+  - database update
+  - pgAdmin
+---
+
+import useBaseUrl from '@docusaurus/useBaseUrl';
+
+## Question
+
+Why am I encountering this error in the mobile app wallet while verifying a credential issued from my issuer node, and how can I resolve it?
+
+```
+Error creating proof: [AuthenticateUseCase] error: status is not OK with code 0: unexpected status code: 404
+```
+
+## Answer
+
+The "unexpected status code: 404" error during credential verification typically stems from the URL stored in the `authCoreClaim` being unavailable. This situation arises when the URL of the issuer node used during the creation of the issuer's identity is no longer accessible, thus hindering the revocation status check required for generating the proof.
+
+To determine if this is the root cause of the error you are encountering, perform the following check:
+
+Retrieve the problematic credential using the core API of the issuer node, which operates on port 3001. The endpoint format is:
+
+```
+GET /v1/{identifier}/claims/{id}
+```
+
+Here, `{identifier}` is the DID of the issuer node, and `{id}` is the ID of the credential within the database.
+
+:::note
+
+The issuer node's DID can be retrieved by executing the command `make print-did`.
+
+:::
+
+:::note
+
+Authenticate with this API using the credentials found in the `ISSUER_API_AUTH_USER` and `ISSUER_API_AUTH_PASSWORD` environment variables.
+
+:::
+
+The returned claim from this API endpoint provides detailed information, including the URL of the issuer node at the time the issuer's identity was established. This typically corresponds to the initial setup of the issuer node, involving the creation of the `authCoreClaim` credential, the issuer DID, and the genesis state of the issuer identity.
+
+Locate this URL within the JSON response at `proof[0].issuerData.credentialStatus.id`.
+
+If this URL is no longer operational, proceed with the following instructions. If not, the issue may differ.
+
+### Ensuring a Stable URL
+
+First and foremost, ensure your issuer node has a stable URL. Services like ngrok or localtunnel often change URLs with each session, which can cause this issue. If utilizing ngrok, setting up a [custom domain](https://ngrok.com/docs/guides/how-to-set-up-a-custom-domain) is advisable for consistency.
+
+### Manually Updating the URL in the Database
+
+:::note
+
+Manually updating the URL of the credentials in the database is not a straightforward process. For development or testing purposes, it might be simpler to recreate the issuer node's identity and start from scratch. This can be accomplished by removing and restarting the Docker containers. However, be advised that this approach **will erase all existing data**.
+
+:::
+
+To manually update the URL in existing credentials, particularly if using Docker, follow these detailed steps:
+
+1. Launch a pgAdmin container for UI-based interaction:
+
+```bash
+docker run -p 8080:80 --network=issuer-network -e "PGADMIN_DEFAULT_EMAIL=mail@mail.com" -e "PGADMIN_DEFAULT_PASSWORD=password" --name pgadmin_container -d dpage/pgadmin4
+```
+
+2. Navigate to `http://localhost:8080` in your browser and log in with the provided credentials (`mail@mail.com`/`password`).
+
+3. Within the dashboard, opt to "Add New Server".
+
+<div align="center">
+    <img src={useBaseUrl("img/faqs/issuer-node-pgadmin-01.png")} width="600px" />
+</div>
+
+4. Name it "Issuer Node".
+
+<div align="center">
+    <img src={useBaseUrl("img/faqs/issuer-node-pgadmin-02.png")} width="600px" />
+</div>
+
+5. In the "Connection" tab, input the necessary details and confirm by clicking "Save".
+
+<div align="center">
+    <img src={useBaseUrl("img/faqs/issuer-node-pgadmin-03.png")} width="600px" />
+</div>
+
+6. On the tree to the left, explore the nodes to `Servers > Issuer Node > Databases > platformid > Schemas > public > Tables`, right-click the `claims` table, and choose "View/Edit Data > All Rows".
+
+<div align="center">
+    <img src={useBaseUrl("img/faqs/issuer-node-pgadmin-04.png")} width="600px" />
+</div>
+
+7. Locate the `credential_status` column in the loaded credentials (claims). This column contains a JSON value.
+
+<div align="center">
+    <img src={useBaseUrl("img/faqs/issuer-node-pgadmin-05.png")} width="900px" />
+</div>
+
+8. Identify the credential with the `revocationNonce` of `0` (the `authCoreClaim` credential). Modify the URL within the `id` property of the JSON to the new domain of your issuer node.
+
+<div align="center">
+    <img src={useBaseUrl("img/faqs/issuer-node-pgadmin-06.png")} width="600px" />
+</div>
+
+9. Confirm the update by clicking "Ok" and save the alterations to apply the updated issuer node URL.
+
+<div align="center">
+    <img src={useBaseUrl("img/faqs/issuer-node-pgadmin-07.png")} width="300px" />
+</div>
+
+By following these steps, new credentials issued will utilize the updated issuer node URL. Note that previously issued credentials will need their URLs updated individually to resolve any verification issues.
+
+### Updating the Issuer URL in Database Records
+
+For those comfortable with direct database manipulation, the issuer node URL within existing credentials can be updated using a SQL command. This method is particularly useful if you have a large number of credentials that need updating to a new issuer node URL. Here is the SQL command to perform this update:
+
+```sql
+UPDATE claims
+SET credential_status = jsonb_set(credential_status, '{id}', ('"' || regexp_replace(credential_status ->> 'id', '^https://123456', 'https://0.0.0.0') || '"')::jsonb)
+WHERE jsonb_extract_path_text(credential_status, 'id') LIKE 'https://123456/%' AND identifier = 'myDID';
+```
+
+In this command:
+
+- `https://123456` represents the old URL to be replaced.
+- `https://0.0.0.0` is the new URL you're updating to.
+- `myDID` should be replaced with the actual DID of the issuer whose credentials you're updating.
+
+This SQL command specifically targets the `credential_status` JSONB column within the `claims` table, replacing the old URL with the new one only in records where the `id` field of the `credential_status` matches the specified pattern and belongs to the specified issuer DID.
+
+:::warning
+
+Direct manipulation of database records can lead to data integrity issues if not performed carefully. Ensure you have backups or other recovery methods available before executing direct database updates.
+
+:::
+
+### Recommendations
+
+- **Stable URL**: Secure a stable URL for your issuer node to prevent similar issues in the future.
+- **Database Caution**: Directly modifying database entries should be done with caution to avoid unintended data corruption.
+
+For further assistance or if you encounter additional challenges, do not hesitate to seek help from the support team.
+
+<div className="hidden">
+Wrong answer:
+
+To resolve the "unexpected status code: 404" error, simply retry the verification process until it succeeds, without needing to check or update the issuer node's URL in the database or reconsider the stability of your ngrok setup.
+
+</div>

docs/faqs/content/verifier-on-chain-verification-custom-event.md

@@ -0,0 +1,55 @@
+---
+id: verifier-on-chain-verification-custom-event
+title: "Detecting Completion of On-Chain Verification in Frontend"
+sidebar_label: On-Chain Verification Event
+description: Explains how to determine the completion of on-chain verification from the frontend, highlighting the use of custom events in smart contracts.
+keywords:
+  - faq
+  - on-chain verification
+  - smart contract
+  - frontend
+  - callback method
+  - events
+---
+
+## Question
+
+After successfully creating my smart contract for on-chain verification and verifying my credential on-chain, how can I know if the verification is completed from the frontend? Is there any callback method for on-chain verification?
+
+## Answer
+
+By default, validators in the smart contract do not trigger any events to signal the completion of on-chain verification. To address this from a frontend perspective, you can enhance your smart contract by incorporating custom events. These events can be emitted in the `_afterProofSubmit` hook of your contract.
+
+Here’s a brief guide on implementing and utilizing this approach:
+
+1. **Modify Your Smart Contract**: Add a custom event in your contract that fires upon successful completion of the `_afterProofSubmit` hook. For example:
+
+   ```solidity
+   event VerificationCompleted(bool verified);
+
+   function _afterProofSubmit(...) internal override {
+       ...
+       emit VerificationCompleted(true);
+   }
+   ```
+
+2. **Listen for the Event in Frontend**: In your frontend application, use web3.js, ethers.js, or a similar library to listen for the specific event emitted by your contract. You'll need to specify the contract address and the event signature.
+
+   ```javascript
+   myContract.on("VerificationCompleted", (verified) => {
+     if (verified) {
+       console.log("Verification completed successfully.");
+     }
+   });
+   ```
+
+This method allows your frontend to asynchronously receive a notification when the on-chain verification process has concluded, enabling you to take further actions or update the UI accordingly.
+
+Remember, you will need to listen for events on the specific contract address involved in the verification process, ensuring your frontend is dynamically updated based on the contract's activity.
+
+<div className="hidden">
+Wrong answer:
+
+There's no way for a smart contract to notify other actors such as a frontend about a successful on-chain verification process. The only method to determine the completion of on-chain verification is by repeatedly querying the contract's state (polling).
+
+</div>

docs/faqs/faqs.md

@@ -32,6 +32,7 @@ keywords:
 - [<span className="faq-link">Error: Issuer DID Does Not Exist in the Database</span>](./content/issuer-node-error-the-issuer-did-does-not-exist-in-the-database.md)
 - [<span className="faq-link">Error: Cannot Get Issuer DID from Vault</span>](./content/issuer-node-error-cannot-get-did-from-vault.md)
 - [<span className="faq-link">Error: Getting Identity by DID, No Rows in Result Set</span>](./content/issuer-node-error-no-identity-by-did-no-rows-in-result-set.md)
+- [<span className="faq-link">Resolving Mobile App Credential Verification 404 Error</span>](./content/issuer-node-404-error-verifying-credential.md)
 
 ## Verifiers
 
@@ -41,6 +42,7 @@ keywords:
 
 - [<span className="faq-link">Understanding Gas Fees for On-Chain Verification</span>](./content/verifier-on-chain-verification-gas-costs.md)
 - [<span className="faq-link">Data Management for On-Chain Credential Verification</span>](./content/verifier-on-chain-verification-data-storage.md)
+- [<span className="faq-link">Detecting Completion of On-Chain Verification in Frontend</span>](./content/verifier-on-chain-verification-custom-event.md)
 
 ## Wallets
 

docs/introduction.md

@@ -16,7 +16,7 @@ keywords:
 import useBaseUrl from '@docusaurus/useBaseUrl';
 
 <div align="center">
-<img src={useBaseUrl('/img/logo.svg')} align="center" width="128px"/>
+<img src={useBaseUrl("img/logo.svg")} align="center" width="128px"/>
 <br /><br />
 </div>
 

docs/issuer-node/issuer-node-api/agent/apis.md

@@ -106,5 +106,3 @@ A typical response looks like this:
 ```
 
 <a href="https://self-hosted-platform.polygonid.me/#post-/v1/agent" target="_blank">API Reference</a>
-
-[![Run in Postman](https://run.pstmn.io/button.svg)](https://www.postman.com/dark-star-200015/workspace/public/request/23322631-2a66c833-a76e-4486-8ef6-b78a09ff65d2)

docs/issuer-node/issuer-node-api/claim/apis.md

@@ -50,8 +50,6 @@ The Issuer Node responds by sending a response message that contains the string
 
 <a href="https://self-hosted-platform.polygonid.me/#post-/v1/-identifier-/claims" target="_blank">API Reference</a>
 
-[![Run in Postman](https://run.pstmn.io/button.svg)](https://www.postman.com/dark-star-200015/workspace/public/request/23322631-f7c15972-bb5c-4614-974a-c18e367839a6)
-
 ## Get Claim
 
 **Function**: endpoint to retrieve a Verifiable Credential based on its Claim ID (CID). This way, you can retrieve a credential issued by an Issuer based on this credential's ID.
@@ -91,8 +89,6 @@ The server responds by sending the following data about the Verifiable Credentia
 
 <a href="https://self-hosted-platform.polygonid.me/#get-/v1/-identifier-/claims/-id-" target="_blank">API Reference</a>
 
-[![Run in Postman](https://run.pstmn.io/button.svg)](https://www.postman.com/dark-star-200015/workspace/public/request/23322631-dbfc361b-fc11-4a2f-ad0f-420c64bbfb58)
-
 ## Get Claims
 
 **Function**: endpoint to retrieve all the Verifiable Credentials issued by an Issuer.
@@ -148,8 +144,6 @@ The Issuer Node responds by sending a response message that contains the Verifia
 
 <a href="https://self-hosted-platform.polygonid.me/#get-/v1/-identifier-/claims" target="_blank">API Reference</a>
 
-[![Run in Postman](https://run.pstmn.io/button.svg)](https://www.postman.com/dark-star-200015/workspace/public/request/23322631-cd69b428-9659-4e82-87c7-c2012f04327b)
-
 ## Get Claim QR Code
 
 :::note
@@ -178,8 +172,6 @@ This JSON can then be pasted on a third-party app's interface that supports gene
 
 <a href="https://self-hosted-platform.polygonid.me/#get-/v1/-identifier-/claims/-id-/qrcode" target="_blank">API Reference</a>
 
-[![Run in Postman](https://run.pstmn.io/button.svg)](https://www.postman.com/dark-star-200015/workspace/public/request/23322631-258a68a6-6301-454b-84c2-62219748def3)
-
 ## Revoke Claim
 
 **Function**: endpoint to revoke a Verifiable Credential
@@ -190,8 +182,6 @@ The server responds by showing the Revocation Status of the credential.
 
 <a href="https://self-hosted-platform.polygonid.me/#post-/v1/-identifier-/claims/revoke/-nonce-" target="_blank">API Reference</a>
 
-[![Run in Postman](https://run.pstmn.io/button.svg)](https://www.postman.com/dark-star-200015/workspace/public/request/23322631-a038c968-9e13-4e41-8364-a91e747cc871)
-
 ## Get Revocation Status
 
 **Function**: endpoint to retrieve the Revocation Status of the Verifiable Credential.
@@ -207,5 +197,3 @@ The server responds by sending the following details:
   - `existence`: Existence or Non-existence of the Revocation Nonce on the Revocation Merkle Tree. For retrieving the revocation status from this endpoint, we need to first send a transaction and after that, the state is published on-chain. Once that is done, the existence of the revocation nonce on Merkle Tree changes to "true".
 
 <a href="https://self-hosted-platform.polygonid.me/#get-/v1/-identifier-/claims/revocation/status/-nonce-" target="_blank">API Reference</a>
-
-[![Run in Postman](https://run.pstmn.io/button.svg)](https://www.postman.com/dark-star-200015/workspace/public/request/23322631-474c51a2-b026-4750-9bc7-488bc52c02ce)

docs/issuer-node/issuer-node-api/identity/apis.md

@@ -91,8 +91,6 @@ For each call to the `Create Identity`, a random Identifier is created.
 
 <a href="https://self-hosted-platform.polygonid.me/#post-/v1/identities" target="_blank">API Reference</a>
 
-[![Run in Postman](https://run.pstmn.io/button.svg)](https://www.postman.com/dark-star-200015/workspace/public/request/23322631-ccf43950-f7a6-4155-a54b-4755d92f0b48)
-
 ## Get Identities
 
 **Function**: Endpoint to retrieve all the identities (identifiers) of a user.
@@ -107,8 +105,6 @@ The Issuer Node responds by sending a response message that contains:
 
 <a href="https://self-hosted-platform.polygonid.me/#get-/v1/identities" target="_blank">API Reference</a>
 
-[![Run in Postman](https://run.pstmn.io/button.svg)](https://www.postman.com/dark-star-200015/workspace/public/request/23322631-793c9e52-cdfa-423a-8b42-62b6b05d8e8c)
-
 ## Publish State On-Chain
 
 **Function**: Endpoint to publish the [Identity State](https://docs.iden3.io/getting-started/identity/identity-state/) on-chain.
@@ -128,5 +124,3 @@ The Issuer Node responds by sending a response message that indicates the publis
 - `txID`: transaction ID of the Published state on-chain. For example, 0xaed59e4195e73ee6c4278be1a5e01ecbdf2ff9565511916200dedda9bb20ff38
 
 <a href="https://self-hosted-platform.polygonid.me/#post-/v1/-identifier-/state/publish" target="_blank">API Reference</a>
-
-[![Run in Postman](https://run.pstmn.io/button.svg)](https://www.postman.com/dark-star-200015/workspace/public/request/23322631-e193e1e1-a740-4c3c-b74c-4696496e0e1e)