diff --git a/docs/issuer/cred-issue-methods.md b/docs/issuer/cred-issue-methods.md
index b0d9be04..7ae38d96 100644
--- a/docs/issuer/cred-issue-methods.md
+++ b/docs/issuer/cred-issue-methods.md
@@ -32,7 +32,7 @@ There are two ways those credentials can be issued: using **BJJ key Signature**
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.
-
+
### MTP Method: Issuance of Credentials with Merkle Tree Proof
@@ -42,5 +42,5 @@ The validation of the proof is done against the state published on-chain. No per
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.
-
+
\ No newline at end of file
diff --git a/docs/issuer/issuer-overview.md b/docs/issuer/issuer-overview.md
index f1e61b4a..d9f0230b 100644
--- a/docs/issuer/issuer-overview.md
+++ b/docs/issuer/issuer-overview.md
@@ -24,7 +24,7 @@ An issuer might be:
:::info
-[Verifiable Credentials](https://www.w3.org/TR/vc-data-model/) are a flexible data format able to express any type of information so that developers can unleash their creativity.
+[
Verifiable Credentials](https://www.w3.org/TR/vc-data-model/) are a flexible data format able to express any type of information so that developers can unleash their creativity.
:::
diff --git a/docs/issuer/on-chain-issuer/on-chain-overview.md b/docs/issuer/on-chain-issuer/on-chain-overview.md
index 4994eda9..a95ab09a 100644
--- a/docs/issuer/on-chain-issuer/on-chain-overview.md
+++ b/docs/issuer/on-chain-issuer/on-chain-overview.md
@@ -26,7 +26,7 @@ In simple words, you can see everything happening: all the logic used to generat
:::info
-An On-chain Issuer, in fact, is a special case of the On-chain Identity. You can find more information about it on the [Iden3 documentation](https://docs.iden3.io/getting-started/identity/onchain-identity/).
+An On-chain Issuer, in fact, is a special case of the On-chain Identity. You can find more information about it on the [
Iden3 documentation](https://docs.iden3.io/getting-started/identity/onchain-identity/).
:::
diff --git a/docs/issuer/on-chain-issuer/on-chain-tutorial.md b/docs/issuer/on-chain-issuer/on-chain-tutorial.md
index 7ea39841..4bf7ae22 100644
--- a/docs/issuer/on-chain-issuer/on-chain-tutorial.md
+++ b/docs/issuer/on-chain-issuer/on-chain-tutorial.md
@@ -61,7 +61,7 @@ Currently, the state contract on the mainnet does not support onchain issuers. P
:::note
- You can find more information on how to deploy a smart contract using Hardhat [in this readme](https://github.com/iden3/contracts#readme).
+ You can find more information on how to deploy a smart contract using Hardhat [
in this readme](https://github.com/iden3/contracts#readme).
:::
@@ -86,8 +86,8 @@ Currently, the state contract on the mainnet does not support onchain issuers. P
Don't forget to download and install the Polygon ID wallet app before you go the next steps.
-- For Android:
Polygon ID on Google Play
-- For iOS:
Polygon ID on the App Store
+- For Android:
Polygon ID on Google Play
+- For iOS:
Polygon ID on the App Store
:::
diff --git a/docs/issuer/schema-builder.md b/docs/issuer/schema-builder.md
index bc417ee1..16127d03 100644
--- a/docs/issuer/schema-builder.md
+++ b/docs/issuer/schema-builder.md
@@ -92,7 +92,7 @@ The first page of the Schema Builder flow lets you define the basic aspects of t
- Title: a name for the schema.
-- Schema Type: a set of attributes used to shape the data stored in one credential.
+- 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.
diff --git a/docs/issuer/schema.md b/docs/issuer/schema.md
index 9a891fb5..e2380eb7 100644
--- a/docs/issuer/schema.md
+++ b/docs/issuer/schema.md
@@ -17,7 +17,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/).
+Polygon ID offers an intuitive, user-friendly interface to create schemas: the Schema Builder. [
@@ -69,7 +69,7 @@ This demo is using Polygon's Mumbai testnet. Go to the gear icon at the top righ
## Issue a new credential to attest to the ID Holder's event attendance
A trusted entity, for instance, a private institution will now play the role of an issuer. It will be responsible for creating the credential and sending it to the ID Holder.
-We are using a testing environment to manage credentials: [https://issuer-ui.polygonid.me](https://issuer-ui.polygonid.me). This is the place where the trusted entity can create credentials, manage schemas and generate connections.
+We are using
the Issuer Node UI testing environment to manage credentials. This is the place where the trusted entity can create credentials, manage schemas and generate connections.
However, if you are using a new credential type, you actually need to create a schema for that credential, which basically is the set of JSON files that gather all the attributes of that specific credential.
@@ -82,28 +82,26 @@ To facilitate this issuance process, we have already created the credential sche
:::note
-To learn how to set up your own issuer environment by deploying an issuer node, visit the [Issuer section in the documentation](./issuer/issuer-overview.md).
+To learn how to set up your own issuer environment by deploying an issuer node, visit the [
Issuer section in the documentation](./issuer/issuer-overview.md).
:::
:::info
-Learn more about creating new schemas on the [Schema Builder UI guide](./issuer/schema-builder.md)
+The schema used in this demo was built using the Polygon ID Schema Builder and is available on [
the Polygon ID Schema Explorer](https://schema-builder.polygonid.me/schemas/1fa99457-b2ae-4884-ae12-d658bd6abf69). Learn more about creating new schemas on [
the Schema Builder UI guide](https://devs.polygonid.com/docs/issuer/schema-builder/).
:::
### Issue the credential
With the new schema in hand, the issuer should now be able to generate a credential.
-1. First, go to the [Issuer Node UI testing environment](https://issuer-ui.polygonid.me).
-
- Provide the following login data:
+1. First, go to the
the Issuer Node UI testing environment.
- - user: `user-ui`
- - password: `password-ui`
+ :::warning
+
+ This Issuer Node is publicly available and used only for testing purposes. Do not use personal or sensitive data. All data is deleted every 48 hours.
- !!!warning
- This Issuer Node is publicly available and used only for testing purposes. Do not use personal or sensitive data. All data is deleted every 48 hours.
+ :::
2. Now you need to import the schema. Click on **Import Schema** and paste our previously generated schema IPFS address `ipfs://QmTSwnuCB9grYMB2z5EKXDagfChurK5MiMCS6efrRbsyVX`:
diff --git a/docs/releases.md b/docs/releases.md
index 5ae1b0dc..df534cdf 100644
--- a/docs/releases.md
+++ b/docs/releases.md
@@ -15,6 +15,6 @@ keywords:
You can find release data about each of Polygon ID's products on the following links:
-Flutter SDK [https://github.com/0xPolygonID/polygonid-flutter-sdk/releases](https://github.com/0xPolygonID/polygonid-flutter-sdk/releases)
-Issuer Node: [https://github.com/0xPolygonID/issuer-node/releases](https://github.com/0xPolygonID/issuer-node/releases)
-JS-SDK: [https://github.com/0xPolygonID/js-sdk/releases](https://github.com/0xPolygonID/js-sdk/releases)
+- Flutter SDK [https://github.com/0xPolygonID/polygonid-flutter-sdk/releases](https://github.com/0xPolygonID/polygonid-flutter-sdk/releases)
+- Issuer Node: [https://github.com/0xPolygonID/issuer-node/releases](https://github.com/0xPolygonID/issuer-node/releases)
+- JS-SDK: [https://github.com/0xPolygonID/js-sdk/releases](https://github.com/0xPolygonID/js-sdk/releases)
diff --git a/docs/smart-contracts.md b/docs/smart-contracts.md
index 06d30c20..19a54725 100644
--- a/docs/smart-contracts.md
+++ b/docs/smart-contracts.md
@@ -14,7 +14,7 @@ keywords:
## Blockchain addresses
-For situations where one needs to publish data on the blockchain, such as creating a mtp-type credential, generating on-chain proofs and make credential revocations effective, it is important to have the Smart Contracts addresses:
+For situations where one needs to publish data on the blockchain, such as creating an MTP-type credential, generating on-chain proofs and making credential revocations effective, it is important to have the following Smart Contracts addresses:
- Testnet(mumbai) -> `0x134B1BE34911E39A8397ec6289782989729807a4`
- Mainnet -> `0x624ce98D2d27b20b8f8d521723Df8fC4db71D79D`
@@ -28,7 +28,7 @@ Current addresses on Polygon Mumbai testnet.
| ERC20 examples |0x9017a99afb69CB7B21C7DD29827b4762DECD53FD |0x3Bf7f4774DC3f92431fA690fa000f636562dCC18 |
-Current addresses on Polygon Main. (ERC20 example with airdrop use case, restricted to 1 request).
+Current addresses on Polygon Mainnet (ERC20 example with airdrop use case, restricted to 1 request).
| | Sig | MTP |
|:------------------:|:------------------------------------------:|:-----------------------------------------:|
diff --git a/docs/verifier/demo-verifier.md b/docs/verifier/demo-verifier.md
index 3b5452f7..8d191cc4 100644
--- a/docs/verifier/demo-verifier.md
+++ b/docs/verifier/demo-verifier.md
@@ -24,7 +24,7 @@ Download the Polygon ID Wallet App and create an Identity.
- For Android:
Polygon ID on Google Play
- For iOS:
Polygon ID on the App Store
-- Have the queried credential inside your wallet. For the tutorial, we are using the `ProofOfDaoLongevity` that can be created via the [Demo Issuer](https://issuer-ui.polygonid.me/).
+- Have the queried credential inside your wallet. For the tutorial, we are using the `ProofOfDaoLongevity` that can be created via
the Issuer Node UI testing environment.
## Quick Start
@@ -42,7 +42,7 @@ Download the Polygon ID Wallet App and create an Identity.
The editor allows you to design the query that the user will have to satisfy. The query is created by selecting the credential type and the attribute that you want to query. More info on how to design a query is described via the [ZK Query Language](./verification-library/zk-query-language.md).
In this example, we are querying the date of entry of the user inside a DAO. In particular, we want to make sure that the user joined the DAO before a specific date.
- This query is based on the `ProofOfDaoLongevity` credential type described by this [JSON-LD Context](https://github.com/0xPolygonID/tutorial-examples/blob/main/credential-schema/proof-of-dao-longevity.json-ld).
+ This query is based on the `ProofOfDaoLongevity` credential type described by this [JSON-LD Context](https://github.com/0xPolygonID/tutorial-examples/blob/main/credential-schema/proof-of-dao-longevity.jsonld).
diff --git a/docs/verifier/on-chain-verification/overview.md b/docs/verifier/on-chain-verification/overview.md
index b8aec94e..c00a091e 100644
--- a/docs/verifier/on-chain-verification/overview.md
+++ b/docs/verifier/on-chain-verification/overview.md
@@ -49,7 +49,7 @@ In this tutorial, we will create an ERC20 ZK Airdrop Contract. The chosen query
:::note
-To set up a different query check out the [ZK Query Language section](/docs/verifier/verification-library/zk-query-language.md).
+To set up a different query check out the [
ZK Query Language section](/docs/verifier/verification-library/zk-query-language.md).
:::
@@ -202,7 +202,7 @@ The contract is now fully written!
:::note "Hardhat"
-For this tutorial, we are using the Hardhat development environment to facilitate the contract deployment. You can learn how to get started with this tool by checking [their documentation](https://hardhat.org/hardhat-runner/docs/getting-started).
+For this tutorial, we are using the Hardhat development environment to facilitate the contract deployment. You can learn how to get started with this tool by checking [
their documentation](https://hardhat.org/hardhat-runner/docs/getting-started).
:::
@@ -247,7 +247,7 @@ npx hardhat run polygon-mumbai scripts/deploy.js
### Set the ZKP Request
-The actual ZKP request "to be born before 01/01/2002" hasn't been added to the Smart Contract yet. To do so it is necessary to call
`setZKPRequest` function inherited inside the ERC20Verifier which takes 6 inputs:
+The actual ZKP request "to be born before 01/01/2002" hasn't been added to the Smart Contract yet. To do so it is necessary to call
setZKPRequest function inherited inside the ERC20Verifier which takes 6 inputs:
1. `requestId`: the ID associated with the request.
2. `validator`: the address of the
Validators Smart Contract already deployed on Mumbai. This is the contract that executes the verification on the ZK proof submitted by the user. It can be of type [CredentialAtomicQuerySigValidator](/docs/contracts/overview.md#credentialatomicquerysigvalidator) or [CredentialAtomicQueryMTPValidator](/docs/contracts/overview.md#credentialatomicquerymtpvalidator).
@@ -258,7 +258,7 @@ The actual ZKP request "to be born before 01/01/2002" hasn't been added to the S
:::info
-Check out our [Smart Contract section](/docs/contracts/overview.md) to learn more about the set of verifications executed on the zk proof.
+Check out our [
Smart Contract section](/docs/contracts/overview.md) to learn more about the set of verifications executed on the zk proof.
:::
@@ -366,7 +366,7 @@ The last step is to design the proof request to be embedded inside a QR code. In
Note that the request resembles, in most of its parts, the one designed for [off-chain verification](/docs/verifier/verification-library/request-api-guide.md). The extra part that has been added here is the `transcation_data` that includes:
- `contract_address`, namely the address of the Verifier contract, in this case, ERC20Verifier.
-- `method_id`, namely the [Function Selector](https://solidity-by-example.org/function-selector/) of the
`submitZKPResponse` function.
+- `method_id`, namely the [Function Selector](https://solidity-by-example.org/function-selector/) of the
submitZKPResponse function.
- `chain_id`, the ID of the chain where the Smart Contract has been deployed.
- `network`, the name of the network where the Smart contract has been deployed.
@@ -398,7 +398,7 @@ Or you can directly test it by scanning the QR Code below using your Polygon ID
### How is the proof submission executed?
-The wallet needs to call the `submitZKPResponse()` function before it can submit the proof for the requirements set in the Airdrop Participation process. This function forms part of the ZKPVerifier Interface [`IZKPVerifier`](https://github.com/iden3/contracts/blob/master/contracts/interfaces/IZKPVerifier.sol#L7) and is actually implemented inside the [`ZKPVerifier Contract`](https://github.com/iden3/contracts/blob/master/contracts/ZKPVerifier.sol#L21).
+The wallet needs to call the `submitZKPResponse()` function before it can submit the proof for the requirements set in the Airdrop Participation process. This function forms part of the ZKPVerifier Interface [IZKPVerifier](https://github.com/iden3/contracts/blob/master/contracts/interfaces/IZKPVerifier.sol#L7) and is actually implemented inside the [ZKPVerifier Contract](https://github.com/iden3/contracts/blob/master/contracts/ZKPVerifier.sol#L21).
```solidity
import "./ICircuitValidator.sol";
diff --git a/docs/verifier/verification-library/request-api-guide.md b/docs/verifier/verification-library/request-api-guide.md
index 36a4f52a..8b1daa00 100644
--- a/docs/verifier/verification-library/request-api-guide.md
+++ b/docs/verifier/verification-library/request-api-guide.md
@@ -55,7 +55,7 @@ const request : protocol.AuthorizationRequestMessage = auth.createAuthorizationR
:::info
-An example of the usage of this API can be found [here](https://github.com/0xPolygonID/tutorial-examples/blob/main/verifier-integration/go/index.go#L41)(GO) and [here](https://github.com/0xPolygonID/tutorial-examples/blob/main/verifier-integration/js/index.js#L39)(JS).
+An example of the usage of this API can be found
[here](https://github.com/0xPolygonID/tutorial-examples/blob/main/verifier-integration/go/index.go#L41)(GO) and
[here](https://github.com/0xPolygonID/tutorial-examples/blob/main/verifier-integration/js/index.js#L39)(JS).
:::
@@ -167,18 +167,18 @@ mtpProofRequest.Query = map[string]interface{}{
:::info
-An example of the usage of this API can be found [here](https://github.com/0xPolygonID/tutorial-examples/blob/main/verifier-integration/go/index.go#L47) (GO) and [here](https://github.com/0xPolygonID/tutorial-examples/blob/main/verifier-integration/js/index.js#L49) (JS).
+An example of the usage of this API can be found
[here](https://github.com/0xPolygonID/tutorial-examples/blob/main/verifier-integration/go/index.go#L47) (GO) and
[here](https://github.com/0xPolygonID/tutorial-examples/blob/main/verifier-integration/js/index.js#L49) (JS).
:::
:::info
-Check out our [Query Language guide](./zk-query-language.md) to design any type of query request you can think of!
+Check out our [
Query Language guide](./zk-query-language.md) to design any type of query request you can think of!
:::
:::info
-Check out the [Iden3Comm](/docs/wallet/wallet-sdk/polygonid-sdk/iden3comm/overview.md) section inside the Wallet SDK to learn more about how these requests are interpreted by the wallet in order to generate a zk proof.
+Check out the [
Iden3Comm](/docs/wallet/wallet-sdk/polygonid-sdk/iden3comm/overview.md) section inside the Wallet SDK to learn more about how these requests are interpreted by the wallet in order to generate a zk proof.
:::
diff --git a/docs/verifier/verification-library/verification-api-guide.md b/docs/verifier/verification-library/verification-api-guide.md
index ca1e1c01..44b42321 100644
--- a/docs/verifier/verification-library/verification-api-guide.md
+++ b/docs/verifier/verification-library/verification-api-guide.md
@@ -19,13 +19,6 @@ keywords:
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
-
-
-
-
-
-
-
After having presented a [Request](./request-api-guide.md) to the user's wallet, the wallet will process the request and generate a proof that is sent back to the Verifier.
The proof must be verified in order to authenticate the user.
Let us see how to execute this verification.
diff --git a/docs/verifier/verification-library/verifier-set-up.md b/docs/verifier/verification-library/verifier-set-up.md
index a62fb2ef..a4d77c3a 100644
--- a/docs/verifier/verification-library/verifier-set-up.md
+++ b/docs/verifier/verification-library/verifier-set-up.md
@@ -20,8 +20,8 @@ Any application that wants to authenticate users based on their Polygon ID Ident
The Server generates [the ZK Request](./request-api-guide.md) according to the requirements of the platform. There are two types of authentication:
-- [**Basic Auth**](./request-api-guide.md#basic-auth): for example, a platform that issues Credentials must authenticate users by their identifiers before sharing Credentials with them.
-- [**Query-based Auth**](./request-api-guide.md#query-based-auth): for example, a platform that gives access only to those users that are over 18 years of age.
+- [**Basic Auth**](./request-api-guide.md#basic-auth-request): for example, a platform that issues Credentials must authenticate users by their identifiers before sharing Credentials with them.
+- [**Query-based Auth**](./request-api-guide.md#query-based-auth-request): for example, a platform that gives access only to those users that are over 18 years of age.
The second role of the Server is to execute [Verification](./verification-api-guide.md) of the proof sent by the Identity Wallet.
@@ -70,7 +70,8 @@ Initiate a server that contains two endpoints:
-```go
+
+```go
package main
import(
@@ -129,6 +130,7 @@ app.listen(port, () => {
const requestMap = new Map();
```
+
@@ -140,6 +142,7 @@ This endpoint generates the auth request for the user. Using this endpoint, the
+
```go {11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}
@@ -250,7 +253,7 @@ When we use `*` in the "allowed issuers" segment (`allowedIssuers: ['*']`), we m
:::note
-The highlighted lines are to be added only if the authentication needs to design a [query](./zk-query-language.md) for a specific proof as in the case of [Query-based Auth](./request-api-guide.md#query-based-auth). When not included, it will perform a [Basic Auth](./request-api-guide.md#basic-auth).
+The highlighted lines are to be added only if the authentication needs to design a [query](./zk-query-language.md) for a specific proof as in the case of [Query-based Auth](./request-api-guide.md#query-based-auth). When not included, it will perform a [Basic Auth](./request-api-guide.md#basic-auth).
:::
@@ -287,7 +290,7 @@ A Verifier can work with multiple networks simultaneously. Even users and issuer
:::note
-The public verification keys for Iden3 circuits generated after the trusted setup can be found here and must be added to your project inside a folder called `keys`.
+The public verification keys for Iden3 circuits generated after the trusted setup can be found here and must be added to your project inside a folder called `keys`.
:::
@@ -592,6 +595,7 @@ console.log('Express server is running on port 3000');
+
**Implement Further Logic**
diff --git a/docs/verifier/verification-library/zk-query-language.md b/docs/verifier/verification-library/zk-query-language.md
index f9b4a390..0e007413 100644
--- a/docs/verifier/verification-library/zk-query-language.md
+++ b/docs/verifier/verification-library/zk-query-language.md
@@ -18,7 +18,7 @@ import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import useBaseUrl from '@docusaurus/useBaseUrl';
-The
Atomic Query Signature V2 Circuit and
Atomic Query MTP V2 Circuit circuits have been designed as generic circuits to do the ZK verification based on users' claims.
+The
Atomic Query Signature V2 Circuit and
Atomic Query MTP V2 Circuit circuits have been designed as generic circuits to do the ZK verification based on users' claims.
The Query Language sits on top of these circuits to provide a simple way for developers to design customized authentication requirements for someone's credentials. As long as the user holds a credential of a specific type, the Verifier can design a query based on 6 operators, for example:
@@ -35,7 +35,7 @@ The Query Language follows the same rules whether the verification is implemente
:::note
-The entire scripts to set a query are available here: [off-chain verification](verifier-set-up.md), [on-chain verification](/docs/verifier/on-chain-verification/overview.md)
+The entire scripts to set a query are available here: [
off-chain verification](verifier-set-up.md), [
on-chain verification](/docs/verifier/on-chain-verification/overview.md)
:::
@@ -513,13 +513,6 @@ The `KYCCountryOfResidenceCredential` Schema encodes the countryCode of residenc
When presented with this query, the user must prove that he/she is not a resident of the country `840` identified by the ISO Standard.
-
-
-
-
-
-
-
diff --git a/docs/verifier/verifier-overview.md b/docs/verifier/verifier-overview.md
index 5970f783..ea102bc7 100644
--- a/docs/verifier/verifier-overview.md
+++ b/docs/verifier/verifier-overview.md
@@ -45,7 +45,7 @@ You can quickly try out the Verification experience by following the steps below
- Download the Polygon ID Wallet App and create an Identity.
> - For Android: Polygon ID on Google Play
> - For iOS: Polygon ID on the App Store
-- Fetch a credential from the [Demo Issuer](https://issuer-ui.polygonid.me/).
+- Fetch a credential from the Issuer Node UI testing environment.
- Verify it on the [Demo Verifier](https://verifier-demo.polygonid.me/).
diff --git a/docs/wallet/wallet-overview.md b/docs/wallet/wallet-overview.md
index 2d518701..b8690b0c 100644
--- a/docs/wallet/wallet-overview.md
+++ b/docs/wallet/wallet-overview.md
@@ -40,7 +40,7 @@ Depending on which type of developer (integrator) you are, you can use different
:::info
-If you are interested in building web-based applications with Polygon ID, please visit the [JS SDK documentation](/docs/js-sdk/js-sdk-overview.md).
+If you are interested in building web-based applications with Polygon ID, please visit the [JS SDK documentation](/docs/js-sdk/js-sdk-overview.md).
:::
diff --git a/docs/wallet/wallet-sdk/android-sdk/install-android-sdk.md b/docs/wallet/wallet-sdk/android-sdk/install-android-sdk.md
index 1de88e80..319a4f39 100644
--- a/docs/wallet/wallet-sdk/android-sdk/install-android-sdk.md
+++ b/docs/wallet/wallet-sdk/android-sdk/install-android-sdk.md
@@ -42,7 +42,7 @@ Once initialized, you can use the SDK through its singleton `PolygonIdSdk.getIns
:::info "Under the hood"
-This SDK is calling the [Flutter SDK](https://github.com/0xPolygonID/polygonid-flutter-sdk) through `MethodChannel`, that's why each method has a `Context` param to initialize the get `FlutterEngine`.
+This SDK is calling the [Flutter SDK](https://github.com/0xPolygonID/polygonid-flutter-sdk) through `MethodChannel`, that's why each method has a `Context` param to initialize the get `FlutterEngine`.
You don't need to install or know anything about Flutter.
:::
\ No newline at end of file
diff --git a/docs/wallet/wallet-sdk/polygonid-sdk/iden3comm/api/get-proofs.md b/docs/wallet/wallet-sdk/polygonid-sdk/iden3comm/api/get-proofs.md
index 6be35bcb..46d26df2 100644
--- a/docs/wallet/wallet-sdk/polygonid-sdk/iden3comm/api/get-proofs.md
+++ b/docs/wallet/wallet-sdk/polygonid-sdk/iden3comm/api/get-proofs.md
@@ -39,7 +39,7 @@ Future> getProofs({
:::info
-The iden3comm's `getProofs` method retrieves the proofs from the proof request of the Verifier. The actual proof is created by the `prove()` method, which you will read about in the [Proof section](/docs/wallet/wallet-sdk/polygonid-sdk/proof/proof-generation-api.md#prove) of the APIs.
+The iden3comm's `getProofs` method retrieves the proofs from the proof request of the Verifier. The actual proof is created by the `prove()` method, which you will read about in the [Proof section](/docs/wallet/wallet-sdk/polygonid-sdk/proof/proof-generation-api.md#prove) of the APIs.
For this to happen, iden3comm makes a call to `prove()`.
diff --git a/docs/wallet/wallet-sdk/polygonid-sdk/identity/get-did-identifier.md b/docs/wallet/wallet-sdk/polygonid-sdk/identity/get-did-identifier.md
index a5adc921..63a8b131 100644
--- a/docs/wallet/wallet-sdk/polygonid-sdk/identity/get-did-identifier.md
+++ b/docs/wallet/wallet-sdk/polygonid-sdk/identity/get-did-identifier.md
@@ -38,7 +38,7 @@ Future getDidIdentifier({
It is worth noting that `did` is a Decentralized Identifier associated with an identity and enables verifiable identities. A `did` could be a person, thing, organization, or even an abstract entity. The controller of the `did` can prove that it is the real owner of the identity without the need of seeking permissions/approvals from any centralized authority.
-A `did` is expressed in the following format (as per [w3.org](https://www.w3.org/) standards):
+A `did` is expressed in the following format (as per [w3.org](https://www.w3.org/) standards):
`did: did method: did method-specific identifier`
From 793b5c6c40c89832aca6751ce9efe4be6518bb81 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vin=C3=ADcius=20Gomes?=
<39063808+cerberushades@users.noreply.github.com>
Date: Mon, 4 Sep 2023 13:08:24 -0300
Subject: [PATCH 2/2] fixed internal link
---
docs/verifier/verification-library/verifier-set-up.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/verifier/verification-library/verifier-set-up.md b/docs/verifier/verification-library/verifier-set-up.md
index a4d77c3a..8942bbdb 100644
--- a/docs/verifier/verification-library/verifier-set-up.md
+++ b/docs/verifier/verification-library/verifier-set-up.md
@@ -21,7 +21,7 @@ Any application that wants to authenticate users based on their Polygon ID Ident
The Server generates [the ZK Request](./request-api-guide.md) according to the requirements of the platform. There are two types of authentication:
- [**Basic Auth**](./request-api-guide.md#basic-auth-request): for example, a platform that issues Credentials must authenticate users by their identifiers before sharing Credentials with them.
-- [**Query-based Auth**](./request-api-guide.md#query-based-auth-request): for example, a platform that gives access only to those users that are over 18 years of age.
+- [**Query-based Auth**](./request-api-guide.md#query-based-request): for example, a platform that gives access only to those users that are over 18 years of age.
The second role of the Server is to execute [Verification](./verification-api-guide.md) of the proof sent by the Identity Wallet.