Merge pull request #855 from Concordium/web3-id

Web3 ID documentation

source/mainnet/_templates/index.html

@@ -29,7 +29,7 @@
       <a class="card" href="{{ pathto('net/guides/how-to-earn') }}"><span class="fas fa-coins fa-3x"></span><h3>Earn CCDs</h3><p>Earn CCDs by baking and delegating.</p></a>
       <a class="card" href="{{ pathto('smart-contracts/general/introduction') }}"><span class="fas fa-code-branch fa-3x"></span><h3>Develop with Concordium</h3><p>Go through tutorials to learn about smart contracts and write your own smart contracts.</p></a>
       <a class="card" href="{{ pathto('net/installation/downloads') }}"><span class="fas fa-download fa-3x"></span><h3>Downloads</h3><p>Download Concordium software.</p></a>
-      <a class="card" href="{{ pathto('net/guides/create-proofs') }}"><span class="fas fa-id-card fa-3x"></span><h3>Use ID</h3><p>Use the Concordium ID layer.</p></a>
+      <a class="card" href="{{ pathto('net/web3-id/index') }}"><span class="fas fa-id-card fa-3x"></span><h3>Use ID</h3><p>Use the Concordium ID layer.</p></a>
       <a class="card" href="{{ pathto('net/guides/dapp-examples') }}"><span class="fas fa-desktop fa-3x"></span><h3>dApp examples</h3><p>Example dApps for inspiration.</p></a>
       <a class="card" href="https://academy.concordium.software/ccd-academy/getting-started"><span class="fas fa-graduation-cap fa-3x"></span><h3>Concordium Academy</h3><p>Learn about Concordium and get rewards.</p></a>
     </div>

source/mainnet/net/guides/create-proofs.rst

@@ -1,13 +1,25 @@
 .. include:: ../../variables.rst
 .. _create-proofs:
 
-=====================
-Use ID: Create proofs
-=====================
+=============
+Create proofs
+=============
+
+A :ref:`verifier<glossary-verifier>` is a business or use-case that provides a service contingent on the holder providing information about themselves using :ref:`verifiable credentials<glossary-verifiable-credential>` or :ref:`account credentials<glossary-account-credential>` they have. A verifier will typically consist of two components:
+
+1. A dApp that interacts with the wallet and requests a :ref:`verifiable presentation<glossary-verifiable-presentation>` from the user.
+2. A back end that will verify the provided presentations, and provide the required service if successful, such as the `Concordia back end <https://github.com/Concordium/concordium-web3id/tree/main/examples/some-verifier>`_.
+
+The |bw| allows verifiers to request verifiable presentations using dApps or services that the user meets some requirement, such as proof the user is over a certain age, or resides in a specific set of countries or area. The wallet owner chooses whether to prove these :ref:`attributes<glossary-attribute>` to the dApp or service. The dApp or service constructs a list of :ref:`statements<glossary-statement>` to request a corresponding list of :ref:`zero knowledge proofs<glossary-zero-knowledge-proof>` of the attribute(s) necessary without revealing anything beyond the truth of the statement. Presentations contain zero-knowledge proofs.
+
+The dApp or service can also request that attributes are revealed. The wallet owner can choose whether they want to reveal these attributes to the dApp or service. The verifiable credentials themselves never leave the holder's wallet, only the information requested by the verifier does.
+
+The verification of presentations consists of two parts.
 
-The |bw| allows dApps or services to request proofs that the user meets some requirement, such as proof the user is over a certain age, or resides in a specific set of countries or area. The wallet owner chooses whether to prove these :ref:`attributes<glossary-attribute>` to the dApp or service. The dApp or service constructs a list of :ref:`statements<glossary-statement>` to request a corresponding list of :ref:`zero knowledge proofs<glossary-zero-knowledge-proof>` of the attribute(s) necessary without revealing anything beyond the truth of the statement.
+1. The cryptographic verification of zero-knowledge proofs, and checks that the verifiable credential is valid, which involves checks in smart contracts.
+2. The checking whether the properties attested to are the ones required. This is the custom business logic of the verifier.
 
-The dApp or service can also request that attributes are revealed. The wallet owner can choose whether they want to reveal these :ref:`attributes<glossary-attribute>` to the dApp or service.
+Note that the presentation can combine requirements for account credentials and verifiable credentials.
 
 The diagram below shows the interaction between the Rust server/backend, the dApp, and the wallet.
 
@@ -30,7 +42,7 @@ For the dApp or service developer there are some general rules about proofs that
 - There is no limit to the amount of attributes that can be revealed.
 - An attribute can only be used in one proof at a time.
 
-The attributes that can be revealed are:
+The identity provider issued attributes that can be revealed from :ref:`account credentials<glossary-account-credential>` are:
 
 - First name
 - Last name
@@ -46,6 +58,8 @@ The attributes that can be revealed are:
 - National ID number
 - Tax ID number
 
