From a9dd6ae3c5a178540f32c9aefab5731bcd3c712b Mon Sep 17 00:00:00 2001 From: AgneCaunt <139773510+AgneCaunt@users.noreply.github.com> Date: Mon, 6 Jan 2025 15:46:56 +0200 Subject: [PATCH 1/9] Update concepts_claim_deduction.md --- tutorials/src/concepts_claim_deduction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tutorials/src/concepts_claim_deduction.md b/tutorials/src/concepts_claim_deduction.md index b3a56fe6a..892e4a271 100644 --- a/tutorials/src/concepts_claim_deduction.md +++ b/tutorials/src/concepts_claim_deduction.md @@ -4,7 +4,7 @@ The [verifiable credentials data model](https://www.w3.org/TR/vc-data-model/) is Every VCDM credential is representable as an RDF graph. So computers can reason about them, deriving new conclusions that weren't explicitly stated by the issuer. -The Dock SDK exposes utilities for primitive deductive reasoning over verified credentials. The Verifier has a choice to perform deduction themself (expensive), or offload that responsibility to the Presenter of the credential[s] by accepting deductive proofs of composite claims. +The Truvera Credential SDK exposes utilities for primitive deductive reasoning over verified credentials. The Verifier has a choice to perform deduction themself (expensive), or offload that responsibility to the Presenter of the credential[s] by accepting deductive proofs of composite claims. In RDF, if graph A is true and graph B is true, then the [union]() of those graphs, is also true `A∧B->A∪B` [^1]. Using this property we can combine multiple credentials and reason over their union. From f5e5c4a3190885f7dbdde3552b90027641496946 Mon Sep 17 00:00:00 2001 From: AgneCaunt <139773510+AgneCaunt@users.noreply.github.com> Date: Mon, 6 Jan 2025 15:58:10 +0200 Subject: [PATCH 2/9] Update concepts_poe_anchors.md --- tutorials/src/concepts_poe_anchors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tutorials/src/concepts_poe_anchors.md b/tutorials/src/concepts_poe_anchors.md index 83cf870cb..53e4bcb33 100644 --- a/tutorials/src/concepts_poe_anchors.md +++ b/tutorials/src/concepts_poe_anchors.md @@ -2,4 +2,4 @@ The Dock Blockchain includes a module explicitly intended for proof of existence The PoE module accepts arbitrary bytes as an anchor but in order to keep anchor size constant the chain stores only the blake2b256 hash of those bytes. -Developers are free to use the anchoring module however they want, taloring their software to their own use case. An anchoring example can be found in the sdk examples directory. Dock provides a [fully functioning reference client](https://fe.dock.io/#/anchor/batch) for anchoring. The client even implements batching anchors into a merkle tree so you can anchor multiple documents in a single transaction. +Developers are free to use the anchoring module however they want, taloring their software to their own use case. An anchoring example can be found in the sdk examples directory. Dock Labs provides a [fully functioning reference client](https://fe.dock.io/#/anchor/batch) for anchoring. The client even implements batching anchors into a merkle tree so you can anchor multiple documents in a single transaction. From 8746407abd5dddc914beb0ad1edbe30ae1ba41d4 Mon Sep 17 00:00:00 2001 From: AgneCaunt <139773510+AgneCaunt@users.noreply.github.com> Date: Mon, 6 Jan 2025 16:09:42 +0200 Subject: [PATCH 3/9] Update concepts_private_delegation.md --- tutorials/src/concepts_private_delegation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tutorials/src/concepts_private_delegation.md b/tutorials/src/concepts_private_delegation.md index f6aea3873..da3e0d08e 100644 --- a/tutorials/src/concepts_private_delegation.md +++ b/tutorials/src/concepts_private_delegation.md @@ -1,6 +1,6 @@ # Private Delegation -Claim Deduction rules can express delegation of authority to issue credentials! It's expected to be a common enough use case that Dock has declared some rdf vocabulary and associated claim deduction rules aid potential delegators. +Claim Deduction rules can express delegation of authority to issue credentials! It's expected to be a common enough use case that Dock Labs has declared some rdf vocabulary and associated claim deduction rules aid potential delegators. An issuer may grant delegation authority to another issuer simply by issuing them a vcdm credential. Let's say `did:ex:a` wants to grant delegation authority to `did:ex:b`. `did:ex:a` simply issues the credential saying that `did:ex:b` may make any claim. @@ -23,4 +23,4 @@ When `did:ex:b` wishes to issue a credential on behalf of `did:ex:a`, they shoul In order to process delegated credentials a verifier accepts a bundle. The bundle includes both delegations and credentials issued by delegates. After verifying every credential within the bundle (including the delegations) the verifier uses [Claim Deduction](concepts_claim_deduction.md) to determine which statements are proven by the delegated credential. -Dock's delegation ontology (i.e. rdf vocabulary) and ruleset are currently in alpha. See [Private Delegation](tutorial_private_delegation.md) for an example of their use. +Dock Labs' delegation ontology (i.e. rdf vocabulary) and ruleset are currently in alpha. See [Private Delegation](tutorial_private_delegation.md) for an example of their use. From 44e9c7260016bb8a398e6e5f9896403313e97644 Mon Sep 17 00:00:00 2001 From: AgneCaunt <139773510+AgneCaunt@users.noreply.github.com> Date: Mon, 6 Jan 2025 16:14:18 +0200 Subject: [PATCH 4/9] Update concepts_public_attestation.md --- tutorials/src/concepts_public_attestation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tutorials/src/concepts_public_attestation.md b/tutorials/src/concepts_public_attestation.md index e5abff76e..23d7cfe02 100644 --- a/tutorials/src/concepts_public_attestation.md +++ b/tutorials/src/concepts_public_attestation.md @@ -4,7 +4,7 @@ This feature should be considered _Alpha_. [RFC](https://github.com/docknetwork/planning/blob/master/rfc/0014-public-attestation.md) -VCDM Verifiable credentials are a way to prove an _attestation_. Valid credentials prove statements of the form `Issuer claims X`, where `X` is itself a statement. One property of verifiable credentials is that the holder may keep them private simply by not sharing them with other parties. That property will be sometimes useful, sometimes not. VCDM crededentials are private and therefore not automatically discoverable but Public Attestations give a decentralized identity the ability to post claims that _are_ discoverable by any party. For Dock DIDs, attestations are linked on-chain but Public Attestations are not specicfic to Dock. Other DID methods can implement public attestations by including them in DID documents. +VCDM Verifiable credentials are a way to prove an _attestation_. Valid credentials prove statements of the form `Issuer claims X`, where `X` is itself a statement. One property of verifiable credentials is that the holder may keep them private simply by not sharing them with other parties. That property will be sometimes useful, sometimes not. VCDM crededentials are private and therefore not automatically discoverable but Public Attestations give a decentralized identity the ability to post claims that _are_ discoverable by any party. For Dock DIDs, attestations are linked on-chain but Public Attestations are not specicfic to Dock Labs. Other DID methods can implement public attestations by including them in DID documents. Public Attestations are posted as RDF documents. Since RDF can represent, or link to, arbitrary types of data, Public Attestations can be used to publish arbitrary content. @@ -61,7 +61,7 @@ Fact 2: ### Example of A DID attesting to multiple documents -While it is valid DIDs to include multiple attested IRIs in a single DID document, Dock artificially limits the number of attestation to one per Dock DID. This is to encourage off-chain (ipfs) data storage. If a DID wishes to attests to multiple documents, there are two suggested options: 1) merge the two documents into a single document or 2) attest to a single document which in turn notes an `attestsDocumentContents` for each of it's children. The following is an example of option "2)". +While it is valid DIDs to include multiple attested IRIs in a single DID document, Dock Labs artificially limits the number of attestation to one per Dock DID. This is to encourage off-chain (ipfs) data storage. If a DID wishes to attests to multiple documents, there are two suggested options: 1) merge the two documents into a single document or 2) attest to a single document which in turn notes an `attestsDocumentContents` for each of it's children. The following is an example of option "2)". `did:ex:ex`: From 409768e215e67417e64b6a530756c725230c107e Mon Sep 17 00:00:00 2001 From: AgneCaunt <139773510+AgneCaunt@users.noreply.github.com> Date: Mon, 6 Jan 2025 17:19:29 +0200 Subject: [PATCH 5/9] Update concepts_vcdm.md --- tutorials/src/concepts_vcdm.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tutorials/src/concepts_vcdm.md b/tutorials/src/concepts_vcdm.md index cd5eddbc1..ed4a95481 100644 --- a/tutorials/src/concepts_vcdm.md +++ b/tutorials/src/concepts_vcdm.md @@ -42,7 +42,7 @@ machine-verifiable. ## Issuing To issue a verifiable credential, the issuer needs to have a public key that is accessible by the holder and verifier to verify the -signature (in `proof`) in the credential. Though the VCDM spec does not mandate it, an issuer in Dock must have a DID on chain. +signature (in `proof`) in the credential. Though the VCDM spec does not mandate it, an issuer using Truvera Credential SDK must have a DID on chain. This DID is present in the credential in the `issuer` field. An example credential where both the issuer and holder have Dock DIDs ```js @@ -123,10 +123,10 @@ on chain and learn the public key. An example presentation signed by the holder ## Revocation If the credential is revocable, the issuer must specify how the revocation check must be done in the `credentialStatus` field. -On Dock, credential revocation is managed with a revocation registry. There can be multiple registries on chain and each +With Truvera Credential SDK, credential revocation is managed with a revocation registry. There can be multiple registries on chain and each registry has a unique id. It is recommended that the revocation authority creates a new registry for each credential type. While issuing the credential, issuer embeds the revocation registry's id in the credential in the `credentialStatus` field. -An example credential with Dock revocation registry +An example credential with Truvera revocation registry ```js { @@ -159,6 +159,6 @@ An example credential with Dock revocation registry To revoke a credential, the revocation authority (might be same as the issuer), puts a hash of the credential id in the revocation registry. To check the revocation status of a credential, hash the credential id and query the registry id specified in the credential. The revocation of a credential can be undone if the revocation registry supports undoing. Moreover, currently, each registry is -owned by a single DID so that DID can revoke a credential or undo the revocation. In future, Dock will support ownership of +owned by a single DID so that DID can revoke a credential or undo the revocation. In future, Truvera will support ownership of the registry with mulitple DIDs and in different fashions, like any one of the owner DIDs could revoke or a threshold is needed, etc. To learn more about revocation registries, refer the [revocation section](./tutorial_revocation.md) of the documentation. From d94a2cda40c61154e331652e7c09d6c0585e9a53 Mon Sep 17 00:00:00 2001 From: AgneCaunt <139773510+AgneCaunt@users.noreply.github.com> Date: Mon, 6 Jan 2025 17:24:22 +0200 Subject: [PATCH 6/9] Update introduction.md --- tutorials/src/introduction.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tutorials/src/introduction.md b/tutorials/src/introduction.md index ffe7c085d..7dbb06abe 100644 --- a/tutorials/src/introduction.md +++ b/tutorials/src/introduction.md @@ -15,7 +15,7 @@ Overall, there're five packages located in the [GitHub repository](https://githu - [`@docknetwork/cheqd-blockchain-api`](https://github.com/docknetwork/sdk/tree/master/packages/cheqd-blockchain-api) - A Javascript library built atop of `@cheqd/sdk` that allows to interact with the `Cheqd` blockchain. - [`@docknetwork/cheqd-blockchain-modules`](https://github.com/docknetwork/sdk/tree/master/packages/cheqd-blockchain-modules) - A JavaScript library created for managing credential SDK components such as DIDs, accumulators etc on the Cheqd blockchain. -# Dock +# Truvera Credential SDK ## Installation @@ -43,10 +43,10 @@ bash scripts/run_dock_node_in_docker ## Importing -In this tutorial series, we will use Node.js with Babel for ES6 support. This code will also work in browsers once transpiled. To start, import the Dock SDK. You can import the `DockAPI` class and instantiate your object: +In this tutorial series, we will use Node.js with Babel for ES6 support. This code will also work in browsers once transpiled. To start, import the Truvera Credential SDK. You can import the `DockAPI` class and instantiate your object: ```javascript -// Import the Dock SDK +// Import the Truvera Credential SDK import { DockAPI } from "@docknetwork/dock-blockchain-api"; const dock = new DockAPI(); @@ -68,7 +68,7 @@ export const secretUri = "//Alice"; // Account secret in URI format, for local t ## Connecting to a Node -With the required packages and variables imported, we can connect to our node. If you don't have a local testnet running, go to [Docker Substrate](https://github.com/docknetwork/dock-substrate) for setup instructions. You could also use the Dock testnet if you have an account with sufficient funds. Begin by creating the following method: +With the required packages and variables imported, we can connect to our node. If you don't have a local testnet running, go to [Docker Substrate](https://github.com/docknetwork/dock-substrate) for setup instructions. You could also use the Truvera testnet if you have an account with sufficient funds. Begin by creating the following method: ```javascript export async function connectToNode() {} @@ -132,7 +132,7 @@ Send a transaction using `signAndSend`: const res = await dock.signAndSend(transaction); ``` -Instantiate Dock modules with `DockCoreModules`: +Instantiate Truvera modules with `DockCoreModules`: ```js import { DockCoreModules } from "@docknetwork/dock-blockchain-modules"; @@ -155,7 +155,7 @@ const accumulator = dockModules.accumulator; ## Installation -As with Dock, the process is simple. Use NPM to install: +As with Truvera, the process is simple. Use NPM to install: ```bash npm install @docknetwork/credential-sdk @docknetwork/cheqd-blockchain-modules @docknetwork/cheqd-blockchain-api From 7497701982630329b703fc4079f76b72f699af50 Mon Sep 17 00:00:00 2001 From: AgneCaunt <139773510+AgneCaunt@users.noreply.github.com> Date: Mon, 6 Jan 2025 17:27:20 +0200 Subject: [PATCH 7/9] Update tutorial_did.md --- tutorials/src/tutorial_did.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tutorials/src/tutorial_did.md b/tutorials/src/tutorial_did.md index b572a33c6..5cf2c0ded 100644 --- a/tutorials/src/tutorial_did.md +++ b/tutorials/src/tutorial_did.md @@ -4,7 +4,7 @@ If you are not familiar with DIDs, you can get a conceptual overview [here](./co ## Overview -DIDs in Dock are created by choosing a 32 byte unique (on Dock chain) identifier along with 1 ore more public keys or controllers. +DIDs in Truvera are created by choosing a 32 byte unique (on Dock chain) identifier along with 1 ore more public keys or controllers. The public key can be added or removed by the DID's controller (which the DID maybe itself) signature with a key having `capabilityInvocation` verification relationship. From 9e82282a35efd771a6b761dcecd0d28b79bde5f2 Mon Sep 17 00:00:00 2001 From: AgneCaunt <139773510+AgneCaunt@users.noreply.github.com> Date: Mon, 6 Jan 2025 17:30:34 +0200 Subject: [PATCH 8/9] Update tutorial_resolver.md --- tutorials/src/tutorial_resolver.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tutorials/src/tutorial_resolver.md b/tutorials/src/tutorial_resolver.md index b27383c1b..e499702bd 100644 --- a/tutorials/src/tutorial_resolver.md +++ b/tutorials/src/tutorial_resolver.md @@ -16,11 +16,11 @@ There is another class called `ResolverRouter` that can accept several types of of `DIDResolver`) and once the `ResolverRouter` is initialized with the resolvers of different DID methods, it can resolve DIDs of those methods. -## Dock resolver +## DID Dock resolver The resolver for Dock DIDs `CoreResolver` connects to the Dock blockchain to get the DID details. -The resolver is constructed by passing it a Dock API object so that it can connect to a Dock node. +The resolver is constructed by passing it a Truvera API object so that it can connect to a Dock node. This is how you resolve a Dock DID: ```js @@ -34,7 +34,7 @@ const didDocument = await dockResolver.resolve("did:dock:5D....."); ## Creating a resolver class for a different method -If you want to resolve DIDs other than Dock and do not have/want access to the universal resolver, you can extend the +If you want to resolve DIDs other than did:dock and do not have/want access to the universal resolver, you can extend the `DIDResolver` class to derive a custom resolver. Following is an example to build a custom Ethereum resolver. It uses the library From b5903e4998f6e1fca0696494280c5bf77d01a7fd Mon Sep 17 00:00:00 2001 From: AgneCaunt <139773510+AgneCaunt@users.noreply.github.com> Date: Tue, 7 Jan 2025 13:52:46 +0200 Subject: [PATCH 9/9] Update tutorial_revocation.md --- tutorials/src/tutorial_revocation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tutorials/src/tutorial_revocation.md b/tutorials/src/tutorial_revocation.md index 5732b9367..68a632980 100644 --- a/tutorials/src/tutorial_revocation.md +++ b/tutorials/src/tutorial_revocation.md @@ -4,8 +4,8 @@ This guide provides instructions for managing credential revocation using `Statu ## Prerequisites -- Ensure you have access to Dock's Credential SDK and Blockchain API. -- The Dock API is initialized and connected to the blockchain. +- Ensure you have access to Truvera's Credential SDK and Blockchain API. +- The Truvera API is initialized and connected to the blockchain. - You have a valid issuer DID registered on the Dock network. ## Steps to Manage Revocation