diff --git a/source/mainnet/_templates/index.html b/source/mainnet/_templates/index.html index 4fecefce66..284ea52855 100644 --- a/source/mainnet/_templates/index.html +++ b/source/mainnet/_templates/index.html @@ -29,7 +29,7 @@

Earn CCDs

Earn CCDs by baking and delegating.

Develop with Concordium

Go through tutorials to learn about smart contracts and write your own smart contracts.

Downloads

Download Concordium software.

 -

Use ID

Use the Concordium ID layer.

 +

Use ID

Use the Concordium ID layer.

dApp examples

Example dApps for inspiration.

Concordium Academy

Learn about Concordium and get rewards.

 diff --git a/source/mainnet/net/guides/create-proofs.rst b/source/mainnet/net/guides/create-proofs.rst index 0d101b9877..e7c81fe613 100644 --- a/source/mainnet/net/guides/create-proofs.rst +++ b/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` is a business or use-case that provides a service contingent on the holder providing information about themselves using :ref:`verifiable credentials` or :ref:`account credentials` they have. A verifier will typically consist of two components: + +1. A dApp that interacts with the wallet and requests a :ref:`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 `_. + +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` to the dApp or service. The dApp or service constructs a list of :ref:`statements` to request a corresponding list of :ref:`zero knowledge proofs` 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` to the dApp or service. The dApp or service constructs a list of :ref:`statements` to request a corresponding list of :ref:`zero knowledge proofs` 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` 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` 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`. In this case, there is not a fixed list of attributes; it depends on the :ref:`issuer's needs`. + You can find more information about building proof statements in the `Concordium node SDK js repository `_. 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 `_. +.. _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 `__ or `Testnet `__, 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 `__ or use the `published Docker image `__. + Example dApp ============ diff --git a/source/mainnet/net/guides/proofs.rst b/source/mainnet/net/guides/proofs.rst index c93f60c463..f92f546bd8 100644 --- a/source/mainnet/net/guides/proofs.rst +++ b/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` to the dApp or service. The dApp or service uses a :ref:`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` to the dApp or service using your :ref:`account credentials` or :ref:`verifiable credentials`. The dApp or service uses a :ref:`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` 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` 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`. + + +.. |reject| image:: ../images/browser-wallet/vc-reject-proof-button.png + :width: 20px + :alt: white x on red background diff --git a/source/mainnet/net/images/browser-wallet/add-web3id-credential.png b/source/mainnet/net/images/browser-wallet/add-web3id-credential.png new file mode 100644 index 0000000000..710ad29f36 Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/add-web3id-credential.png differ diff --git a/source/mainnet/net/images/browser-wallet/mixed-statement-proof.png b/source/mainnet/net/images/browser-wallet/mixed-statement-proof.png index 15fa6983f3..561bb2cf8d 100644 Binary files a/source/mainnet/net/images/browser-wallet/mixed-statement-proof.png and b/source/mainnet/net/images/browser-wallet/mixed-statement-proof.png differ diff --git a/source/mainnet/net/images/browser-wallet/page-actions.png b/source/mainnet/net/images/browser-wallet/page-actions.png new file mode 100644 index 0000000000..63ab1d5b44 Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/page-actions.png differ diff --git a/source/mainnet/net/images/browser-wallet/proof-allowlisting.png b/source/mainnet/net/images/browser-wallet/proof-allowlisting.png new file mode 100644 index 0000000000..aea9ed07bc Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/proof-allowlisting.png differ diff --git a/source/mainnet/net/images/browser-wallet/proof-not-proved.png b/source/mainnet/net/images/browser-wallet/proof-not-proved.png new file mode 100644 index 0000000000..fc46594c01 Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/proof-not-proved.png differ diff --git a/source/mainnet/net/images/browser-wallet/reveal-icon.png b/source/mainnet/net/images/browser-wallet/reveal-icon.png deleted file mode 100644 index 5e8422cbb0..0000000000 Binary files a/source/mainnet/net/images/browser-wallet/reveal-icon.png and /dev/null differ diff --git a/source/mainnet/net/images/browser-wallet/reveal-proof.png b/source/mainnet/net/images/browser-wallet/reveal-proof.png index 327fa4b269..ffc41a9501 100644 Binary files a/source/mainnet/net/images/browser-wallet/reveal-proof.png and b/source/mainnet/net/images/browser-wallet/reveal-proof.png differ diff --git a/source/mainnet/net/images/browser-wallet/reveal-warning.png b/source/mainnet/net/images/browser-wallet/reveal-warning.png deleted file mode 100644 index e5c208d8e7..0000000000 Binary files a/source/mainnet/net/images/browser-wallet/reveal-warning.png and /dev/null differ diff --git a/source/mainnet/net/images/browser-wallet/vc-details.png b/source/mainnet/net/images/browser-wallet/vc-details.png new file mode 100644 index 0000000000..8408b33b70 Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/vc-details.png differ diff --git a/source/mainnet/net/images/browser-wallet/vc-import.png b/source/mainnet/net/images/browser-wallet/vc-import.png new file mode 100644 index 0000000000..c84a9afbf7 Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/vc-import.png differ diff --git a/source/mainnet/net/images/browser-wallet/vc-mixed-proof-1.png b/source/mainnet/net/images/browser-wallet/vc-mixed-proof-1.png new file mode 100644 index 0000000000..1a46f9fda8 Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/vc-mixed-proof-1.png differ diff --git a/source/mainnet/net/images/browser-wallet/vc-mixed-proof-2.png b/source/mainnet/net/images/browser-wallet/vc-mixed-proof-2.png new file mode 100644 index 0000000000..569e164930 Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/vc-mixed-proof-2.png differ diff --git a/source/mainnet/net/images/browser-wallet/vc-reject-proof-button.png b/source/mainnet/net/images/browser-wallet/vc-reject-proof-button.png new file mode 100644 index 0000000000..18569642ac Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/vc-reject-proof-button.png differ diff --git a/source/mainnet/net/images/browser-wallet/verifiable-credential.png b/source/mainnet/net/images/browser-wallet/verifiable-credential.png new file mode 100644 index 0000000000..88b54a97e2 Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/verifiable-credential.png differ diff --git a/source/mainnet/net/images/browser-wallet/web3id-credential.png b/source/mainnet/net/images/browser-wallet/web3id-credential.png new file mode 100644 index 0000000000..c037d3652c Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/web3id-credential.png differ diff --git a/source/mainnet/net/images/browser-wallet/web3id-diagram.png b/source/mainnet/net/images/browser-wallet/web3id-diagram.png new file mode 100644 index 0000000000..3216fa6089 Binary files /dev/null and b/source/mainnet/net/images/browser-wallet/web3id-diagram.png differ diff --git a/source/mainnet/net/images/browser-wallet/zkp-icon.png b/source/mainnet/net/images/browser-wallet/zkp-icon.png deleted file mode 100644 index c9e1f275e9..0000000000 Binary files a/source/mainnet/net/images/browser-wallet/zkp-icon.png and /dev/null differ diff --git a/source/mainnet/net/images/browser-wallet/zkp-one-attribute-ok.png b/source/mainnet/net/images/browser-wallet/zkp-one-attribute-ok.png index 8050cf7e35..f369046f35 100644 Binary files a/source/mainnet/net/images/browser-wallet/zkp-one-attribute-ok.png and b/source/mainnet/net/images/browser-wallet/zkp-one-attribute-ok.png differ diff --git a/source/mainnet/net/images/web3id/web3id-entities.png b/source/mainnet/net/images/web3id/web3id-entities.png new file mode 100644 index 0000000000..038935a258 Binary files /dev/null and b/source/mainnet/net/images/web3id/web3id-entities.png differ diff --git a/source/mainnet/net/index.rst b/source/mainnet/net/index.rst index 25f9e882de..4c2c51cd65 100644 --- a/source/mainnet/net/index.rst +++ b/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:: diff --git a/source/mainnet/net/release-notes/release-notes-lp.rst b/source/mainnet/net/release-notes/release-notes-lp.rst index e53dddf7f5..d7d7b98d4b 100644 --- a/source/mainnet/net/release-notes/release-notes-lp.rst +++ b/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 `_ 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 `_ or `Concordia social media verifier on Testnet `_. 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 `_ 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: diff --git a/source/mainnet/net/resources/glossary.rst b/source/mainnet/net/resources/glossary.rst index 0cce4901d6..edbc4285d8 100644 --- a/source/mainnet/net/resources/glossary.rst +++ b/source/mainnet/net/resources/glossary.rst @@ -24,6 +24,17 @@ with the account holder's :ref:`identity`, although this asso for anonymity. This anonymity can only be revoked by :ref:`anonymity revokers`, in cooperation with the account's :ref:`identity provider`. +.. _glossary-account-credential: + +Account credential +================== + +A certificate derived from the :ref:`glossary-identity-object` that proves that +the owner has been verified by an identity provider. The key feature of the +credential is that it **does not** identify the owner to the identity provider, +nor to any other single entity, however it contains enough information to allow +anonymity revokers in concert with the identity provider to find the owner. + .. _glossary-alias: Alias @@ -211,11 +222,7 @@ The consensus protocol for the blockchain. The protocol offers high transaction Credential ========== -A certificate derived from the :ref:`glossary-identity-object` that proves that -the owner has been verified by an identity provider. The key feature of the -credential is that it **does not** identify the owner to the identity provider, -nor to any other single entity, however it contains enough information to allow -anonymity revokers in concert with the identity provider to find the owner. +See :ref:`account credential`. .. _glossary-credential-holder: @@ -224,12 +231,19 @@ Credential holder The user holding a credential. An account is owned by one or more credential holders. +.. _glossary-credential-registry-contract: + +Credential registry contract +============================ + +A smart contract used by :ref:`issuers` of :ref:`verifiable credentials` to register credentials when they are issued. This contract will also be used to track the state of a credential, e.g., valid, revoked, expired. + .. _glossary-cryptographic-proof: Cryptographic proof =================== -A method by which one party (the prover) can prove to another party (the verifier) that a given statement is true while the prover avoids conveying any additional information apart from the fact that the statement is indeed true. This is known as a zero-knowledge proof. +A method by which one party (the prover) can prove to another party (the verifier) that a given statement is true while the prover avoids conveying any additional information apart from the fact that the statement is indeed true. This is known as a :ref:`zero-knowledge proof`. .. _glossary-decryption-key: @@ -377,6 +391,13 @@ Invoke means to call something into effect. Invoke is also the act of triggering a receive function in a smart contract from ``concordium-client`` and viewing its return value. Invoking an instance is not a transaction and it does not change the state of a contract. Invoking can be useful to either view information about the instance or to test a receive method before running an update. Because invoking is not a transaction, there is no fee to run invoke. Click :ref:`here to see examples of how to use invoke to view information about the instance`. +.. _glossary-issuer: + +Issuer +====== + +Party that issues Web3 ID credentials to users. May also revoke Web3 ID credentials. + .. _glossary-leader-election: Leader Election @@ -728,6 +749,27 @@ User identity certificate Issued to the individual or entity once their real-world identity has been verified and recorded by an Identity Provider. You cannot use the Concordium Platform without a User Identity Certificate. The user identity certificate includes attributes such as name, age, and nationality. When the Identity Provider has validated the attributes, it issues a user identity certificate, which is basically the Identity Provider’s signature over some cryptographic keys of the user and the validated personal attributes. Unlike usual public key certificates such as X.509 certificates, the user identity certificate is private to the user; it is not submitted to the chain. Note that the Identity Provider also stores some information, but this is only used for a possible, subsequent investigation of the user’s activities (i.e. anonymity revocation). The Identity Provider is not involved in any subsequent use of the user identity certificate. The user identity certificate is signed using the Pointcheval-Sanders signature scheme. +.. _glossary-verifiable-credential: + +Verifiable credential +===================== + +Issued to the individual by an :ref:`issuer` who has authority for the credential to be issued. A verifiable credential contains some information about the individual that does not necessitate :ref:`anonymity revocation`, such as membership in a club or loyalty program, education, and more. Verifiable credentials can be checked by a :ref:`verifier` using :ref:`zero-knowledge proofs`. The issuer can choose to have the verifiable credential expire, or revoke it, if necessary. The issuer manages the verifiable credentials with a smart contract, a credential registry contract. + +.. _glossary-verifiable-presentation: + +Verifiable presentation +======================= + +Data derived from one or more verifiable credentials and/or account credentials, issued by one or more issuers or identity providers, that is shared with a specific verifier. A verifiable presentation is tamper-evident and encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. It contains a link that points to the contract and holder ID. A presentation that contains a **zero-knowledge proof** might contain data that confirms the truth of a statement from verifiable credentials or account credentials, but the presentation does not reveal the actual attributes of verifiable credentials. + +.. _glossary-verifier: + +Verifier +======== + +Party that checks users' :ref:`verifiable credentials`. + .. _glossary-wallet: Wallet @@ -750,6 +792,13 @@ The |bw| The |bw| is a web browser extension wallet that enables you to create and manage your Concordium identities and accounts, to create simple transactions, and to connect to dApps. +.. _glossary-web3-id: + +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. This could be that the credential holder can revoke it, the credential expires, or the issuer or some other third party has rights to revoke it. + .. _glossary-web-assembly: WebAssembly diff --git a/source/mainnet/net/resources/legal.rst b/source/mainnet/net/resources/legal.rst index f8c5efead0..51048c48a4 100644 --- a/source/mainnet/net/resources/legal.rst +++ b/source/mainnet/net/resources/legal.rst @@ -12,6 +12,7 @@ The following topics relate to terms and conditions of use as well as notices an terms-and-conditions terms-and-conditions-dw terms-and-conditions-mw + terms-and-conditions-concordia third-party-licenses third-party-notices bw-licenses diff --git a/source/mainnet/net/resources/terms-and-conditions-concordia.rst b/source/mainnet/net/resources/terms-and-conditions-concordia.rst new file mode 100644 index 0000000000..a2bd2c5c83 --- /dev/null +++ b/source/mainnet/net/resources/terms-and-conditions-concordia.rst @@ -0,0 +1,77 @@ +.. include:: ../../variables.rst +.. _terms-and-conditions: + +=============== +About Concordia +=============== + +Concordia is a chat bot, currently available for Discord and Telegram, with extensions for other platforms in the future. + +Concordia is able to talk to an issuer service that is able to issue proof of ownerships of your Telegram and Discord profiles. These proofs are then sent to your Conñcordium Wallet as Verified Credentials. + +Once the wallet holder (you) possess proof of your Telegram and/or Discord profiles, you can use the Wallet functionality to confirm your identity to Concordia. This verification process leverages the trust and security offered by blockchain technology. + +This service enables you to validate that your Telegram handle and Discord name indeed belong to you. Consequently, by asking Concordia inside the Telegram or Discord channel, other community members can confidently verify if a user in the Telegram channel is the same person as behind a Discord profile (or vice versa). + +If you would like to add an extra layer of identity verification the service running behind Concordia allows you to provide a proof of your actual name as it appears in your Concordium Wallet. Concordia will now include your name in addition to your Telegram and Discord profile names. + +This service is entirely free to use, as all transaction costs for creating the proofs are covered by the service operator. + +Terms of service +================ + +The Concordia bot and the services issuing verified credentials and verifying Telegram and Discord users are provided by Concordium Software ApS free of charge on an AS-IS basis. The services are designed to showcase in a simple way how the Web3 ID infrastructure may be utilized. + +Any new features or references to tools and functionality that are added to the Site shall also be subject to these Terms. Any part of these terms may be updated, changed, or replaced by posting updates and/or changes to the Site, https://concordia.mainnet.concordium.software/. You can review the most current version of the Terms at any time on this page. Your continued use of or access to the Site following the posting of any changes constitutes acceptance of those changes. + +Your profile is your responsibility. You are the only person with access to your wallet. It contains your personal data and you are responsible for keeping the wallet secure through protection of your access credentials that only you have. It is important to understand that you are the only party to any transaction on the Concordium blockchain. + + +If you’re not comfortable with interacting with an inherently transparent blockchain, you should not engage with the Site to issue or verify social media proofs. You are solely responsible for the safekeeping of the private key (key phrase) associated with the blockchain address used to interact with the Site. The transactions on a blockchain, including transfer of data, are permanent and cannot be undone. + +The Site uses functionality on the Concordium blockchain, but has no influence on the operation or integrity of this network. This network, or the services provided by the network to Concordia may not be available in the future. + +There is no guarantee, actual or implied, that this site or functionality will function according to expectations, or be available at any time in the future. The site may be discontinued, suspended, or modified without notice. The components referred to on this site are outside our control and may be accessible without the use of this site. + +Services may be refused or ceased to anyone or everyone for any reason at any time. + +Access to the site is conditional on your acceptance of the attached privacy guidelines. These specifically address the storage of encrypted personal data, by yourself, as part of the interactions recommended by this Site. + +This Site has no relationships with the Social Media sites such as Discord and Telegram. + +Privacy policy +============== + +When using this service you agree and accept that certain data will be made public and at the same time this data will be collected by Concordium Software ApS in order to deliver the service. + +When you instruct the service to verify you are the owner of a Telegram or Discord profile, the service will register and store your Telegram or Discord handle as well as your user ID. + +When you issue a proof that your Telegram and Discord handles both, and at the same time, belong to you, you present the Verified Credentials in your Concordium Wallet to the service. The service will store this information so that when other community members queries Concordia to verify your Telegram or Discord name, the service will be able to provide Concordia with the stored information. This includes your actual name should you have chosen to make it public. + +When you use this service you understand that any personal information you choose to make public cannot be deleted by the service. The service itself fully supports the right to be forgotten and you may at any time be deleted from the service. Doing this means the Concordia bot(s) will no longer be able to verify your identities when prompted by other community members. + +The following items of personal data are collected by the Service: + +- Discord and Telegram handles. +- Your real name should you choose to reveal it +- Generated proofs. + +These are collected to provide the functionality needed to run the service. + +Tracking technologies may be used that automatically collect information limited to the following: + +- Session Cookies, that are necessary for you to browse the Site efficiently + +The site may also collect data from activity that is publicly visible and/or accessible on blockchains or social media sites. + +Right to deletion +================= + +Should you wish to be removed from the service you can invalidate your proof by clicking the “Remove Verification?” link on the Site. This will allow you to authenticate with your original Telegram and Discord verified credentials stored in your Concordium Wallet and complete your deletion. + +Revision of Policy +================== + +This privacy policy may be revised and reissued at any time. Any changes will be effective immediately upon our posting of the revised Privacy Policy. For the avoidance of doubt, your continued use of the Site indicates your consent to the revised Privacy Policy. + +If you have any question in regards to this Privacy Policy please contact: support@concordium.software. diff --git a/source/mainnet/net/web3-id/concordia.rst b/source/mainnet/net/web3-id/concordia.rst new file mode 100644 index 0000000000..2c838df0f5 --- /dev/null +++ b/source/mainnet/net/web3-id/concordia.rst @@ -0,0 +1,45 @@ +.. _concordia: +.. include:: ../../variables.rst + +.. meta:: + :description lang=en: + Concordia is an example Web3 ID solution that allows you to transfer trust between Telegram and Discord. + +========= +Concordia +========= + +Concordia is an example solution built on Web3 ID. It allows you to transfer trust between Telegram and Discord. Using verifiable credentials in the |bw|, you can prove ownership of accounts on Telegram and Discord. This is done by allowing users to link their accounts and, optionally, real name. You can also ``/check`` and ``/verify`` other users in Telegram and Discord. In other words, if you know John Doe in one platform, you can also trust him in the other platform using his verifiable credentials. + +To issue credentials and perform verification that these are your credentials, you can use the Concordia Social media verifier. The Concordia Social media verifier performs all the steps needed for you to allow transfer of trust of your user between platforms. + +`Concordia social media verifier on Mainnet `_ + +`Concordia social media verifier on Testnet `_ + +To get started, log in with your social media account to get verifiable credentials for your accounts (e.g. one for Discord, one for Telegram) in the **Issue credentials** drop-down. + +In the **Verification** drop-down, you prove ownership of the social media accounts for the verifiable credentials you added to your |bw|. + +The Concordia Social media verifier provides links to check that your verification was completed successfully in the **Check verification** drop-down. + +If you want to remove your verification, click **Remove verification** in the Concordia Social media verifier and select the social media platform for which you hold credentials in the wallet. For example, if you want to remove verification with verifiable credentials issued for Telegram then you would select Telegram. + +Note that after verification was removed, it is not possible to prove ownership over Telegram or Discord accounts unless the process of verification is done again. + +Concordium's bots +================= + +To verify that you are using the real Concordium bots configured in our channels, use this reference: + +Telegram - Mainnet - @ConcordiaWeb3IDBot + +Discord- Mainnet - Concordia#0667 + +There is an example of independent issuers with the user interface that can be used to issue verifiable credentials for the account that is owned on the social media network. After verifiable credentials are issued, they can be used to prove ownership of social media accounts and transfer trust between them by using Concordia social media verifier on `Testnet `__ or `Mainnet `__. + +On Mainnet, use the links below: + +`Telegram issuer on Mainnet `_ + +`Discord issuer on Mainnet `_ diff --git a/source/mainnet/net/web3-id/index.rst b/source/mainnet/net/web3-id/index.rst new file mode 100644 index 0000000000..852a6617e5 --- /dev/null +++ b/source/mainnet/net/web3-id/index.rst @@ -0,0 +1,107 @@ +.. _web3id-index: +.. include:: ../../variables.rst + +.. meta:: + :description lang=en: + ID is an integral part of the Concordium blockchain. Web3 ID expands on our ID layer and allows anyone to become a credential issuer. + +====================== +Identity on Concordium +====================== + +Concordium’s identity layer is built into the protocol. Every account on the chain has one or more credentials issued by specially sanctioned identity providers who are expected to be able to provide full anonymity revocation. ID 2.0 made it possible to use these identities off-chain: wallets allow using identities to prove properties about the holder, such as their nationality or age. These are known as :ref:`account credentials`. + +.. image:: ../images/mobile-wallet/MW12.png + :width: 25% + +You can read more about the identity provider issued account credentials in :ref:`Identities`. + +Web3 ID +======= + +Web3 ID is an extension of the existing ID 2.0 infrastructure in Concordium to allow issuance of many different types of :ref:`verifiable credentials` in addition to the existing :ref:`account credentials`. Web3 ID allows you to add :ref:`verifiable credentials` to your |bw|, such as club memberships, education credentials, employment history, rewards programs, customer loyalty programs, and more. :ref:`Proofs` can be made to verify these credentials, if necessary. + +.. image:: ../images/browser-wallet/add-web3id-credential.png + :alt: window with pending credential and option buttons + :width: 25% + +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 prove a number of other attributes of the holder. Examples of this could 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 verifiable credentials can be revoked according to the logic imposed by the issuer. This could be that the credential holder can revoke it, the credential expires, or the issuer or some other third party has rights to revoke it. + +Verifiable credentials, like account credentials, will contain commitments to a variety of attributes. :ref:`Zero-knowledge proofs` can be constructed to verify the committed values. The |bw| supports construction of these proofs. The proofs can contain a mix of verifiable credentials and account credentials. + +Entities +======== + +The core entities of the Web3 ID ecosystem are :ref:`issuers` which issue and manage the lifetime of verifiable credentials, and :ref:`holders` that have verifiable credentials in their wallets, and use them to prove properties about themselves to :ref:`verifiers`. + +The issuer is an entity that issues verifiable credentials. Issuers have a smart contract that holds credential lifetime metadata, a back-end service that has logic for identifying users and sending transactions to the smart contract, and a dApp that interacts with the user’s wallet and the back end to facilitate issuance of credentials. + +Verifiers ask holders for proofs about their attributes, such as proof of club membership, and holders respond with zero knowledge proofs created using their verifiable credentials. Verifiers have a back-end service that checks :ref:`verifiable presentations` and provides a service, And a dApp that facilitates interaction with the wallet, making requests. + +A user/wallet holds verifiable credentials, produces verifiable presentations, and interacts with the issuer and verifier. Verifiable credentials themselves never leave the user's wallet. + +.. image:: ../images/web3id/web3id-entities.png + +Issuance flow for verifiable credentials +======================================== + +The following diagram shows the issuance flow for verifiable credentials. + +.. image:: ../images/browser-wallet/web3id-diagram.png + :alt: diagram of verifiable credential flow + :width: 75% + +#. A user initiates a request for a verifiable credential from an :ref:`issuer's` dApp. +#. The issuer makes a request to the user's wallet for adding Web3ID credential. The request contains attributes and metadata. +#. After reviewing what has been sent by the issuer, the user accepts or rejects the request. If denied, the process stops here. +#. If accepted, they generate a fresh credential holder ID and the wallet sends their credential ID (public key) to the issuer back end. +#. The issuer verifies the request, and if OK, registers the credential metadata (validity period, styling, logo, colors) in the smart contract under the received credential ID. +#. The issuer signs the attributes and returns a verifiable credential to the dApp which then sends it to the wallet, thus making the user a :ref:`holder`. + +Support for issuers and verifiers +================================= + +Concordium understands that issuers and verifiers may not have the resources to create a smart contract from scratch and the other tooling needed to issue and prove verifiable credentials. +So tooling is provided that enables you to become an issuer and verify credentials as painlessly as possible. + +Issuer +------ + +An issuer will typically consist of the following components. + +1. Some existing way of identifying users. +2. A dApp that integrates with the wallet and allows the holder to request credential. An example dApp is the `Concordia social media verifier on Testnet `_. +3. A smart contract that manages the credential lifetime. When a verifiable credential is issued the metadata is stored in the contract, and the attributes and other secrets, the full verifiable credential, are returned to the dApp to be stored in the wallet. + +To ease the process of becoming an issuer, Concordium has created the `Concordium Web3 ID Issuer Front End `__ where you can quickly and easily become an issuer. + +In order to simplify issuance as much as possible Concordium provides a `template smart contract `_ that is expected to suffice for most of the issuers, but can be modified if custom logic is required. + +As an alternative to the Concordium Web3 ID Issuer Front End, Concordium additionally provides an `issuer service `_ that is designed to handle all of the chain-specific interactions, and provides a simple REST API, so that only the custom business logic of the issuer must be implemented. Note that the service must be run by the issuer themselves, since only they have the secret keys necessary to run it. + +Regardless of whether you use the Concordium Web3 ID Issuer Front End or the issuer service, the issuer must provide JSON schemas for their credentials, and metadata. These schemas and metadata are used by the holder's wallet to display the credentials in the wallet. + +Verifier +-------- + +A verifier is expected to be a business or another use-case that will only provide a service provided specific proofs can be provided by the holder, for example proof of ownership of specific credential, such as a concert ticket. +This will typically consist of two components. + +1. A dApp that will interact with the wallet to request from the user to attest to specific properties of their credentials. The result of such a request is a :ref:`verifiable presentation`. +2. A back-end component that will verify the provided verifiable presentation and allow the desired action or not. + +Verification of presentations has two components, the cryptographic verification of the zero-knowledge proofs contained within, which establish that the holder indeed owns the relevant credentials and they are issued by the stated issuer, and the business logic checking that the required property was attested. +In particular, a key part of the business logic is whether the verifier trusts a particular issuer, which is identified by a smart contract address and the public key registered therein. + +Concordium runs an instance of the verifier for `Mainnet `_ or `Testnet `__. Using Concordium hosted services means that the verifier places trust in Concordium, but simplifies the implementation of the verifier. You still have to provide a user interface or front end (usually a dApp) that calls the Concordium hosted verifier. Otherwise, if you want to run the verification service yourself, Concordium simplifies the checking of the cryptographic part by providing a `verifier service `_. To read more about the verification service, see :ref:`Tool to verify credentials`. + +An example verifier dApp is the `Concordia social media verifier on Testnet `_, and an example back end can be found in `the Web3 ID repository `. + +.. toctree:: + :hidden: + :maxdepth: 1 + + wallet + issuer + ../guides/create-proofs + concordia diff --git a/source/mainnet/net/web3-id/issuer.rst b/source/mainnet/net/web3-id/issuer.rst new file mode 100644 index 0000000000..c78b9360eb --- /dev/null +++ b/source/mainnet/net/web3-id/issuer.rst @@ -0,0 +1,78 @@ +.. _web3id-issuer: +.. include:: ../../variables.rst + +.. meta:: + :description lang=en: + Anyone can become an issuer of verifiable credentials for Web3 ID. Concordium provides an easy issuer tool to start the process. + +=============== +Web3 ID issuers +=============== + +Web3 ID includes many types of credentials that are not identity credentials. This might be employment history, certifications from educational courses or diplomas, membership in loyalty clubs or rewards programs, and more. Because of this anyone can become an :ref:`issuer`! + +How to become an issuer +======================= + +An issuer needs to have the following components. + +1. Some way of identifying users to whom the credentials will be issued, e.g., an existing database of users. +2. JSON schemas and metadata for credentials. These are used by the wallet to display and style the credential. This might be a logo, a background color, how the attributes will appear in the credential (e.g., date format, title), and so on. The `Concordium Web3 ID Issuer Front End `__ helps with setting up your metadata. +3. A smart contract where credential lifetime is managed, together with its metadata such as expiry time. The `Concordium Web3 ID Issuer Front End `__ helps with setting up your credential registry contract. +4. A dApp where the user will request credentials with the help of the wallet. +5. A back end which will issue credentials, which involves registering the credential in the smart contract, and returning it to the holder's wallet. + +To make it easier to become an issuer, you can use the `Concordium Web3 ID Issuer Front End `__. This tool walks you through steps two and three when becoming an issuer. + +Concordium Issuer tool +---------------------- + +Concordium also provides a generic issuer for Web3ID credentials. It exposes a REST API for registering credentials, and handles the correct formatting of credentials to submit to the chain, and communication with the node. + +Concordium provides Docker images to make it simple to run the issuer tool, but the issuer themselves have to run it since issuing credentials requires access to private keys of the issuer, and payment of transaction fees. + +The issuer has the following endpoints: + +- ``POST v0/issue`` + +- ``GET v0/status/:transactionHash`` + +The status endpoint returns the minimal status of a transaction. + +If the transaction is not present it returns the 404 status code. If the return code is 200, then the response is a JSON body with the following fields: + +- status (required) either "finalized" or "notFinalized". + +- block (optional) and present if status is "finalized". The block hash in which the transaction is finalized. + +- success (optional) and present if status is "finalized". A boolean indicating whether the transaction was successful. + +An example response is: + +.. code-block:: json + + { + "status": "finalized", + "block": "075a91a1b371a0bb532f357cef3fb126da3580640ddc18963e6f11f9573655cf", + "success": true + } + +The issuer endpoint accepts a JSON body with the request to issue the credential and if successful returns a transaction hash that may be queried for status. + +.. todo:: + + JSON Schemas for requests and responses are available at (link). + +Credential metadata controls how the credential is displayed in the wallet. An example is: + +.. code-block:: json + + { + "title": "Mixed credential", + "logo": { + "url": "https://avatars.gibhubusercontent.com/u/39614219?s=200&v=4" + }, + "backgroundColor": "#ffaa00" + } + +You can update the metadata for verifiable credentials, such as title, image, colors, or localization, but the credential attributes cannot be edited once the smart contract is deployed. diff --git a/source/mainnet/net/web3-id/wallet.rst b/source/mainnet/net/web3-id/wallet.rst new file mode 100644 index 0000000000..6ec232f231 --- /dev/null +++ b/source/mainnet/net/web3-id/wallet.rst @@ -0,0 +1,139 @@ +.. _web3id-wallet: +.. include:: ../../variables.rst + +.. meta:: + :description lang=en: + Web3 ID allows you to add and use verifiable credentials in the wallet for interactions with services that require verification. + +===================== +Web3 ID in the |bw| +===================== + +Web3 :ref:`verifiable credentials` are available in the |bw|. They might have any of the following states: + +- Pending: the verifiable credential is in the process of being issued +- Active: the verifiable credential is issued and valid +- Revoked: the verifiable credential is no longer valid because the holder or issuer has canceled it +- Not activated: the verifiable credential is issued but is not yet active because its *valid from date* has not passed, e.g. a concert ticket +- Expired: the verifiable credential is past the *valid until date*, e.g. a concert ticket + +Add verifiable credentials to the wallet +======================================== + +When choosing to add verifiable credentials from an issuer, make sure that you *trust* the issuer to whom you are revealing information about yourself. + +#. Contact the issuer of the verifiable credentials using the dApp the issuer provides and provide the information requested by the issuer. + +#. The issuer sends a request to your |bw| to issue a verifiable credential. Click **Cancel** to stop the process or click **Add credential** to continue. You will see the verifiable credential as **Pending**. + + .. image:: ../images/browser-wallet/add-web3id-credential.png + :alt: window with pending credential and option buttons + :width: 50% + +To see the details of the verifiable credential: + +#. Click |hamburger-bw| and select **Verifiable credentials**. + +#. Click on the verifiable credential card. + +#. Click |actions-bw| and select **Details**. + + .. image:: ../images/browser-wallet/vc-details.png + :alt: window with card showing details of the verifiable credential + :width: 50% + +Backup verifiable credentials +============================= + +#. Click |hamburger-bw| and select **Verifiable credentials**. + +#. Click |actions-bw| and select **Download export file**. This saves the verifiable credentials in a file called *web3IdCredentials.export* in your downloads folder by default. + +Revoke verifiable credentials +============================= + +In some cases, the issuer of the verifiable credential may allow you to revoke a credential yourself in your |bw| if you no longer need it. + +#. Click |hamburger-bw| and select **Verifiable credentials**. + +#. Click on the verifiable credential card to revoke. + +#. Click |actions-bw| and select **Revoke**. + +#. Review the transaction information and click **Send**. + +Recover verifiable credentials +============================== + +#. Click |hamburger-bw| and select **Verifiable credentials**. + +#. Click |actions-bw| and select **Open import window**. + +#. Click **Select file to import**. Navigate to the location that the *web3IdCredentials.export* file is located and select the file. + + .. image:: ../images/browser-wallet/vc-import.png + :alt: window with button to navigate to import file location + :width: 50% + +#. The verifiable credentials that could be imported from the file are added to the wallet. + +Use verifiable credentials +========================== + +In cases where a verifier asks to prove your verifiable credentials, you are asked to generate a :ref:`verifiable presentation` in the |bw| to prove or reveal information. Proofs or revealing information can be: + +- Only verifiable credentials +- Only account credentials +- A mix of verifiable and account credentials + +You can choose which account (and thus identity) and/or verifiable credential to use to prove/reveal the requested attributes. + +It is important to understand the difference between a proof request and a reveal request. For more information, see :ref:`Proofs and revealing information`. + +In the case below, the proof from the verifier is a mixed proof that requests you reveal the degree name and you prove that were born within a date range. This is a mixed proof because it asks you to reveal and prove information, and also because it asks to prove/reveal information from your verifiable credential and your account credential. Because your date of birth is not in the date range that statement cannot be proven and your only option is to reject the request. You never see the reveal request because you do not meet the requirement from the other part of the proof. + +.. image:: ../images/browser-wallet/proof-not-proved.png + :alt: window with button to reject proof request + :width: 50% + +Another example of a mixed proof includes a request to prove information from your 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% + +These are just a few examples of how you might see proof requests in the |bw|, but the possibilities for what a verifier might request are limitless for verifiable credentials. The identity provider issued attributes that can be revealed from :ref:`account credentials` are: + +- First name +- Last name +- Sex +- Date of birth +- Country of residence +- Country of nationality +- ID document type +- ID document number +- ID document issuer +- ID valid from +- ID valid to +- National ID number +- Tax ID number + + + +.. |hamburger-bw| image:: ../images/browser-wallet/hamburger-menu.png + :width: 20px + :alt: three horizontal lines + +.. |actions-bw| image:: ../images/browser-wallet/page-actions.png + :width: 20px + :alt: three horizontal lines + +.. |reject| image:: ../images/browser-wallet/vc-reject-proof-button.png + :width: 20px + :alt: white x on red background