+You can also build statements that include proofs for attributes in :ref:`verifiable credentials<glossary-verifiable-credential>`. In this case, there is not a fixed list of attributes; it depends on the :ref:`issuer's needs<web3id-issuer>`.
+
 You can find more information about building proof statements in the `Concordium node SDK js repository <https://github.com/Concordium/concordium-node-sdk-js/tree/main/packages/common#identity-proofs>`_.
 
 Asking a user to reveal attributes
@@ -164,6 +178,21 @@ For example, the statement below asks if the wallet owner is a citizen of China
 
     Country codes to use for residence and nationality proofs are the `ISO-3166-1 alpha-2 codes <https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2>`_.
 
+.. _verifier-tool:
+
+Tool to verify credentials
+==========================
+
+Concordium has developed a verifier tool which is a self-contained service that handles the retrieval of credentials from the chain, and the cryptographic verification of presentations.
+The tool is generic and the API exposed is minimal.
+The verifier has a single POST endpoint and is meant to be used by another service, such as a dApp.
+
+The response to the request will be status code 200 together with a JSON body that contains the request (i.e., challenge and statement for which the presentation is valid) together with the timestamp and block in which the verification took place. In case of an invalid request the HTTP status code will be in the 4** range, either 404 if credentials cannot be found, or 400 for invalid proofs or otherwise malformed requests.
+
+You can choose whether you want to use the hosted Concordium verifier for `Mainnet <https://web3id-verifier.mainnet.concordium.software/v0/verify>`__ or `Testnet <https://web3id-verifier.testnet.concordium.com/v0/verify>`__, or whether you want to create your own verifier tool. Note that if you use the hosted verifier then you trust Concordium when verifying proofs.
+
+If you do not wish to use the Concordium hosted verifier, you can can either build your own following instructions in `readme file <https://github.com/Concordium/concordium-web3id/tree/main/services/web3id-verifier>`__ or use the `published Docker image <https://hub.docker.com/r/concordium/web3id-verifier/tags>`__.
+
 Example dApp
 ============
 

source/mainnet/net/guides/proofs.rst

@@ -5,12 +5,12 @@
 Proofs and revealing information
 ================================
 
-Some dApps or services may require you to prove that you are over a certain age, or that you reside in a specific range of countries or area without revealing your exact age or country of residence. You can choose whether you want to prove these :ref:`attributes<glossary-attribute>` to the dApp or service. The dApp or service uses a :ref:`zero knowledge proof<glossary-zero-knowledge-proof>` to request the attributes necessary for their service. This means that the dApp or service does not get any exact attributes, only proof that you live up to their requirements.
+Some dApps or services may require you to prove that you are over a certain age, that you reside in a specific range of countries or area without revealing your exact age or country of residence, or that you have a certain type of education. You can choose whether you want to prove these :ref:`attributes<glossary-attribute>` to the dApp or service using your :ref:`account credentials<glossary-account-credential>` or :ref:`verifiable credentials<glossary-verifiable-credential>`. The dApp or service uses a :ref:`zero-knowledge proof<glossary-zero-knowledge-proof>` to request the attributes necessary for their service. This means that the dApp or service does not get any exact attributes, only proof that you live up to their requirements. You can choose which account (and thus identity) to use to fulfill the proof request for :ref:`account credentials<glossary-account-credential>` using the drop-down above the proof.
 
 .. image:: ../images/browser-wallet/zkp-one-attribute-ok.png
     :width: 75%
 
-When an attribute or attributes will be proven by zero knowledge proof but not revealed, the hidden icon |proof-zkp| appears next to the attributes to prove.
+When an attribute or attributes will be proven by zero-knowledge proof but not revealed, the **Zero-knowledge proof** heading appears on the card with the attributes to prove.
 
 If you do not meet one of the attributes in the statement, you would see a screen similar to below.
 
@@ -24,8 +24,6 @@ Other times the dApp or service may request that you **reveal** the information
 .. image:: ../images/browser-wallet/reveal-proof.png
     :width: 75%
 
-When an attribute or attributes are to be revealed, the shown icon |proof-reveal| appears next to the information to reveal and a warning triangle |reveal-warning| appears on the information card.
-
 .. Warning::
 
     By **proving** information to a third-party, it may become possible for them to deduce precise information about you. When you **reveal** information to a third-party, you effectively hand over your information to them. This means that you should only do this if you agree with their data usage and protection policies.
@@ -34,11 +32,23 @@ When an attribute or attributes are to be revealed, the shown icon |proof-reveal
 
 It is not possible for you to choose which attributes in the statement to prove/reveal or not prove/reveal. If there is something in the statement that you do not want to prove or reveal, you must reject the statement.
 
-It is also possible that a dApp could present a mixed statement that asks you to reveal one attribute and prove another. In the example below, the first name must be revealed and the user's age must be proven.
+It is also possible that a dApp could present a mixed statement that asks you to reveal one attribute and prove another. In the example below, the user's sex must be revealed and the user's age must be proven.
 
 .. image:: ../images/browser-wallet/mixed-statement-proof.png
     :width: 75%
 
