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/verifier/features.md b/docs/verifier/features.md index 4890f15e..d0931cb0 100644 --- a/docs/verifier/features.md +++ b/docs/verifier/features.md @@ -5,7 +5,7 @@ sidebar_label: Features description: Verifier main features. keywords: - docs - - polygon id + - privado id - ID holder - verifier - selective disclosure @@ -15,10 +15,10 @@ keywords: ## Selective Disclosure -There are two types of proof requests: private proof and selective disclosure. In private proof requests, the credential attribute values are not disclosed, and the response is true/false of the requested value. +There are two types of proof requests: private proof and selective disclosure. In private proof requests, the credential attribute values are not disclosed, and the response is true/false for the requested value. In selective disclosure requests, the verifier asks for one attribute value from the credential to be disclosed. -The selective disclosure has almost the same technical flow as the proof request, the only difference is that the query in the QR code from the proof request of the verifier contains a different format. The SDK just calls the authenticate method from `iden3comm.dart` with the `iden3MessageEntity` as a parameter. +The **selective disclosure** has almost the same technical flow as the proof request, the only difference is that the query in the QR code from the proof request of the verifier contains a different format. The SDK just calls the authenticate method from `iden3comm.dart` with the `iden3MessageEntity` as a parameter. :::info diff --git a/docs/verifier/on-chain-verification/overview.md b/docs/verifier/on-chain-verification/overview.md index 9ecb68d9..a18eea91 100644 --- a/docs/verifier/on-chain-verification/overview.md +++ b/docs/verifier/on-chain-verification/overview.md @@ -14,7 +14,7 @@ keywords: import useBaseUrl from '@docusaurus/useBaseUrl'; -The on-chain verification workflow allows dApps to verify users' credentials inside a Smart Contract. Zero-Knowledge Proof cryptography enables this verification to happen privately, that means, without revealing any personal information of the user (prover). +The on-chain verification workflow allows dApps to verify users' credentials inside a Smart Contract. Zero-Knowledge Proof cryptography enables this verification to happen privately, this means, without revealing any personal information of the user (prover). This flow is especially needed in cases where further on-chain logic needs to be implemented on successful verification such as: @@ -29,9 +29,9 @@ Before describing on-chain verification details, it's important to emphasize tha You can inherit `EmbeddedZKPVerifier` smart contract or link to pre-deployed `UniversalVerifier` contract. Both of the contracts share the same parent class and implement the same `IZKPVerifier` interface, which defines methods to set, get, and submit responses for Proof Requests. -However, as `EmbeddedZKPVerifier` is added to client custom contract that means that all verification result are stored in the state of a client contract. Whenever you need to use on-chain verification for a new contract, you need to re-submit all the proof responses to it. +However, as `EmbeddedZKPVerifier` is added to client's custom contract that means that all verification result are stored in the state of a client contract. Whenever you need to use on-chain verification for a new contract, you need to resubmit all the proof responses to it. -On the other hand, `UniversalVerifier` is deployed as a standalone contract and acts as a central register of proof verifications. Once a proof is submitted for specific proof request, is can be used in many different client contracts. +On the other hand, `UniversalVerifier` is deployed as a standalone contract and acts as a central register of proof verifications. Once a proof is submitted for specific proof request, it can be used in many different client contracts. ## On-chain verification flow @@ -43,14 +43,14 @@ On the other hand, `UniversalVerifier` is deployed as a standalone contract and 1. After having deployed a client custom contract with inherited `Embedded ZKP Verifier`, the Verifier designs and sets a [Proof Request](#set-the-zkp-request) with `setRequest` contract method. -1. The Request is generated at verifier backend and delivered to a user within a QR code (or via deep-linking, depending on the implementation). -1. The user scans the QR code using his/her mobile ID wallet and parses the request. -1. A ZK proof is generated on mobile or web wallet according to the request of the website and based on the credentials held in his/her wallet. -1. The user sends the ZK proof to the Verifier Smart Contract via `submitZKPResponse` or `submitZKPResponseV2` method. -1. The Verifier Smart Contract verifies the ZK Proof. -1. The Verifier Smart Contract checks that the State of the Issuer of the credential and the State of the user are still valid and have not been revoked. -1. If the verification is successful, the proof status is recorded on-chain. -1. Now the Verifier Contract may execute a custom business logic (e.g. minting tokens), which may check the proof status and occurs in the same transaction. +2. The Request is generated at verifier backend and delivered to a user within a QR code (or via deep-linking, depending on the implementation). +3. The user scans the QR code using his/her mobile ID wallet and parses the request. +4. A ZK proof is generated on mobile or web wallet according to the request of the website and based on the credentials held in his/her wallet. +5. The user sends the ZK proof to the Verifier Smart Contract via `submitZKPResponse` or `submitZKPResponseV2` method. +6. The Verifier Smart Contract verifies the ZK Proof. +7. The Verifier Smart Contract checks that the State of the Issuer of the credential and the State of the user are still valid and have not been revoked. +8. If the verification is successful, the proof status is recorded on-chain. +9. Now the Verifier Contract may execute a custom business logic (e.g. minting tokens), which may check the proof status and occur in the same transaction. Note that the Verifier only sets the Request at step 1. All the rest of the interaction is between a User and the Smart Contract. All the verification logic is executed programmatically inside the Smart Contract. diff --git a/docs/verifier/on-chain-verification/set-zkp-request.md b/docs/verifier/on-chain-verification/set-zkp-request.md index 7666c9e6..7c4d4a79 100644 --- a/docs/verifier/on-chain-verification/set-zkp-request.md +++ b/docs/verifier/on-chain-verification/set-zkp-request.md @@ -16,33 +16,41 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; ### Approach - A Setting Request using Query Builder: -1. Visit the [PrivadoID Query Builder](https://tools.privado.id/query-builder) and paste the JSON-LD Context URL (mentioned above) in the input box. -2. Select the schema type to `pohcheck` and select the `human` in the Attribute field. +1. Visit the [PrivadoID Query Builder](https://tools.privado.id/query-builder) and paste the JSON-LD Context URL (mentioned below). +`ipfs://QmfEEiU1UqkH5eXSFurSbu6g87k6R6YhKtxyRnd534Wn6E` + +2. Select the schema type to `Proof of Age`, click on `Add condition` and select the `minAgeRange` in the Attribute field.
- -3. Select the Proof type "Signature-based (SIG)" and Circuit ID Credential Atomic Query v3 On Chain. - -4. Set the query type as Condition and Operator as "Is equal to," and select `true` in the Attribute value. - -5. Set the Issuer DID field to "*" to accept credentials from any issuer or, if you want, you can use any specific DID to restrict allowed issuers for the query. +
-6. Next, click on the **“Create query”**. +3. Set the Issuer DID field to "*" to accept credentials from any issuer or, if you want, you can use any specific DID to restrict allowed issuers for the query. + +4. Set the Operator as "Is equal to," and input value `20` in the Attribute value + +5. Select verification type as `on-chain` and click on Advanced options and select the Proof type `BJJSignature2021` and Circuit ID `Credential Atomic Query v3`. -7. Add the Universal Verifier Smart contract address for the selected network (e.g., for Polygon Amoy: `0xfcc86A79fCb057A8e55C6B853dff9479C3cf607c`) in the Smart Contract Address input.
+
+
+ +
-8. Click on the **Set request** to submit the on-chain request. +6. Add the Universal Verifier Smart contract address for the selected network (e.g., for Polygon Amoy: `0xfcc86A79fCb057A8e55C6B853dff9479C3cf607c`) in the Smart Contract Address input. -9. Click on **Confirm** in the Metamask to accept and submit the request. +7. Click on the **Set query** to submit the on-chain request. + +8. Click on **Confirm** in the Metamask to accept and submit the request. + +9. Next, click on the **“Test query”**.
- +
:::note diff --git a/docs/verifier/query-builder.md b/docs/verifier/query-builder.md index c74f03a4..8777eced 100644 --- a/docs/verifier/query-builder.md +++ b/docs/verifier/query-builder.md @@ -5,7 +5,7 @@ sidebar_label: Query Builder description: Learn how to use the Query Builder. keywords: - docs - - polygon id + - privado id - ID holder - issuer - verifier @@ -23,7 +23,7 @@ keywords: import useBaseUrl from '@docusaurus/useBaseUrl'; -The Query Builder, available [here](https://schema-builder.polygonid.me/query-builder), is an intuitive, web-based tool designed to simplify the creation of verification queries. It's particularly useful for verifiers looking to establish specific criteria for identity verification, such as organizational membership or age requirements. By leveraging Polygon ID, the Query Builder offers a secure and efficient method for users to authenticate identities based on these criteria. +The Query Builder, available [here](https://tools.privado.id/query-builder), is an intuitive, web-based tool designed to simplify the creation of verification queries. It's particularly useful for verifiers looking to establish specific criteria for identity verification, such as organizational membership or age requirements. By leveraging Privado ID, the Query Builder offers a secure and efficient method for users to authenticate identities based on these criteria. ## Features @@ -48,12 +48,20 @@ Here's a glimpse of the main user interface of the Query Builder:
+
+ +
+
+
+ +
+
## Building a query ### URL to JSON-LD Context -To create a query, it is essential to reference the correct schema, specifically its JSON-LD Context's URL. Users have two options: they can either enter a URL pointing to a JSON-LD Context or utilize one from the [Schema Explorer](https://schema-builder.polygonid.me). By starting to type the name (or any other keyword) of the desired schema in the Schema Explorer, a list of available schemas will appear, allowing the user to select the appropriate one. +To create a query, it is essential to reference the correct schema, specifically its JSON-LD Context's URL. Users have two options: they can either enter a URL pointing to a JSON-LD Context or utilize one from the [Schema Explorer](https://tools.privado.id/). By starting to type the name (or any other keyword) of the desired schema in the Schema Explorer, a list of available schemas will appear, allowing the user to select the appropriate one.
@@ -73,6 +81,9 @@ Credentials consist of various primitive attributes such as strings, integers, b
+
+ +

### Proof type @@ -132,9 +143,9 @@ The protocol allows selection between three query types: 1. **Condition:** This type allows the prover to demonstrate that a specific condition is met without revealing the underlying data. It maintains data privacy by cryptographically verifying the condition. An example is proving legal age for entry into a venue without disclosing the actual age. -2. **Selective disclosure:** Use this when you need the prover to reveal specific data stored in their credential. This option discloses the actual value of an attribute to the verifier. For instance, instead of just requesting proof proving legal age, it would disclose the prover's actual age to the verifier. +2. **Selective disclosure:** Use this when you need the prover to reveal specific data stored in their credential. This option discloses the actual value of an attribute to the verifier. For instance, instead of just requesting proof of legal age, it would disclose the prover's actual age to the verifier. -3. **Credential issued:** Use this when you need the prove that credential with a specific type has been issued, but not to reveal any information. +3. **Credential issued:** Use this when you need to prove that a credential with a specific type has been issued, but not to reveal any information. Choose "Condition" for privacy-preserving verification, "Selective disclosure" for cases where revealing specific information is necessary, "Credential issued" when you need to ensure the fact of credential issuance. @@ -198,7 +209,7 @@ The verification of queries off-chain is a straightforward process: 2. **Scan QR Code:** Use the prover's wallet to scan this QR code. 3. **Credential Validation:** The wallet checks for the existence of the credential and verifies all query requirements, including issuer DID, revocation status, and specified conditions. 4. **Zero-Knowledge Proof Generation:** If the criteria are met, a zero-knowledge proof is generated. This proof serves as cryptographic evidence that the prover's credential is valid and fulfills all aspects of the query. -5. **Receiving Proof:** The zero-knowledge proof is returned as a JWZ token, which can be decoded using the [JWZ tool](https://jwz.polygonid.me/). +5. **Receiving Proof:** The zero-knowledge proof is returned as a JWZ token, which can be decoded using the [JWZ tool](hhttps://jwz-validator.privado.id/). For a detailed walkthrough, refer to the provided video illustrating the complete process of creating and verifying an off-chain query. diff --git a/docs/verifier/v3-circuit.md b/docs/verifier/v3-circuit.md index 9efed71d..c40df0ff 100644 --- a/docs/verifier/v3-circuit.md +++ b/docs/verifier/v3-circuit.md @@ -5,7 +5,7 @@ sidebar_label: V3 circuit (Beta) description: Verifier main features. keywords: - docs - - polygon id + - privado id - ID holder - circuit - v3 @@ -13,17 +13,17 @@ keywords: ## New circuits available -We want to introduce new circuits - СredentialAtomicQueryV3 and CredentialAtomicQueryV3Onchain +We are introducing two new circuits — CredentialAtomicQueryV3 and CredentialAtomicQueryV3Onchain :::warning - Circuits are in the beta version. Trusted setup will be performed in the next release. + These circuits are in beta. The trusted setup will be completed in the next release. Newest version is СredentialAtomicQueryV3-beta.1
Changelog from beta.0 to beta.1 1. ValueArrSize input is introduced, which fixes behaviour for IN / NIN operations. - 2. Exists / Noop / Less Than Or Equal / Greater Than or Equal / Not between / Between operators support. + 2. Support for Exists / Noop / Less Than Or Equal / Greater Than Or Equal / Not Between / Between operators. 3. Query hash calculation algorithm changes. 4. Constraints and security optimizations. @@ -35,7 +35,7 @@ More about new supported operators [here](./verification-library/zk-query-langua Link to latest sdk circuit wrappers: [js](https://github.com/0xPolygonID/js-sdk/pull/181) / [go](https://github.com/iden3/go-circuits/releases/tag/v2.1.0) -In general it's an improved version of V2 circuits with several important key features: +Overall, it is an improved version of the V2 circuits with several important features: 1. SIG and MTP checks are united in single circuit. Now you can use only one circuit without sig/mtp suffixes. Proof will be taken from user wallet and authorization response will contain information about verifiable credential proof type which has been used. It is possible to request the needed proof from user by using `proofType` property in the authorization request message. Possible values are `Iden3SparseMerkleTreeProof` and `BJJSignature2021`. If `proofType` is not provided - available proof will be used. In case there are two proofs available - MTP will be used as more prior. @@ -56,7 +56,7 @@ In general it's an improved version of V2 circuits with several important key fe 2. Support of new type of operators modifiers: now selective disclosed value will be present in the output value - this will give a possibility for onchain verification to work with selective disclosure workflows. The format of the request hasn't been changed. -3. Support of nullifiers generation for proof of uniqueness use cases. Imagine the scenario when verifier needs to make sure that credential can be used only once for the proof generation from specific user. Now it's possible. If credential is issued on profile, verifier id is present and nullifier session id is provided - unique value for such credential will be generated and persist in the proof outputs. +3. Support of nullifiers generation for proof of uniqueness use cases. Imagine the scenario when verifier needs to make sure that credential can be used only once for the proof generation from specific user. This is now possible, if a credential is issued on a profile, the verifier ID is present, and a nullifier session ID is provided - unique value for such credential will be generated and persist in the proof outputs. ```json ... @@ -75,8 +75,8 @@ In general it's an improved version of V2 circuits with several important key fe ... ``` -4. For onchain circuit now it is possible to disable default authentication. Ethereum-based identities can generate zero-knowledge proofs without having the bjj keys, and verification will be successful. - In this scenario user id myst be derived from the sender address. Bellow is an example of V3 circuit. +4. For onchain circuit now it is possible to disable default authentication. Ethereum-based identities can generate zero-knowledge proofs without having the BJJ keys, and verification will be successful. + In this scenario user id must be derived from the sender address. Below is an example of a V3 circuit. ```js @@ -90,7 +90,7 @@ In general it's an improved version of V2 circuits with several important key fe Beta Validator is also deployed: [Repository](https://github.com/0xPolygonID/contracts) -1. Possibility to use linked proofs. This means that verifier can be sure that user used the same credential to proof different queries. This is achievable by using `groupId` property in the proof request. +5. Possibility to use linked proofs. This means the verifier can be sure that the user used the same credential to prove different queries. This is achievable by using `groupId` property in the proof request. ```json ... @@ -144,7 +144,7 @@ Example of complex request with v3 circuit proof request: }, "query": { "groupId": 1, - "proofType": "BJJSignature", + "proofType": "BJJSignature2021", "allowedIssuers": ["*"], "context": "https://raw.githubusercontent.com/iden3/claim-schema-vocab/main/schemas/json-ld/kyc-v101.json-ld", "type": "KYCEmployee", diff --git a/docs/verifier/verification-library/verification-api-guide.md b/docs/verifier/verification-library/verification-api-guide.md index 8c04d546..a1b5d609 100644 --- a/docs/verifier/verification-library/verification-api-guide.md +++ b/docs/verifier/verification-library/verification-api-guide.md @@ -5,7 +5,7 @@ sidebar_label: Verification description: Learn how to verify proofs using the API. keywords: - docs - - polygon id + - privado id - ID holder - issuer - verifier @@ -19,7 +19,7 @@ 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. +After presenting 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. @@ -51,7 +51,7 @@ const tokenStr = raw.toString().trim(); -`req` is the post request sent by the wallet in response to the Auth Request posed by the Verifier. This unpacks the proof sent by the wallet. +`req` is the POST request sent by the wallet in response to the Auth Request posed by the Verifier. This unpacks the proof sent by the wallet. ## Initiate the verifier @@ -138,7 +138,7 @@ authResponse = await verifier.fullVerify(tokenStr, authRequest, opts); -Execute the verification. It verifies that the proof shared by the user satisfies the criteria set by the Verifier inside the initial request. +This process verifies that the proof shared by the user satisfies the criteria set by the Verifier inside the initial request. `tokenBytes` contains the proof generated by the user's wallet. @@ -165,7 +165,7 @@ Starting from the circuit-specific public verification key, the proof, and the p ### Verification of On-chain Identity States -Starting from the DID of the user, the State is fetched from the blockchain and compared to the state provided as input to the proof; this is done to check whether the user is the actual "owner" of the state used to generate the proof or not. It is important to note here that there is no gas cost associated with the verification as the `VerifyState` method. It just reads the identity state of the user on-chain without making any operations/smart contract calls. The same verification is performed for the Issuer's Identity State. +Starting from the DID of the user, the State is fetched from the blockchain and compared to the state provided as input to the proof; this is done to check whether the user is the actual "owner" of the state used to generate the proof. It is important to note here that there is no gas cost associated with the verification as the `VerifyState` method. It just reads the identity state of the user on-chain without making any operations/smart contract calls. The same verification is performed for the Issuer's Identity State. In this part, it is also verified that the requested credential has not been revoked by the Issuer. @@ -180,5 +180,5 @@ This "off-circuit" verification is important because a user can potentially modi At the end of the workflow: -- The web client is able to authenticate the user using its DID `ID` after having established that the user controls that identity and satisfies the query presented in the auth request. -- The user is able to log into the platform without disclosing any personal information to the client except for its DID. +- The web client is able to authenticate the user using its `DID` after having established that the user controls that identity and satisfies the query presented in the auth request. +- The user is able to log into the platform without disclosing any personal information to the client except for their DID. diff --git a/docs/verifier/verification-library/verifier-library-intro.md b/docs/verifier/verification-library/verifier-library-intro.md index 5e536afb..aae027c4 100644 --- a/docs/verifier/verification-library/verifier-library-intro.md +++ b/docs/verifier/verification-library/verifier-library-intro.md @@ -18,7 +18,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; At its core, every off-chain interaction between a Verifier and a user's Wallet follows this workflow: - A web application designs a [request](./request-api-guide.md) for the users. This is delivered to the user via a [Universal link](../../wallet/universal-links.md), a QR code or via deep-linking (it is up to the implementer). This can either be a [auth request](./request-api-guide.md#basic-auth-request) or a [query-based request](./request-api-guide.md#query-based-request). -- The user clicks the universal link which directs them to the Web Wallet or the mobile wallet or the scans the QR code using the mobile wallet to parse the request. +- The user either clicks the universal link, which opens the Web Wallet or Mobile Wallet, or scans the QR code with the Mobile Wallet to parse the request. - The user fetches the revocation status of the requested credential from the Issuer of that credential. - The user generates a ZK proof on mobile according to the request of the website starting from the credentials held in his/her wallet. This also contains the ZK proof that the credential is not revoked. - The user sends the ZK proof to the Verifier. diff --git a/docs/verifier/verification-library/zk-query-language.md b/docs/verifier/verification-library/zk-query-language.md index c01e165c..85249153 100644 --- a/docs/verifier/verification-library/zk-query-language.md +++ b/docs/verifier/verification-library/zk-query-language.md @@ -5,7 +5,7 @@ sidebar_label: ZK Query Language description: Learn how to build verification requests with the ZK query language. keywords: - docs - - polygon id + - privado id - verifier - on-chain - off-chain @@ -22,7 +22,7 @@ The -Please, check out our [Onchain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for onchain +Please, check out our [On-chain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for on-chain Corresponding QR Code @@ -163,7 +163,7 @@ const proofRequest: protocol.ZKPRequest = { -Please, check out our [Onchain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for onchain +Please, check out our [On-chain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for on-chain Corresponding QR Code @@ -238,7 +238,7 @@ const proofRequest: protocol.ZKPRequest = { -Please, check out our [Onchain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for onchain +Please, check out our [On-chain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for on-chain Corresponding QR Code\*\* @@ -315,7 +315,7 @@ const proofRequest: protocol.ZKPRequest = { -Please, check out our [Onchain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for onchain +Please, check out our [On-chain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for on-chain Corresponding QR Code @@ -389,7 +389,7 @@ const proofRequest: protocol.ZKPRequest = { -Please, check out our [Onchain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for onchain +Please, check out our [On-chain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for on-chain Corresponding QR Code @@ -464,7 +464,7 @@ const proofRequest: protocol.ZKPRequest = { -Please, check out our [Onchain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for onchain +Please, check out our [On-chain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for on-chain Corresponding QR Code @@ -514,11 +514,11 @@ Operators 7-11 are supported only by [V3 circuit](../v3-circuit.md) **Credential Schema** -The `KYCCountryOfResidenceCredential` Schema encodes the countryCode of residence of the credential subject according to the [ISO Standard](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes). Here's the [JSON-LD Context](https://github.com/iden3/claim-schema-vocab/blob/main/schemas/json-ld/kyc-v4.jsonld) of the Schema Type. +The `KYCAgeCredential` Schema encodes the countryCode of residence of the credential subject according to the [ISO Standard](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes). Here's the [JSON-LD Context](https://github.com/iden3/claim-schema-vocab/blob/main/schemas/json-ld/kyc-v4.jsonld) of the Schema Type. **Query** -When presented with this query, the user must prove that he/she has been born before or including 2001/01/01 +When presented with this query, the user must prove that he/she was born on or before 2001/01/01 @@ -529,7 +529,7 @@ const proofRequest: protocol.ZKPRequest = { circuitId: "credentialAtomicQuerySigV2", query: { allowedIssuers: ["*"], - type: "KYCCountryOfResidenceCredential", + type: "KYCAgeCredential", context: "https://raw.githubusercontent.com/iden3/claim-schema-vocab/main/schemas/json-ld/kyc-v4.jsonld", credentialSubject: { @@ -544,7 +544,7 @@ const proofRequest: protocol.ZKPRequest = { -Please, check out our [Onchain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for onchain +Please, check out our [On-chain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for on-chain Corresponding QR Code @@ -574,7 +574,7 @@ Corresponding QR Code "$lte": 20010101 } }, - "type": "KYCCountryOfResidenceCredential" + "type": "KYCAgeCredential" } } ] @@ -589,11 +589,11 @@ Corresponding QR Code **Credential Schema** -The `KYCCountryOfResidenceCredential` Schema encodes the countryCode of residence of the credential subject according to the [ISO Standard](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes). Here's the [JSON-LD Context](https://github.com/iden3/claim-schema-vocab/blob/main/schemas/json-ld/kyc-v4.jsonld) of the Schema Type. +The `KYCAgeCredential` Schema encodes the countryCode of residence of the credential subject according to the [ISO Standard](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes). Here's the [JSON-LD Context](https://github.com/iden3/claim-schema-vocab/blob/main/schemas/json-ld/kyc-v4.jsonld) of the Schema Type. **Query** -When presented with this query, the user must prove that he/she has been born after or including 2001/01/01 +When presented with this query, the user must prove that he/she has been born on or after 2001/01/01 @@ -604,7 +604,7 @@ const proofRequest: protocol.ZKPRequest = { circuitId: "credentialAtomicQuerySigV2", query: { allowedIssuers: ["*"], - type: "KYCCountryOfResidenceCredential", + type: "KYCAgeCredential", context: "https://raw.githubusercontent.com/iden3/claim-schema-vocab/main/schemas/json-ld/kyc-v4.jsonld", credentialSubject: { @@ -619,7 +619,7 @@ const proofRequest: protocol.ZKPRequest = { -Please, check out our [Onchain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for onchain +Please, check out our [On-chain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for on-chain Corresponding QR Code @@ -649,7 +649,7 @@ Corresponding QR Code "$gte": 20010101 } }, - "type": "KYCCountryOfResidenceCredential" + "type": "KYCAgeCredential" } } ] @@ -664,11 +664,11 @@ Corresponding QR Code **Credential Schema** -The `KYCCountryOfResidenceCredential` Schema encodes the countryCode of residence of the credential subject according to the [ISO Standard](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes). Here's the [JSON-LD Context](https://github.com/iden3/claim-schema-vocab/blob/main/schemas/json-ld/kyc-v4.jsonld) of the Schema Type. +The `KYCAgeCredential` Schema encodes the countryCode of residence of the credential subject according to the [ISO Standard](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes). Here's the [JSON-LD Context](https://github.com/iden3/claim-schema-vocab/blob/main/schemas/json-ld/kyc-v4.jsonld) of the Schema Type. **Query** -When presented with this query, the user must prove that he/she has been born before 2001/01/01, but after 1996/01/01 +When presented with this query, the user must prove that he/she has been born between 2001/01/01 and 1996/01/01 @@ -679,7 +679,7 @@ const proofRequest: protocol.ZKPRequest = { circuitId: "credentialAtomicQuerySigV2", query: { allowedIssuers: ["*"], - type: "KYCCountryOfResidenceCredential", + type: "KYCAgeCredential", context: "https://raw.githubusercontent.com/iden3/claim-schema-vocab/main/schemas/json-ld/kyc-v4.jsonld", credentialSubject: { @@ -694,7 +694,7 @@ const proofRequest: protocol.ZKPRequest = { -Please, check out our [Onchain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for onchain +Please, check out our [On-chain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for on-chain Corresponding QR Code @@ -724,7 +724,7 @@ Corresponding QR Code "$between": [19960101, 20010101] } }, - "type": "KYCCountryOfResidenceCredential" + "type": "KYCAgeCredential" } } ] @@ -743,7 +743,7 @@ The `KYCCountryOfResidenceCredential` Schema encodes the countryCode of residenc **Query** -When presented with this query, the user must prove that he/she has been born not after 1996/01/01 and and not till 2001/01/01 +When presented with this query, the user must prove that he/she has not been born between 1996/01/01 and 2001/01/01 @@ -754,7 +754,7 @@ const proofRequest: protocol.ZKPRequest = { circuitId: "credentialAtomicQuerySigV2", query: { allowedIssuers: ["*"], - type: "KYCCountryOfResidenceCredential", + type: "KYCAgeCredential", context: "https://raw.githubusercontent.com/iden3/claim-schema-vocab/main/schemas/json-ld/kyc-v4.jsonld", credentialSubject: { @@ -769,7 +769,7 @@ const proofRequest: protocol.ZKPRequest = { -Please, check out our [Onchain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for onchain +Please, check out our [On-chain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for on-chain Corresponding QR Code @@ -799,7 +799,7 @@ Corresponding QR Code "$nonbetween": [19960101, 20010101] } }, - "type": "KYCCountryOfResidenceCredential" + "type": "KYCAgeCredential" } } ] @@ -845,7 +845,7 @@ const proofRequest: protocol.ZKPRequest = { -Please, check out our [Onchain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for onchain +Please, check out our [On-chain verification tutorial to build a query](/docs/verifier/on-chain-verification/overview.md) to learn more how to set zk request for on-chain Corresponding QR Code diff --git a/docs/verifier/verifier-backend.md b/docs/verifier/verifier-backend.md index 7b7c5ce1..12c9f8a4 100644 --- a/docs/verifier/verifier-backend.md +++ b/docs/verifier/verifier-backend.md @@ -5,7 +5,7 @@ sidebar_label: Verifier Backend API description: Verifier Backend API. keywords: - docs - - polygon id + - privado id - ID holder - verifier --- diff --git a/docs/verifier/verifier-overview.md b/docs/verifier/verifier-overview.md index c2338fd5..68c2cef3 100644 --- a/docs/verifier/verifier-overview.md +++ b/docs/verifier/verifier-overview.md @@ -5,7 +5,7 @@ sidebar_label: Overview description: Verifier definition and SDK types. keywords: - docs - - polygon id + - privado id - ID holder - issuer - verifier @@ -20,7 +20,7 @@ A Verifier is any web2 or web3 platform that wants to authenticate users based o Verifiers can set up queries based on **users’ existing Credentials** collected from a broad set of [Issuers](/docs/issuer/issuer-overview.md). A [Query](/docs/verifier/verification-library/zk-query-language.md) encapsulates the criteria that a user must match to authenticate, such as “must be a member of XYZ DAO” or “must be over 18 years old”. Privado ID provides a seamless, customized and privacy-based authentication experience to users. -The request of the Verifier is designed using our fully expressive [zk Query Language](/docs/verifier/verification-library/zk-query-language.md) and encapsulated into a [Universal Link](../wallet/universal-links.md) or a QR code to be shown to the user. The clicks the Universal link or user scans the QR code with its mobile wallet app to prompt the proof generation. +The request of the Verifier is designed using our fully expressive [zk Query Language](/docs/verifier/verification-library/zk-query-language.md) and encapsulated into a [Universal Link](../wallet/universal-links.md) or a QR code to be shown to the user. The user clicks the Universal link or the user scan the QR code with their mobile wallet app to prompt the proof generation. The verification process doesn’t involve any interaction between the Verifier and the Issuer of the requested credential. As part of the Query, the Verifier includes the identifiers of the trusted issuers. For example, a Verifier should add XYZ DAO as the only trusted Issuer when verifying that an individual is a member of XYZ DAO. The XYZ DAO doesn’t need to accept nor interact with the Verifier. diff --git a/package-lock.json b/package-lock.json index 5cc0145a..a4d7f0c9 100644 --- a/package-lock.json +++ b/package-lock.json @@ -2593,15 +2593,6 @@ "resolved": "https://registry.npmjs.org/@docsearch/css/-/css-3.8.0.tgz", "integrity": "sha512-pieeipSOW4sQ0+bE5UFC51AOZp9NGxg89wAlZ1BAQFaiRAGK1IKUaPQ0UGZeNctJXyqZ1UvBtOQh2HH+U5GtmA==" }, - "node_modules/@docsearch/js": { - "version": "3.8.0", - "resolved": "https://registry.npmjs.org/@docsearch/js/-/js-3.8.0.tgz", - "integrity": "sha512-PVuV629f5UcYRtBWqK7ID6vNL5647+2ADJypwTjfeBIrJfwPuHtzLy39hMGMfFK+0xgRyhTR0FZ83EkdEraBlg==", - "dependencies": { - "@docsearch/react": "3.8.0", - "preact": "^10.0.0" - } - }, "node_modules/@docsearch/react": { "version": "3.8.0", "resolved": "https://registry.npmjs.org/@docsearch/react/-/react-3.8.0.tgz", @@ -16770,15 +16761,6 @@ "postcss": "^8.2.15" } }, - "node_modules/preact": { - "version": "10.24.3", - "resolved": "https://registry.npmjs.org/preact/-/preact-10.24.3.tgz", - "integrity": "sha512-Z2dPnBnMUfyQfSQ+GBdsGa16hz35YmLmtTLhM169uW944hYL6xzTYkJjC07j+Wosz733pMWx0fgON3JNw1jJQA==", - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/preact" - } - }, "node_modules/prepend-http": { "version": "1.0.4", "resolved": "https://registry.npmjs.org/prepend-http/-/prepend-http-1.0.4.tgz", diff --git a/static/img/onchain-verifier/querybuilder-1.png b/static/img/onchain-verifier/querybuilder-1.png index ba56d822..1cfb1ebe 100644 Binary files a/static/img/onchain-verifier/querybuilder-1.png and b/static/img/onchain-verifier/querybuilder-1.png differ diff --git a/static/img/onchain-verifier/querybuilder-2.png b/static/img/onchain-verifier/querybuilder-2.png index dba0d7e9..e87636ea 100644 Binary files a/static/img/onchain-verifier/querybuilder-2.png and b/static/img/onchain-verifier/querybuilder-2.png differ diff --git a/static/img/onchain-verifier/querybuilder-3.png b/static/img/onchain-verifier/querybuilder-3.png index 28285732..0319c8a4 100644 Binary files a/static/img/onchain-verifier/querybuilder-3.png and b/static/img/onchain-verifier/querybuilder-3.png differ diff --git a/static/img/onchain-verifier/querybuilder-4.png b/static/img/onchain-verifier/querybuilder-4.png index e82fa7d3..9ab5ce20 100644 Binary files a/static/img/onchain-verifier/querybuilder-4.png and b/static/img/onchain-verifier/querybuilder-4.png differ diff --git a/static/img/onchain-verifier/querybuilder-5.png b/static/img/onchain-verifier/querybuilder-5.png index ccc55792..0de9d79a 100644 Binary files a/static/img/onchain-verifier/querybuilder-5.png and b/static/img/onchain-verifier/querybuilder-5.png differ diff --git a/static/img/onchain-verifier/querybuilder-6.png b/static/img/onchain-verifier/querybuilder-6.png index bf81ee6f..448c823c 100644 Binary files a/static/img/onchain-verifier/querybuilder-6.png and b/static/img/onchain-verifier/querybuilder-6.png differ diff --git a/static/img/query-add-condition.png b/static/img/query-add-condition.png new file mode 100644 index 00000000..f6f7e034 Binary files /dev/null and b/static/img/query-add-condition.png differ diff --git a/static/img/query-builder-attribute-field.png b/static/img/query-builder-attribute-field.png index 920d8eff..a21a7c8c 100644 Binary files a/static/img/query-builder-attribute-field.png and b/static/img/query-builder-attribute-field.png differ diff --git a/static/img/query-builder.png b/static/img/query-builder.png index e15b8d93..3becb9d3 100644 Binary files a/static/img/query-builder.png and b/static/img/query-builder.png differ diff --git a/static/img/query-circuit.png b/static/img/query-circuit.png new file mode 100644 index 00000000..f70e8d4f Binary files /dev/null and b/static/img/query-circuit.png differ diff --git a/static/img/query-test.png b/static/img/query-test.png new file mode 100644 index 00000000..b4a492c7 Binary files /dev/null and b/static/img/query-test.png differ