Merge pull request #499 from docknetwork/AgneCaunt-patch-2

Update concepts_claim_deduction.md

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](<https://en.wikipedia.org/wiki/Union_(set_theory)>) of those graphs, is also true `A∧B->A∪B` [^1]. Using this property we can combine multiple credentials and reason over their union.
 

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.

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.

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`:
 

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.

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

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.
 

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

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