+Another example of a mixed proof includes a request to prove information from your :ref:`verifiable credential<glossary-verifiable-credential>` and from your identity. The first screen is requesting you prove information from your verifiable credential. Click **Continue**.
+
+.. image:: ../images/browser-wallet/vc-mixed-proof-1.png
+    :alt: window with verifiable credential proof and continue button
+    :width: 50%
+
+The second screen is requesting you prove information from your account credential. You can choose which account (and thus identity) you want to use for the proof. Click **Approve** if you agree to prove the information. Click |reject| to reject the proof request.
+
+.. image:: ../images/browser-wallet/vc-mixed-proof-2.png
+    :alt: window with account credential proof and approve button
+    :width: 50%
+
 Example dApp
 ============
 
@@ -56,14 +66,9 @@ When the wallet receives a request, a screen similiar to below appears.
 .. image:: ../images/browser-wallet/zkp-one-attribute-ok.png
     :width: 75%
 
-Click **Accept** to allow the dApp or service to complete the proof or click **Reject** if you do not want to share this information.
-
-.. |proof-reveal| image:: ../images/browser-wallet/reveal-icon.png
-             :alt: eye
-             :width: 50px
-.. |proof-zkp| image:: ../images/browser-wallet/zkp-icon.png
-             :alt: eye with line through
-             :width: 50px
-.. |reveal-warning| image:: ../images/browser-wallet/reveal-warning.png
-             :alt: yellow warning triangle
-             :width: 50px
+Click **Accept** to allow the dApp or service to complete the proof or click **Reject** if you do not want to share this information. For more information about verifiable credentials and proofs, see :ref:`Web3 ID in the Concordium Wallet for Web<web3id-wallet>`.
+
+
+.. |reject| image:: ../images/browser-wallet/vc-reject-proof-button.png
+                    :width: 20px
+                    :alt: white x on red background

source/mainnet/net/index.rst

@@ -68,7 +68,7 @@ index
    :includehidden:
    :caption: Use Concordium's ID Layer
 
-   guides/create-proofs
+   web3-id/index
    guides/gallery/index
 
 .. toctree::

source/mainnet/net/release-notes/release-notes-lp.rst

@@ -129,14 +129,20 @@ Wallets
 |bw|
 -------------------------
 
-    August 17, 2023
+    September 11, 2023
 
-        |bw| 1.0.7 adds support for the `protocol version 6 <https://github.com/Concordium/concordium-update-proposals/blob/main/updates/P6.txt>`_ with Concordium BFT consensus which will be released August 21, 2023.
+        |bw| 1.1.7 introduces support for Web3 ID. Web3 ID is an extension of the core protocol identity with other types of credentials that don’t have stringent requirements on anonymity revocation, but can also witness a number of other attributes of the holder. Examples of this would be club membership credentials, reward programs, etc. There are no requirements imposed on who can be an issuer of these credentials, and in contrast to protocol identities, the Web3 ID credentials can be revoked according to the logic imposed by the issuer.
 
-        Additionally, Concordium plans to remove support for JSON-RPC in the |bw| on 1 November 2023. JSON-RPC allows a dApp to communicate with the same node as the wallet is connected to, and enables dApps to access the JSON-RPC interface without being connected to a separate server itself. In future, the wallet API will only use gRPC2. More information is forthcoming about how developers should prepare for this.
+        For wallet users, you can already use the Web3 ID functionality by using the `Concordia social media verifier on Mainnet <https://concordia.mainnet.concordium.software/>`_ or `Concordia social media verifier on Testnet <https://concordia.testnet.concordium.software/>`_. With Concordia, you can prove ownership of accounts on Telegram and Discord and thus transfer trust between the two platforms. Using the bots to issue credentials based on your Telegram and Discord logins allows you to link your accounts and optionally your real name. This is done in two steps. First, you get Web3 ID credentials for your accounts (e.g. one for Discord, one for Telegram). Then, a dApp checks the credentials and stores the verification. Other users can see your other linked accounts within the platform, transferring trust since they know you from another platform.
 
     .. dropdown:: Previous releases
 
+        .. dropdown:: |bw| 1.0.7 - August 17, 2023
+
+            |bw| 1.0.7 adds support for the `protocol version 6 <https://github.com/Concordium/concordium-update-proposals/blob/main/updates/P6.txt>`_ with Concordium BFT consensus which will be released August 21, 2023.
+
+            Additionally, Concordium plans to remove support for JSON-RPC in the |bw| on 1 November 2023. JSON-RPC allows a dApp to communicate with the same node as the wallet is connected to, and enables dApps to access the JSON-RPC interface without being connected to a separate server itself. In future, the wallet API will only use gRPC2. More information is forthcoming about how developers should prepare for this.
+
         .. dropdown:: |bw| 1.0.6 - May 30, 2023
 
             |bw| 1.0.6 contains fixes for the following issues: