diff --git a/docs/common-issues/astron-address-whitelist-error.md b/docs/common-issues/astron-address-whitelist-error.md
index b6622ad..9dd8dc1 100644
--- a/docs/common-issues/astron-address-whitelist-error.md
+++ b/docs/common-issues/astron-address-whitelist-error.md
@@ -13,4 +13,4 @@ Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":56,\"error\"
To resolve this issue, ensure that your wallet address is whitelisted before attempting to transact on the Astron L2 network.
-More information regarding the whitelist will be provided. For any inquiries or additional information, feel free to contact us at tradetrust@imda.gov.sg.
+More information regarding the whitelist will be provided. For any inquiries or additional information, feel free to contact us via the [Official Page](https://trustvc.io/contact) or drop us an email at [tvc-support@dextech.ai](mailto:tvc-support@dextech.ai).
diff --git a/docs/common-issues/cors-error.md b/docs/common-issues/cors-error.md
index 5e3dc80..4303d03 100644
--- a/docs/common-issues/cors-error.md
+++ b/docs/common-issues/cors-error.md
@@ -5,10 +5,10 @@ sidebar_label: CORS Errors on External Resources
keywords: ["cors", "cors error", "Access-Control-Allow-Origin", "cross-origin", "no-cors", "fetch blocked"]
---
-When using the web-based verifier such as [ref.tradetrust.io](https://ref.tradetrust.io), the browser will block requests to external resources that do not have Cross-Origin Resource Sharing (CORS) enabled.
+When using the web-based verifier such as [trustvc.io](https://trustvc.io), the browser will block requests to external resources that do not have Cross-Origin Resource Sharing (CORS) enabled.
:::info
-This is not a bug in TradeTrust. It is a security feature of the browser that enforces access controls on the resources you host.
+This is not a bug in TrustVC. It is a security feature of the browser that enforces access controls on the resources you host.
:::
## The Error
@@ -16,16 +16,16 @@ This is not a bug in TradeTrust. It is a security feature of the browser that en
You will see this in your browser console (F12):
```text
-Access to fetch at 'https://your-domain.com/context.json' from origin 'https://ref.tradetrust.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
+Access to fetch at 'https://your-domain.com/context.json' from origin 'https://trustvc.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
```
## The Cause
-The TradeTrust verifier runs entirely in the client's browser. When it tries to read a JSON-LD context or a revocation list from your server (`your-domain.com`), the browser checks your server's headers.
+The TrustVC verifier runs entirely in the client's browser. When it tries to read a JSON-LD context or a revocation list from your server (`your-domain.com`), the browser checks your server's headers.
-If your server does not return the header `Access-Control-Allow-Origin: *` (or explicitly allow `https://ref.tradetrust.io`), the browser acts as a gatekeeper and blocks the data from reaching the verifier.
+If your server does not return the header `Access-Control-Allow-Origin: *` (or explicitly allow `https://trustvc.io`), the browser acts as a gatekeeper and blocks the data from reaching the verifier.
-## Common Triggers in TradeTrust
+## Common Triggers in TrustVC
These are the resources you host that frequently cause this error.
diff --git a/docs/community/contributing.md b/docs/community/contributing.md
index 8411a10..4ec7baf 100644
--- a/docs/community/contributing.md
+++ b/docs/community/contributing.md
@@ -4,9 +4,9 @@ title: Contributing
sidebar_label: Contributing
---
-# TradeTrust Community
+# TrustVC Community
-Welcome to the **TradeTrust Community**! This page provides an overview of **TrustVC** and how you can contribute.
+Welcome to the **TrustVC Community**! This page provides an overview of **TrustVC** and how you can contribute.
## Overview
diff --git a/docs/glossary/glossary.md b/docs/glossary/glossary.md
index da31300..5b28fef 100644
--- a/docs/glossary/glossary.md
+++ b/docs/glossary/glossary.md
@@ -27,8 +27,8 @@ A new type of identifier designed to enable verifiable, self-sovereign digital i
[Learn more](https://www.w3.org/TR/did-core/)
### Document Store
-A smart contract on the Ethereum network that records the issuance, revocation, and transfer status of TradeTrust Verifiable Documents. It enables the management of document validity and ownership transfers.
-[Learn more](https://github.com/TradeTrust/document-store)
+A smart contract on the Ethereum network that records the issuance, revocation, and transfer status of TrustVC Verifiable Documents. It enables the management of document validity and ownership transfers.
+[Learn more](https://github.com/TrustVC/document-store)
### Ether
The native cryptocurrency of the Ethereum blockchain, used to power transactions and interact with smart contracts.
diff --git a/docs/how-tos/advanced/address-resolver.md b/docs/how-tos/advanced/address-resolver.md
index 8a02cc5..86e97b7 100644
--- a/docs/how-tos/advanced/address-resolver.md
+++ b/docs/how-tos/advanced/address-resolver.md
@@ -6,22 +6,22 @@ sidebar_label: Address Resolver
Different companies may choose to use different pseudo-identity, some of these identifiers are reused and some are not. For those companies who chose to reuse a pseudo-identity, there is almost always a need to point to them again when doing transactions because it acts as an identifier to the user / company when doing transactions with them. Examples of such resources could be a shipping line wallet, multi-sig wallet or eBL token registry. Read more about identifier resolution framework here.
-## TradeTrust's address resolution
+## TrustVC's address resolution
-For TradeTrust, currently there are 2 ways of resolving identities, 1 is through a local address book, the other is via 3rd party resolver API. These are accessible from the gear icon on the far right of the top navigation bar on TradeTrust website.
+For TrustVC, currently there are 2 ways of resolving identities, 1 is through a local address book, the other is via 3rd party resolver API. These are accessible from the gear icon on the far right of the top navigation bar on the TrustVC website.
-
+
-> You can refer to this [example](https://github.com/TradeTrust/address-identity-resolver) on how addresses get resolved on application end.
+> For implementation reference, see the [TrustVC package](https://github.com/TrustVC/trustvc). The `@trustvc/trustvc` package is used for document verification and does not expose dedicated address-resolver APIs, so address resolution is configured and handled at the application settings layer.
## Address Book (Local)
-Address Book is like a local phone book. The data is in a csv/excel format, where the minimal amount of columns are:
+Address Book is like a local phone book. The data is in a csv/excel format, where the minimal required columns are:
-- `identifier` (refers to the ethereum address)
-- `name` (refers to the resolved name that the company defined in their csv/excel sheet).
+- `Name` (refers to the resolved company or entity name)
+- `Address` (refers to the Wallet address)
-
+
After importing the csv/excel sheet, previously ethereum addresses (where resolvable) should now be resolved to recognizable identities as defined within the imported sheet.
@@ -29,41 +29,49 @@ After importing the csv/excel sheet, previously ethereum addresses (where resolv
So to recap the steps on setting your own local addressbook:
-1. First, prepare a csv excel sheet list of addresses and identifiers. For example:
- 
+1. First, prepare a csv/excel sheet with `Name` and `Address` columns. For example:
+ 
2. Develop an import csv file feature in your application. You'll need to:
- Convert file to string. For example:
- ```js
- const readAsText = async (file: File): Promise => {
- return new Promise((resolve, reject) => {
- const reader = new FileReader();
- if (reader.error) {
- reject(reader.error);
- }
- reader.onload = () => resolve(reader.result as string);
- reader.readAsText(file);
- });
- };
- ```
+
+ ```ts
+ const readAsText = async (file: File): Promise => {
+ return new Promise((resolve, reject) => {
+ const reader = new FileReader();
+ reader.onerror = () => reject(reader.error);
+ reader.onload = () => resolve(reader.result as string);
+ reader.readAsText(file);
+ });
+ };
+ ```
- Then convert string to key value object. For example:
- ```js
- import { parse } from "papaparse";
- const csvToAddressBook = (csv: string) => {
- const { data } = parse(csv, { skipEmptyLines: true, header: true });
- const addressBook = {};
- data.forEach((row, index) => {
- const identifierText = row.Identifier || row.identifier;
- const addressText = row.Address || row.address;
- addressBook[addressText.toLowerCase()] = identifierText;
- });
- return addressBook;
- };
- csvToAddressBook(readAsText);
- ```
-3. Finally, if local address tally, return identifier name as per defined in csv file previously.
+
+ ```ts
+ import { parse } from "papaparse";
+
+ const csvToAddressBook = (csv: string) => {
+ const parsed = parse(csv, { skipEmptyLines: true, header: true });
+ const data = parsed.data;
+ const addressBook: Record = {};
+
+ data.forEach((row: any) => {
+ const nameText = row.Name || row.name;
+ const addressText = row.Address || row.address;
+ if (!addressText || !nameText) return;
+ addressBook[addressText.toLowerCase()] = nameText;
+ });
+
+ return addressBook;
+ };
+
+ const csv = await readAsText(file);
+ const addressBook = csvToAddressBook(csv);
+ ```
+3. Finally, if a local address matches, return the `Name` from your csv/excel file.
+
```js
const addressToMatch = "0xabc..."; // your local address
- for (const [key, value] of Object.entries(csvToAddressBook)) {
+ for (const [key, value] of Object.entries(addressBook)) {
if (addressToMatch === key) {
return value;
}
@@ -72,59 +80,74 @@ So to recap the steps on setting your own local addressbook:
## Address Resolver (Third party)
-For our reference implementation, we are using Google Sheets as our "database" for demonstrating the third party address resolution concept conveniently. Similar to local address book, think of it as a list of records that map ethereum addresses to a defined label name within the google sheet columns.
+Third-party resolver lets you fetch address book entries from an external endpoint instead of importing CSV manually. Think of it as a remote address book that returns name/address pairs in JSON.
-In the settings page you can add your third party address resolver. It enables you to add a third party's endpoint to resolve Ethereum addresses to their company's name. With Ethereum addresses being cryptic to end users, this Address Resolver will act as a digital address book, think of it as your mobile phone contact list, we only remember names, not numbers. The address book allows end users to see familiar identifiers such as `ABC Pte Ltd`. Once the Address Resolver endpoint has been added, when you verify a document with an identifiable Ethereum address, it will look like the following:
+In the settings page you can add your third-party resolver endpoint to resolve Ethereum addresses to a company's name. With Ethereum addresses being cryptic to end users, this Address Resolver acts like a digital contact list where users see familiar identifiers such as `ABC Pte Ltd`. Once the endpoint is added and saved, resolvable Ethereum addresses appear with their resolved name:
-
+
-You can see that the company's name, resolver details and source will also be displayed above the resolved Ethereum
+You can see that the company's name and resolver details will also be displayed above the resolved Ethereum
address.
-_Note: There is a difference between "Resolved by" and "Source" parameters. Resolved by refers to the naming of the 3rd
-party resolver that the user has set in the settings page. Source (an optional field) refers to information that is
-verified by another party. For example, in NDI Myinfo, they have verified information from different agencies._
-
-> You are not restricted to Google Sheets approach and is free to use any other backend solutions.
-
-### How to set up a 3rd party Address Resolver (Google Sheet approach)
-
-_Prerequisite: [Google sheets API](https://developers.google.com/sheets/api/reference/rest)._
-
-- Go to [Google Console](https://console.cloud.google.com/apis/library) and create a new project.
- 
-- Enable Google Sheets API. Once enabled, it should be added to the enabled API list.
- 
-- Create an API key.
- 
-- Create and populate a Google Sheet with columns of:
- - `identifier` (The ethereum address of the company)
- - `name` (The name of the company)
- - `source`. (_Optional:The source of the information_)
-- Set Google Sheet to public.
-- Setup the third party resolution service by configuring it to access Google Sheets with the API key gotten from step 1.
- - Fork this [reference implementation](https://github.com/TradeTrust/demo-identifier-resolver).
- - Define these environment variables in github repo secrets:
- - SHEETS_API_KEY = Your created API key from Google Console.
- - SHEETS_ID = Your google sheet ID.
- - SHEETS_RANGE = Your google sheet cell range.
- - STAGING_AWS_ACCESS_KEY_ID = Your AWS access key id.
- - STAGING_AWS_SECRET_ACCESS_KEY = Your AWS access key secret.
- - Spin up this service up by pushing to master, github actions will automate the deployment.
- - Go to API Gateway in your AWS account. Create a custom domain name of your preference. Take note of API Gateway domain name.
- 
- - Click API mappings and configure it by selecting `stg-demo-identifier-resolver` from dropdown list.
- - Go to Route53 and create a new CNAME record. The value is your API Gateway domain name.
- 
- - Once set, wait for a few minutes and your API endpoint will be accessible in the custom domain name that you've created. This will be what we call the third party resolution service endpoint.
-- Go to the website application, clicking the "+ Add" button in the settings page will show you following:
-
-
-
-- Fill in the following:
- - `name` (A label you want to name this endpoint, this will be reflected as the "Resolved by")
- - `endpoint` (The third party resolution service endpoint that you've spinned up)
- - `API Header and API Key` (The authentication handling on service that you've spinned up)
+### How to set up a 3rd party Address Resolver
+
+#### 1) Create an endpoint that returns JSON
+
+Your endpoint must return an array of objects with:
+
+- `name`: display label (for example, company name)
+- `address`: Ethereum wallet address
+
+Supported response shapes:
+
+```json
+[
+ { "name": "Alice Pte Ltd", "address": "0x1111111111111111111111111111111111111111" },
+ { "name": "Bob Shipping", "address": "0x2222222222222222222222222222222222222222" }
+]
+```
+
+or nested under one of these keys:
+
+```json
+{
+ "entries": [
+ { "name": "Alice Pte Ltd", "address": "0x1111111111111111111111111111111111111111" }
+ ]
+}
+```
+
+```json
+{
+ "results": [
+ { "name": "Alice Pte Ltd", "address": "0x1111111111111111111111111111111111111111" }
+ ]
+}
+```
+
+#### 2) Host the endpoint
+
+You can host it using either:
+
+- **Simple**: static JSON file on a public URL (for example GitHub Pages, S3, or any static host)
+- **Advanced**: API endpoint (for example Node/Express, Python/Flask, serverless functions)
+
+For production, secure your resolver endpoint.
+
+- If your endpoint is protected, configure an API header and API key in resolver settings (for example `x-api-key` + your token).
+
+#### 3) Configure resolver in Settings
+
+- Go to the website application. Click the `+ Add` button in the Settings page:
+
+ 
+
+- Fill in:
+ - `name` (label for this resolver; shown as "Resolved by")
+ - `endpoint` (the URL returning JSON entries)
+ - `API Header` and `API Key` (optional; use for protected endpoints, for example `X-API-Key` + `secret123`)
+
+ 
---
@@ -136,12 +159,13 @@ The "Name" input refers to the name of the address resolver that contains all th
#### Endpoint
-The "Endpoint" input refers to the endpoint that will be called to resolve an Ethereum Address.
-A demo hosted endpoint is available at [https://demo-resolver.tradetrust.io/](https://demo-resolver.tradetrust.io/).
+The "Endpoint" input is the URL that will be called to resolve an Ethereum address.
+Use the URL of your own deployed resolver service.
+Example: `https://resolver.your-domain.com/api/resolve`.
-
+
-_Note: This demo endpoint is not suitable for production environment, please use it only in testing or staging environment._
+_Note: For production environments, host and secure your own resolver endpoint._
---
diff --git a/docs/how-tos/advanced/wallet-management.md b/docs/how-tos/advanced/wallet-management.md
index 5989a1c..76d02b5 100644
--- a/docs/how-tos/advanced/wallet-management.md
+++ b/docs/how-tos/advanced/wallet-management.md
@@ -4,4 +4,4 @@ title: Wallet Management
sidebar_label: Wallet Management
---
-For any signed transactions, a wallet private key is always needed. As of today, Tradetrust uses metamask browser extension as its wallet management solution. This [ADR](https://github.com/Open-Attestation/adr/blob/master/wallet_management.md#survey-of-key-management-solutions) provides a good background context on various key management solutions.
+For any signed transactions, a wallet private key is always needed. As of today, TrustVC uses metamask browser extension as its wallet management solution. This [ADR](https://github.com/Open-Attestation/adr/blob/master/wallet_management.md#survey-of-key-management-solutions) provides a good background context on various key management solutions.
diff --git a/docs/how-tos/bitstring.md b/docs/how-tos/bitstring.md
index 980cf03..c7fa768 100644
--- a/docs/how-tos/bitstring.md
+++ b/docs/how-tos/bitstring.md
@@ -201,14 +201,14 @@ For the examples above, the Credential Status List is hosted at:
https://example.com/credentials/status/3
:::warning CORS Configuration Required for Interoperability
-Your hosted Status List **must** have CORS enabled. This requires configuring the status list endpoint to return the `Access-Control-Allow-Origin: *` header. Without this configuration, external verifiers (like [ref.tradetrust.io](https://ref.tradetrust.io)) will be blocked by the browser's CORS policy and **cannot check if credentials are revoked or suspended**.
+Your hosted Status List **must** have CORS enabled. This requires configuring the status list endpoint to return the `Access-Control-Allow-Origin: *` header. Without this configuration, external verifiers (like [trustvc.io](https://trustvc.io)) will be blocked by the browser's CORS policy and **cannot check if credentials are revoked or suspended**.
**Why this matters:**
-- This only affects **web-based verifiers** running in browsers (like [ref.tradetrust.io](https://ref.tradetrust.io))
+- This only affects **web-based verifiers** running in browsers (like [trustvc.io](https://trustvc.io))
- Server-side or native app verifiers are not affected by CORS
- Testing locally or within your own domain won't reveal this issue
- The error only appears when external web verifiers try to fetch your status list
-- This is a browser security feature, not a bug in TradeTrust
+- This is a browser security feature, not a bug in TrustVC
- Verification will fail or show warnings if the status cannot be checked
For detailed instructions on configuring CORS for your status list endpoint, see the [CORS Errors guide](/docs/common-issues/cors-error).
diff --git a/docs/how-tos/contexts.md b/docs/how-tos/contexts.md
index dd823d4..cde7aff 100644
--- a/docs/how-tos/contexts.md
+++ b/docs/how-tos/contexts.md
@@ -155,14 +155,14 @@ The Bitstring Status List provides a mechanism to represent and manage the revoc
This section explains the usage of custom contexts that we have created, including transferableRecords, renderMethod, and attachments, in the TrustVC framework. These contexts enhance the functionality and flexibility of Verifiable Credentials, enabling tailored solutions for diverse applications.
:::warning CORS Configuration Required for Interoperability
-If you host custom `@context` URLs on your own infrastructure, you **must** configure these specific resources to allow cross-origin requests. This requires setting the `Access-Control-Allow-Origin: *` header on these context files. Without this configuration, external verifiers (like [ref.tradetrust.io](https://ref.tradetrust.io)) will be blocked by the browser's CORS policy and **verification will fail**.
+If you host custom `@context` URLs on your own infrastructure, you **must** configure these specific resources to allow cross-origin requests. This requires setting the `Access-Control-Allow-Origin: *` header on these context files. Without this configuration, external verifiers (like [trustvc.io](https://trustvc.io)) will be blocked by the browser's CORS policy and **verification will fail**.
**Why this matters:**
-- This only affects **web-based verifiers** running in browsers (like [ref.tradetrust.io](https://ref.tradetrust.io))
+- This only affects **web-based verifiers** running in browsers (like [trustvc.io](https://trustvc.io))
- Server-side or native app verifiers are not affected by CORS
- Testing locally or within your own domain won't reveal this issue
- The error only appears when external web verifiers try to read your context files
-- This is a browser security feature, not a bug in TradeTrust
+- This is a browser security feature, not a bug in TrustVC
For detailed instructions on fixing CORS errors, see the [CORS Errors guide](/docs/common-issues/cors-error).
:::
diff --git a/docs/how-tos/decentralized-renderer/decentralized-renderer-guide.md b/docs/how-tos/decentralized-renderer/decentralized-renderer-guide.md
index 4c052fc..ca6222f 100644
--- a/docs/how-tos/decentralized-renderer/decentralized-renderer-guide.md
+++ b/docs/how-tos/decentralized-renderer/decentralized-renderer-guide.md
@@ -6,11 +6,11 @@ sidebar_label: Decentralized Renderer Guide
# Decentralized Renderer Guide
-This comprehensive guide covers best practices and troubleshooting for TradeTrust decentralized renderers, helping you build robust, maintainable, and user-friendly document templates.
+This comprehensive guide covers best practices and troubleshooting for TrustVC decentralized renderers, helping you build robust, maintainable, and user-friendly document templates.
## Introduction
-Decentralized renderers are essential components in the TradeTrust ecosystem that provide document preview templates. They allow issuers to define how their documents are displayed while keeping the rendering logic separate from the verification process.
+Decentralized renderers are essential components in the TrustVC ecosystem that provide document preview templates. They allow issuers to define how their documents are displayed while keeping the rendering logic separate from the verification process.
### Key Concepts
@@ -119,7 +119,7 @@ sequenceDiagram
**Remember that your renderer might be used by external systems you don't control.**
-Your decentralized renderer will be embedded in various applications, including the TradeTrust document viewer, third-party applications, and other verification portals.
+Your decentralized renderer will be embedded in various applications, including the TrustVC document viewer, third-party applications, and other verification portals.
:::important Important Guidelines
@@ -132,7 +132,7 @@ Your decentralized renderer will be embedded in various applications, including
**Templates must remain available indefinitely.**
-Since TradeTrust documents may not expire and could be verified years after issuance:
+Since TrustVC documents may not expire and could be verified years after issuance:
:::note
@@ -146,7 +146,7 @@ Since TradeTrust documents may not expire and could be verified years after issu
### CORS Configuration
-Decentralized renderers must support Cross-Origin Resource Sharing (CORS) to function properly with TradeTrust applications.
+Decentralized renderers must support Cross-Origin Resource Sharing (CORS) to function properly with TrustVC applications.
**Best Practice**:
@@ -205,10 +205,10 @@ The `useFallbackRenderer` prop ensures that if the third-party renderer fails to
#### 2. Surrounding your template with ErrorBoundary:
-TradeTrust provides a `Wrapper` component in the core library that includes an `ErrorBoundary` for catching and displaying template errors. It's recommended to use this component in your templates:
+TrustVC provides a `Wrapper` component in the core library that includes an `ErrorBoundary` for catching and displaying template errors. It's recommended to use this component in your templates:
```tsx
-// From TradeTrust generic-templates/src/core/Wrapper/Wrapper.tsx
+// From TrustVC generic-templates/src/core/Wrapper/Wrapper.tsx
import React, { FunctionComponent } from "react";
import { ErrorBoundary } from "../ErrorBoundary";
@@ -651,4 +651,4 @@ export const registry = {
## Conclusion
-Building effective decentralized renderers requires attention to both technical implementation details and user experience considerations. By following these best practices and troubleshooting techniques, you can create robust, maintainable, and user-friendly document templates for the TradeTrust ecosystem.
+Building effective decentralized renderers requires attention to both technical implementation details and user experience considerations. By following these best practices and troubleshooting techniques, you can create robust, maintainable, and user-friendly document templates for the TrustVC ecosystem.
diff --git a/docs/how-tos/decentralized-renderer/template-advanced-features.md b/docs/how-tos/decentralized-renderer/template-advanced-features.md
index 0e32c1e..e28ba44 100644
--- a/docs/how-tos/decentralized-renderer/template-advanced-features.md
+++ b/docs/how-tos/decentralized-renderer/template-advanced-features.md
@@ -6,17 +6,17 @@ sidebar_label: Template Advanced Features
# Template Advanced Features
-This guide explores advanced features for document preview templates in TradeTrust. These features enhance the functionality and user experience of your templates beyond basic rendering.
+This guide explores advanced features for document preview templates in TrustVC. These features enhance the functionality and user experience of your templates beyond basic rendering.
## Introduction
Once you've created your basic document templates, you can enhance them with advanced features like multiple views, print-friendly formatting, and more. This guide demonstrates how to implement these features in your templates.
-Before proceeding with these examples, make sure you're familiar with the basics of [decentralized renderer](/docs/how-tos/decentralized-renderer/decentralized-renderer-guide.md) and understand the [generic templates](/docs/how-tos/decentralized-renderer/using-generic-templates) available in TradeTrust.
+Before proceeding with these examples, make sure you're familiar with the basics of [decentralized renderer](/docs/how-tos/decentralized-renderer/decentralized-renderer-guide.md) and understand the [generic templates](/docs/how-tos/decentralized-renderer/using-generic-templates) available in TrustVC.
## Advanced Features
-In many cases, you'll want to provide multiple views or formats for the same document. TradeTrust's decentralized renderer framework makes this easy to implement. Let's explore how to create multiple views for a document and add advanced features.
+In many cases, you'll want to provide multiple views or formats for the same document. TrustVC's decentralized renderer framework makes this easy to implement. Let's explore how to create multiple views for a document and add advanced features.
### Implementing Multiple Views
@@ -512,8 +512,8 @@ export const MultiLanguageTemplate = ({ document }) => {
## Conclusion
-Implementing advanced features in your TradeTrust document templates can significantly enhance the user experience and functionality of your documents. By leveraging multiple views, print-friendly formatting, conditional rendering, interactive elements, data visualization, QR codes, and internationalization, you can create rich, interactive document experiences that meet diverse user needs.
+Implementing advanced features in your TrustVC document templates can significantly enhance the user experience and functionality of your documents. By leveraging multiple views, print-friendly formatting, conditional rendering, interactive elements, data visualization, QR codes, and internationalization, you can create rich, interactive document experiences that meet diverse user needs.
Remember that these advanced features should complement the core purpose of your document templates: to present document data clearly and accurately. Always prioritize readability and usability when implementing these features.
-For more information on TradeTrust's decentralized renderer framework, refer to the [decentralized renderer guide](/docs/how-tos/decentralized-renderer/decentralized-renderer-guide.md) and explore the [generic templates](/docs/how-tos/decentralized-renderer/using-generic-templates) available in TradeTrust.
+For more information on TrustVC's decentralized renderer framework, refer to the [decentralized renderer guide](/docs/how-tos/decentralized-renderer/decentralized-renderer-guide.md) and explore the [generic templates](/docs/how-tos/decentralized-renderer/using-generic-templates) available in TrustVC.
diff --git a/docs/how-tos/decentralized-renderer/using-generic-templates.md b/docs/how-tos/decentralized-renderer/using-generic-templates.md
index 6840422..42b4bca 100644
--- a/docs/how-tos/decentralized-renderer/using-generic-templates.md
+++ b/docs/how-tos/decentralized-renderer/using-generic-templates.md
@@ -6,11 +6,11 @@ sidebar_label: Using Generic Templates
# Using Generic Templates for Document Preview
-TradeTrust provides a set of pre-designed generic templates for common document types. These templates offer a quick and convenient way to render TradeTrust documents without having to create custom renderers from scratch. This guide will walk you through the process of using these generic templates for your documents.
+TrustVC provides a set of pre-designed generic templates for common document types. These templates offer a quick and convenient way to render TrustVC documents without having to create custom renderers from scratch. This guide will walk you through the process of using these generic templates for your documents.
## Overview of Available Templates
-TradeTrust currently offers the following generic templates:
+TrustVC currently offers the following generic templates:
| Template Name | Description |
| --- | --- |
@@ -20,13 +20,13 @@ TradeTrust currently offers the following generic templates:
| **Invoice** | A commercial document issued by a seller to a buyer, detailing the products or services provided, their quantities and agreed prices, and the total amount due. |
| **Warehouse Receipt** | A document issued by a warehouse operator acknowledging the receipt of goods for storage. |
-These templates are hosted at `https://generic-templates.tradetrust.io` and can be previewed in the [TradeTrust Gallery](https://gallery.tradetrust.io/), other legacy templates can be previewed in the [Generic Templates Storybook](https://storybook.generic-templates.tradetrust.io/).
+These templates are hosted at `https://generic-templates.tradetrust.io` and can be previewed in the [TrustVC Gallery](https://gallery.tradetrust.io/), other legacy templates can be previewed in the [Generic Templates Storybook](https://storybook.generic-templates.tradetrust.io/).
## When to Use Generic Templates
Generic templates are ideal for:
-- **Demonstration purposes** - When you want to quickly demonstrate TradeTrust functionality
+- **Demonstration purposes** - When you want to quickly demonstrate TrustVC functionality
- **Prototyping** - When you're in the early stages of development and need a working renderer
- **Testing** - When you want to test document issuance and verification without creating a custom renderer
- **Simple use cases** - When your document structure aligns well with one of the available templates
@@ -124,9 +124,9 @@ Each template requires specific data fields. Below are examples for common templ
### 4. Create and Issue Your Document
-You can create and issue sample document using the [TradeTrust Creator (V5 - Mainnet)](https://v5-token-registry.tradetrust.io/creator) / [TradeTrust Creator (V5 - Testnet)](https://v5-token-registry.dev.tradetrust.io/creator).
+You can create and issue sample document using the [TrustVC Creator (V5 - Mainnet)](https://v5-token-registry.tradetrust.io/creator) / [TrustVC Creator (V5 - Testnet)](https://v5-token-registry.dev.tradetrust.io/creator).
-Alternatively, you can setup your own creator by following the [TradeTrust Creator Tutorial](/docs/tutorial/creator.md).
+Alternatively, you can setup your own creator by following the [TrustVC Creator Tutorial](/docs/tutorial/creator.md).
## Limitations of Generic Templates
@@ -141,6 +141,6 @@ For these reasons, generic templates are recommended primarily for demonstration
## Conclusion
-Generic templates provide a quick and convenient way to render TradeTrust documents without having to create custom renderers. They are ideal for demonstration, testing, and prototyping purposes, but for production use, consider creating a custom decentralized renderer for greater flexibility and branding control.
+Generic templates provide a quick and convenient way to render TrustVC documents without having to create custom renderers. They are ideal for demonstration, testing, and prototyping purposes, but for production use, consider creating a custom decentralized renderer for greater flexibility and branding control.
-By following the steps in this guide, you can effectively use TradeTrust's generic templates to render your documents in a visually appealing way.
+By following the steps in this guide, you can effectively use TrustVC's generic templates to render your documents in a visually appealing way.
diff --git a/docs/how-tos/implementing-qr-codes.md b/docs/how-tos/implementing-qr-codes.md
index a40a9ac..79136c2 100644
--- a/docs/how-tos/implementing-qr-codes.md
+++ b/docs/how-tos/implementing-qr-codes.md
@@ -10,7 +10,7 @@ This documentation explains how to implement QR codes in W3C Verifiable Credenti
## QR Code URL Structure and Payload Schema
-QR codes in TradeTrust documents follow a standard URL structure with an encoded JSON payload using the query parameter `q`:
+QR codes in TrustVC documents follow a standard URL structure with an encoded JSON payload using the query parameter `q`:
```
https://actions.tradetrust.io?q=
@@ -128,7 +128,7 @@ const qrCodeUrl = `https://actions.tradetrust.io?q=${encodeURIComponent(JSON.str
### Document Encryption
-Since documents referenced by QR codes need to be publicly accessible, it's recommended to encrypt them. The TradeTrust system supports the [oa-encryption](https://github.com/Open-Attestation/oa-encryption) library for this purpose:
+Since documents referenced by QR codes need to be publicly accessible, it's recommended to encrypt them. The TrustVC system supports the [oa-encryption](https://github.com/Open-Attestation/oa-encryption) library for this purpose:
1. Encrypt the document:
@@ -158,7 +158,7 @@ const payload = {
### Cross-Origin Resource Sharing (CORS)
-If you're hosting documents on a custom backend, ensure you've configured CORS to allow requests from TradeTrust domains:
+If you're hosting documents on a custom backend, ensure you've configured CORS to allow requests from TrustVC domains:
```
Access-Control-Allow-Origin: *.tradetrust.io
@@ -166,9 +166,9 @@ Access-Control-Allow-Origin: *.tradetrust.io
## Custom URL Redirection
-Instead of directly using the `ref.tradetrust.io` URL, you can implement a custom reverse proxy to handle QR code redirection:
+Instead of directly using the `trustvc.io` URL, you can implement a custom reverse proxy to handle QR code redirection:
-1. Deploy your own redirect service based on [TradeTrust Actions](https://github.com/TradeTrust/actions).
+1. Deploy your own redirect service based on [TrustVC Actions](https://github.com/TrustVC/actions).
2. Configure the service to whitelist allowed redirect domains.
@@ -178,18 +178,18 @@ Instead of directly using the `ref.tradetrust.io` URL, you can implement a custo
https://actions.yourdomain.com?q=
```
-## How TradeTrust Renders QR Codes
+## How TrustVC Renders QR Codes
-When a TradeTrust-compatible document with a QR code is loaded, the TradeTrust website:
+When a TrustVC-compatible document with a QR code is loaded, the TrustVC website:
-1. When the QR code is scanned, the encoded URL is opened, which redirects to TradeTrust with the document URI.
+1. When the QR code is scanned, the encoded URL is opened, which redirects to TrustVC with the document URI.
2. Extracts the QR code URL using the `getQRCodeLink` function, which checks for:
- `qrCode.uri` in W3C VC documents
- `credentialSubject.links.self.href` in OA v3 documents
- `links.self.href` in OA v2 documents
-3. TradeTrust then downloads the document from the specified URI, decrypting it if necessary.
+3. TrustVC then downloads the document from the specified URI, decrypting it if necessary.
4. Renders the URL as a scannable QR code.
@@ -200,30 +200,30 @@ To test if your QR code implementation is working correctly:
1. Create a document with a QR code.
2. Host the document at a publicly accessible URL.
-3. Upload your document to [https://dev.tradetrust.io/](https://dev.tradetrust.io/) / [https://ref.tradetrust.io/](https://ref.tradetrust.io/).
+3. Upload your document to [https://dev.tradetrust.io/](https://dev.tradetrust.io/) / [https://trustvc.io/](https://trustvc.io/).
4. Verify that the QR code icon appears in the document utility bar.
5. Click the QR code icon and scan it with a mobile device.
-6. Confirm that scanning the QR code successfully redirects to TradeTrust and loads the document.
+6. Confirm that scanning the QR code successfully redirects to TrustVC and loads the document.
By following these guidelines, you can successfully implement QR codes in your W3C VC and OpenAttestation documents, making them more accessible and easier to verify.
-## Implementation Example: Using TradeTrust Functions and Actions
+## Implementation Example: Using TrustVC Functions and Actions
-This section provides a complete example of implementing QR codes using TradeTrust's reference implementations.
+This section provides a complete example of implementing QR codes using TrustVC's reference implementations.
-### TradeTrust Functions
+### TrustVC Functions
_Prerequisite: [Netlify functions](https://docs.netlify.com/functions/overview/)._
-TradeTrust functions is built with Netlify functions. TradeTrust provides a set of API endpoints for demonstration purposes only. Essentially you should have an endpoint service yourself to store your documents so to facilitate rendering of QR code in your web application later on.
+TrustVC functions is built with Netlify functions. TrustVC provides a set of API endpoints for demonstration purposes only. Essentially you should have an endpoint service yourself to store your documents so to facilitate rendering of QR code in your web application later on.
-### Setting up TradeTrust Functions
+### Setting up TrustVC Functions
Let's go through the steps:
1. Sign up an account with [Netlify](https://app.netlify.com/signup).
2. If you need document storage service, sign up an account with [AWS](https://aws.amazon.com/). Otherwise, this step **can be skipped**. Create an s3 bucket on AWS. Create access key ID and secret access key to access this resource. Take note of the bucket name, ID and secrets, we'll need them later.
-3. Fork tradetrust-functions [repo](https://github.com/TradeTrust/tradetrust-functions) on your github. Make sure to spin up a netlify site connected to the forked github repo.
+3. Fork tradetrust-functions [repo](https://github.com/TrustVC/trustvc-functions) on your github. Make sure to spin up a netlify site connected to the forked github repo.
4. You should have a random site name allocated to your netlify site. You can edit site name to whichever name you want. For our example, we have renamed it to `tradetrust-functions.netlify.app`.
5. Populate your environment variables on netlify site settings.
@@ -237,7 +237,7 @@ Let's go through the steps:
### Document Storage
-For our reference implementation of [document storage service](https://github.com/TradeTrust/tradetrust-functions#document-storage), it does the following:
+For our reference implementation of [document storage service](https://github.com/TrustVC/trustvc-functions#document-storage), it does the following:
- [Encrypts](https://github.com/Open-Attestation/oa-encryption#encrypting-a-document) a document, returning the `key` among other fields.
- Only neccessary fields are uploaded and stored in Amazon s3 bucket, without `key`.
@@ -255,7 +255,7 @@ For our reference implementation of [document storage service](https://github.co
}
```
-- `key` 1a8d6... will be then be used to decrypt the document at `uri` with 95524... on TradeTrust web application end.
+- `key` 1a8d6... will be then be used to decrypt the document at `uri` with 95524... on TrustVC web application end.
> Note that the `key` value is up to integrators on how it should be managed. Do note that the process of whether to encrypt your document is at your discretion.
diff --git a/docs/how-tos/issuer/did-web.md b/docs/how-tos/issuer/did-web.md
index fde3513..cb54b43 100644
--- a/docs/how-tos/issuer/did-web.md
+++ b/docs/how-tos/issuer/did-web.md
@@ -11,7 +11,7 @@ import TabItem from "@theme/TabItem";
`did:web` is a Decentralized Identifier (DID) method that utilizes existing web infrastructure. This method enables organizations to represent their identifiers through their web domains without requiring a blockchain. The `did:web` method follows the [`did:web` specification](https://w3c-ccg.github.io/did-method-web/) and leverages standard HTTPS and DNS infrastructure for DID resolution.
-When working with TradeTrust documents, the `did:web` method's public key is used to validate the authenticity of any TradeTrust W3C signed document. This verification step is essential as it confirms the document's integrity by checking the digital signatures using the issuer's public key from their DID document. Since TradeTrust relies on these DID documents for verification, maintaining high availability of your `did:web` endpoint is critical - any downtime could prevent others from verifying your documents.
+When working with TrustVC documents, the `did:web` method's public key is used to validate the authenticity of any TrustVC W3C signed document. This verification step is essential as it confirms the document's integrity by checking the digital signatures using the issuer's public key from their DID document. Since TrustVC relies on these DID documents for verification, maintaining high availability of your `did:web` endpoint is critical - any downtime could prevent others from verifying your documents.
## How `did:web` Works
diff --git a/docs/how-tos/issuer/dns-did.md b/docs/how-tos/issuer/dns-did.md
index 5e4b323..1f4c6a0 100644
--- a/docs/how-tos/issuer/dns-did.md
+++ b/docs/how-tos/issuer/dns-did.md
@@ -16,7 +16,7 @@ This segment is retained for legacy support for Open Attestation Document. For m
> smart contract deployment is the deployment of either document store smart contract or token registry smart contracts.
-Alternatively to DNS-TXT method, as an issuer one can use `DNS-DID` issuer method to verify that they indeed sign over the TradeTrust document.
+Alternatively to DNS-TXT method, as an issuer one can use `DNS-DID` issuer method to verify that they indeed sign over the TrustVC document.
:::note
@@ -38,7 +38,7 @@ Decentralized identifiers (DIDs) are a new type of identifier that enables verif
## How it works
-When an individual entity creates an etheruem wallet, it is nothing more than a private / public key pair. The public key can be derived from a wallet address and hence the ethereum wallet address becomes the basis for the DID verification. When we use our private key to sign over `merkleRoot` of our TradeTrust document, `proof.signature` is appended. This is the signature that will be verified against with later in [tt-verify](https://github.com/TradeTrust/tt-verify) library. What happens at this end is the DID document will be resolved and retrieved, verify if the signed message hash equates back to etheruem wallet address, ensuring the document was indeed signed by it's private key. This way we know that it is "issued".
+When an individual entity creates an ethereum wallet, it is nothing more than a private / public key pair. The public key can be derived from a wallet address and hence the ethereum wallet address becomes the basis for the DID verification. When we use our private key to sign over `merkleRoot` of our TrustVC document, `proof.signature` is appended. This is the signature that will be verified against with later in [tt-verify](https://github.com/TrustVC/tt-verify) library. What happens at this end is the DID document will be resolved and retrieved, verify if the signed message hash equates back to ethereum wallet address, ensuring the document was indeed signed by it's private key. This way we know that it is "issued".
Let's look at the `did:ethr` method:
diff --git a/docs/how-tos/issuer/dns-txt.md b/docs/how-tos/issuer/dns-txt.md
index 8b391ec..255403a 100644
--- a/docs/how-tos/issuer/dns-txt.md
+++ b/docs/how-tos/issuer/dns-txt.md
@@ -16,11 +16,11 @@ This segment is retained for legacy support for Open Attestation Document. For m
> smart contract deployment is the deployment of either document store smart contract or token registry smart contracts.
-In the current implementation of TradeTrust, we are using the Domain Name System (DNS) as the method of issuer identity verification.
+In the current implementation of TrustVC, we are using the Domain Name System (DNS) as the method of issuer identity verification.
A one-liner introduction to the DNS system can be summarised as: "Phonebook for the Internet". Its primary purpose is to resolve human readable names such as "google.com", or "tradetrust.io", etc. to a set of records.
The most common records are 'A records', which resolve to IP addresses - this allows network routing to operate over the Internet.
-For TradeTrust, we are using the `TXT` type of record, which simply allows us to store textual data. The textual data we store indicates the deployed Document Store / Token Registry address that the domain administrator trusts.
+For TrustVC, we are using the `TXT` type of record, which simply allows us to store textual data. The textual data we store indicates the deployed Document Store / Token Registry address that the domain administrator trusts.
By allowing the DNS system to be used as an identity registry, we let domain name owners claim ownership of a Document Store / Token Registry smart contract on the Ethereum / Polygon Blockchain.
@@ -92,7 +92,7 @@ An example of a valid `TXT` record for Ethereum `mainnet` network is as shown:
| ---- | --------------------- | ------------------------------------------------------------------------------- |
| TXT | sandbox.tradetrust.io | "openatts net=ethereum netId=1 addr=0x9db35C07350e9a16C828dAda37fd9c2923c75812" |
-The `netId` corresponds to the [chain ID for the different Ethereum networks](https://chainid.network/). Here is a list of TradeTrust supported networks:
+The `netId` corresponds to the [chain ID for the different Ethereum networks](https://chainid.network/). Here is a list of TrustVC supported networks:
| Chain ID | netID | Name | Network Name |
| ---------- | ---------- | ------------------------ | -------------------- |
diff --git a/docs/how-tos/open-attestation/transferable-records/dns.mdx b/docs/how-tos/open-attestation/transferable-records/dns.mdx
index 6c701f0..decec7b 100644
--- a/docs/how-tos/open-attestation/transferable-records/dns.mdx
+++ b/docs/how-tos/open-attestation/transferable-records/dns.mdx
@@ -9,7 +9,7 @@ import Flow from "./flow.mdx";
-Every TradeTrust document's provenance can be verified and traced back to its issuer. This is achieved by embedding an `identityProof`
+Every TrustVC document's provenance can be verified and traced back to its issuer. This is achieved by embedding an `identityProof`
property in the document, which serves as a claim for identity. During the verification phase, the claim is checked against
external records.
@@ -17,7 +17,7 @@ external records.
In this example above, the document's issuer is bound to `example.tradetrust.io`.
-In this guide, we will bind the document issuer's identity to a valid domain name. This domain will be displayed as issuer every time the document is rendered in any TradeTrust-compliant decentralized renderer.
+In this guide, we will bind the document issuer's identity to a valid domain name. This domain will be displayed as issuer every time the document is rendered in any TrustVC-compliant decentralized renderer.
We will be inserting a temporary DNS record on our DNS at `sandbox.openattestation.com` so you do not need your own domain to follow the guide. If you prefer to use your own domain name for the identity, you may skip the steps involving the CLI and instead read the [DNS Configuration Guide](/docs/how-tos/issuer/dns-txt#hands-on-creating-a-dns-txt-record).
diff --git a/docs/how-tos/open-attestation/transferable-records/overview.mdx b/docs/how-tos/open-attestation/transferable-records/overview.mdx
index f1b6b93..bb72771 100644
--- a/docs/how-tos/open-attestation/transferable-records/overview.mdx
+++ b/docs/how-tos/open-attestation/transferable-records/overview.mdx
@@ -8,7 +8,7 @@ import Flow from "./flow.mdx";
-Transferable Records are documents which extends on Verifiable Documents, to allow a document to have an owner and a holder, is the second core pillar of TradeTrust framework. These records references properties laid out in the [UNCITRAL Model Law on Electronic Transferable Records](https://uncitral.un.org/sites/uncitral.un.org/files/media-documents/uncitral/en/mletr_ebook_e.pdf)
+Transferable Records are documents which extends on Verifiable Documents, to allow a document to have an owner and a holder, is the second core pillar of TrustVC framework. These records references properties laid out in the [UNCITRAL Model Law on Electronic Transferable Records](https://uncitral.un.org/sites/uncitral.un.org/files/media-documents/uncitral/en/mletr_ebook_e.pdf)
This allow Transferable Records to be used for documents like:
@@ -17,7 +17,7 @@ This allow Transferable Records to be used for documents like:
## Goal
-By the end of this tutorial you would be able to create your very own Transferable Records that will be valid on any TradeTrust viewer.
+By the end of this tutorial you would be able to create your very own Transferable Records that will be valid on any TrustVC viewer.
With these knowledge you will be able to create transferable records according to your own business needs by:
@@ -33,7 +33,7 @@ With these knowledge you will be able to create transferable records according t
The token registry smart contract is deployed by individual transferable records issuers such as the land title registry (for title deed) or shipping lines (for bill of lading). This smart contract replaces the document store smart contract in the previous section. similarly to document store contract, it also has it's identity bound to the issuer using DNS.
-The token registry stores the ownership state of the transferable records using a mapping from `document ID` to `owner`. The document ID is the target hash (and merkle root) of the individual TradeTrust document created. The owner will be either an externally owned account (EOA) or smart contract address.
+The token registry stores the ownership state of the transferable records using a mapping from `document ID` to `owner`. The document ID is the target hash (and merkle root) of the individual TrustVC document created. The owner will be either an externally owned account (EOA) or smart contract address.
In the overview above, we can see 3 different states of documents:
diff --git a/docs/how-tos/open-attestation/transferable-records/raw-document.mdx b/docs/how-tos/open-attestation/transferable-records/raw-document.mdx
index 3309d48..5c19e18 100644
--- a/docs/how-tos/open-attestation/transferable-records/raw-document.mdx
+++ b/docs/how-tos/open-attestation/transferable-records/raw-document.mdx
@@ -9,13 +9,13 @@ import Flow from "./flow.mdx";
-Every TradeTrust document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) is stored onto the document store as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issued onto the blockchain.
+Every TrustVC document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) is stored onto the document store as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issued onto the blockchain.
In this guide, we will learn how to create one raw document that conforms to the OpenAttestation v2 Schema.
-## Understanding TradeTrust Document Schema
+## Understanding TrustVC Document Schema
-Because TradeTrust is build using Open Attestation, we will be using OpenAttestation v2.0 schema. It defines the shape of data for the `raw document` - the data before the wrapping process. It is defined in [JSON Schema](https://json-schema.org/) format.
+Because TrustVC is build using Open Attestation, we will be using OpenAttestation v2.0 schema. It defines the shape of data for the `raw document` - the data before the wrapping process. It is defined in [JSON Schema](https://json-schema.org/) format.
The official OpenAttestation v2.0 schema can be found at https://schema.openattestation.com/2.0/schema.json
diff --git a/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdx b/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdx
index d9a5fee..e985f1c 100644
--- a/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdx
+++ b/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli.mdx
@@ -12,7 +12,7 @@ import Flow from "../flow.mdx";
> For the current step, you can either opt to use the [CLI](/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli) or [Code](/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-code).
-Every TradeTrust document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be issued into the token registry as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issue.
+Every TrustVC document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be issued into the token registry as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issue.
> Please note that for Transferable Records, there is **NO** batch wrapping.
@@ -20,7 +20,7 @@ In this guide, we will learn how to generate the checksum by running the `wrappi
We will use the CLI tool to read all the files in the `raw-documents` folder, wrap them and then output the files in another directory `wrapped-documents`.
-A `merkleRoot`, a 64 character long string prepended with `0x` will be generated. The `merkleRoot` is the only information that will be stored onto the Blockchain to verify the issuance status of a TradeTrust document.
+A `merkleRoot`, a 64 character long string prepended with `0x` will be generated. The `merkleRoot` is the only information that will be stored onto the Blockchain to verify the issuance status of a TrustVC document.
From the folder containing the `raw-documents` folder, run:
diff --git a/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-code.mdx b/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-code.mdx
index 0088955..ff0564f 100644
--- a/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-code.mdx
+++ b/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-code.mdx
@@ -12,7 +12,7 @@ import Flow from "../flow.mdx";
> For the current step, you can either opt to use the [CLI](/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-cli) or [Code](/docs/how-tos/open-attestation/transferable-records/wrapping-document/wrapping-document-code).
-Every TradeTrust document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be issued into the token registry as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issue.
+Every TrustVC document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be issued into the token registry as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issue.
> Please note that for Transferable Records, there is **NO** batch wrapping.
@@ -20,7 +20,7 @@ In this guide, we will learn how to generate the checksum by running the `wrappi
We will use the CLI tool to read all the files in the `raw-documents` folder, wrap them and then output the files in another directory `wrapped-documents`.
-A `merkleRoot`, a 64 character long string prepended with `0x` will be generated. The `merkleRoot` is the only information that will be stored onto the Blockchain to verify the issuance status of a TradeTrust document.
+A `merkleRoot`, a 64 character long string prepended with `0x` will be generated. The `merkleRoot` is the only information that will be stored onto the Blockchain to verify the issuance status of a TrustVC document.
## Installation
diff --git a/docs/how-tos/open-attestation/verifiable-documents/dns-did/create.mdx b/docs/how-tos/open-attestation/verifiable-documents/dns-did/create.mdx
index 67bd714..6079219 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/dns-did/create.mdx
+++ b/docs/how-tos/open-attestation/verifiable-documents/dns-did/create.mdx
@@ -7,7 +7,7 @@ import Flow from "./flow.mdx";
-While there exists many [DIDs](/docs/glossary#did-decentralized-identifiers), this tutorial will focus only on `ethr` DID. At the moment, TradeTrust only supports `ethr` DID.
+While there exists many [DIDs](/docs/glossary#did-decentralized-identifiers), this tutorial will focus only on `ethr` DID. At the moment, TrustVC only supports `ethr` DID.
The creation of an `ethr` DID is identical to the creation of a wallet, as it relies entirely on the ethereum architecture. Once the wallet will be created, we will need to retrieve its private key:
diff --git a/docs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdx b/docs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdx
index 6f6a064..c1ca703 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdx
+++ b/docs/how-tos/open-attestation/verifiable-documents/dns-did/dns.mdx
@@ -8,7 +8,7 @@ import Flow from "./flow.mdx";
-Every TradeTrust document's provenance can be verified and traced back to its creator or issuer. This is achieved by embedding an
+Every TrustVC document's provenance can be verified and traced back to its creator or issuer. This is achieved by embedding an
`identityProof` property in the document, which serves as a claim for identity. During the verification phase, the claim is checked against external records.
diff --git a/docs/how-tos/open-attestation/verifiable-documents/dns-did/overview.mdx b/docs/how-tos/open-attestation/verifiable-documents/dns-did/overview.mdx
index a6dd8b4..ff1e699 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/dns-did/overview.mdx
+++ b/docs/how-tos/open-attestation/verifiable-documents/dns-did/overview.mdx
@@ -8,12 +8,12 @@ import Flow from "./flow.mdx";
-Building upon OpenAttestation framework, our Verifiable Document form one of two core pillars for TradeTrust framework.
+Building upon OpenAttestation framework, our Verifiable Document form one of two core pillars for TrustVC framework.
In this tutorial guide, you will be deploying your first verifiable document.
## Goal
-By the end of this guide, you would be able to create your π Certificate of Completion that is valid on any compatible TradeTrust Verifier. The following guides are available:
+By the end of this guide, you would be able to create your π Certificate of Completion that is valid on any compatible TrustVC Verifier. The following guides are available:
-- Issue a TradeTrust Verifiable document using [DNS-DID](/docs/how-tos/issuer/dns-did) method.
+- Issue a TrustVC Verifiable document using [DNS-DID](/docs/how-tos/issuer/dns-did) method.
diff --git a/docs/how-tos/open-attestation/verifiable-documents/dns-did/raw-document.mdx b/docs/how-tos/open-attestation/verifiable-documents/dns-did/raw-document.mdx
index 47a63d4..08451fc 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/dns-did/raw-document.mdx
+++ b/docs/how-tos/open-attestation/verifiable-documents/dns-did/raw-document.mdx
@@ -9,13 +9,13 @@ import Flow from "./flow.mdx";
-Every TradeTrust document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) is stored onto the document store as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issued onto the blockchain.
+Every TrustVC document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) is stored onto the document store as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issued onto the blockchain.
In this guide, we will learn how to create one raw document that conforms to the OpenAttestation v2 Schema.
-## Understanding TradeTrust Document Schema
+## Understanding TrustVC Document Schema
-Because TradeTrust is build using Open Attestation, we will be using OpenAttestation v2.0 schema. It defines the shape of data for the `raw document` - the data before the wrapping process. It is defined in [JSON Schema](https://json-schema.org/) format.
+Because TrustVC is build using Open Attestation, we will be using OpenAttestation v2.0 schema. It defines the shape of data for the `raw document` - the data before the wrapping process. It is defined in [JSON Schema](https://json-schema.org/) format.
The official OpenAttestation v2.0 schema can be found at https://schema.openattestation.com/2.0/schema.json
diff --git a/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli.mdx b/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli.mdx
index 67b2fd9..99cbced 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli.mdx
+++ b/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli.mdx
@@ -12,7 +12,7 @@ import Flow from "../flow.mdx";
> For the current step, you can either opt to use the [CLI](/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli) or [Code](/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-code).
-Every TradeTrust document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be signed as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be signed.
+Every TrustVC document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be signed as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be signed.
Multiple documents can be wrapped at the same time in a single batch operation, creating a single checksum for the entire batch of raw documents. This is especially useful when using document store on the Ethereum blockchain to lower the transaction cost and time.
diff --git a/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-code.mdx b/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-code.mdx
index e0aa911..47ed59a 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-code.mdx
+++ b/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-code.mdx
@@ -12,7 +12,7 @@ import Flow from "../flow.mdx";
> For the current step, you can either opt to use the [CLI](/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-cli) or [Code](/docs/how-tos/open-attestation/verifiable-documents/dns-did/wrapping-document/wrapping-document-code).
-Every TradeTrust document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be signed as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be signed.
+Every TrustVC document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be signed as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be signed.
Multiple documents can be wrapped at the same time in a single batch operation, creating a single checksum for the entire batch of raw documents. This is especially useful when using document store on the Ethereum blockchain to lower the transaction cost and time.
diff --git a/docs/how-tos/open-attestation/verifiable-documents/dns-txt/configuring-dns.mdx b/docs/how-tos/open-attestation/verifiable-documents/dns-txt/configuring-dns.mdx
index 3207304..bc8bec6 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/dns-txt/configuring-dns.mdx
+++ b/docs/how-tos/open-attestation/verifiable-documents/dns-txt/configuring-dns.mdx
@@ -9,13 +9,13 @@ import Flow from "./flow.mdx";
-Every TradeTrust document's provenance can be verified and traced back to its issuer. This is achieved by embedding an `identityProof` property in the document, which serves as a claim for identity. During the verification phase, the claim is checked against external records.
+Every TrustVC document's provenance can be verified and traced back to its issuer. This is achieved by embedding an `identityProof` property in the document, which serves as a claim for identity. During the verification phase, the claim is checked against external records.
In this example above, the document's issuer is bound to `example.tradetrust.io`.
-In this guide, we will bind the document issuer's identity to a valid domain name. This domain will be displayed as issuer every time the document is rendered in any TradeTrust-compliant decentralized renderer.
+In this guide, we will bind the document issuer's identity to a valid domain name. This domain will be displayed as issuer every time the document is rendered in any TrustVC-compliant decentralized renderer.
We will be inserting a temporary DNS record on our DNS at `sandbox.openattestation.com` so you do not need your own domain to follow the guide. If you prefer to use your own domain name for the identity, you may skip the steps involving the CLI and instead read the [DNS Configuration Guide](/docs/how-tos/issuer/dns-txt#hands-on-creating-a-dns-txt-record).
diff --git a/docs/how-tos/open-attestation/verifiable-documents/dns-txt/overview.mdx b/docs/how-tos/open-attestation/verifiable-documents/dns-txt/overview.mdx
index bcb3adb..547d2ef 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/dns-txt/overview.mdx
+++ b/docs/how-tos/open-attestation/verifiable-documents/dns-txt/overview.mdx
@@ -9,15 +9,15 @@ import Flow from "./flow.mdx";
-Building upon OpenAttestation framework, our Verifiable Document form one of two core pillars for TradeTrust framework.
+Building upon OpenAttestation framework, our Verifiable Document form one of two core pillars for TrustVC framework.
In this tutorial guide, you will be deploying a verifiable document.
## Goal
-By the end of this guide, you would be able to create your π Certificate of Completion that is valid on any compatible TradeTrust Verifier. The following guides are available:
+By the end of this guide, you would be able to create your π Certificate of Completion that is valid on any compatible TrustVC Verifier. The following guides are available:
-- Issue a TradeTrust Verifiable document that interacts with Ethereum Smart Contract.
+- Issue a TrustVC Verifiable document that interacts with Ethereum Smart Contract.
Before we begin, lets take some time to understand the overall architecture of our verifiable documents.
@@ -27,17 +27,17 @@ Before we begin, lets take some time to understand the overall architecture of o
#### Document Store Smart Contract
-The document store is a smart contract deployed onto the blockchain. When a TradeTrust document is issued, a proof of the issuance is stored onto the blockchain through the smart contract.
+The document store is a smart contract deployed onto the blockchain. When a TrustVC document is issued, a proof of the issuance is stored onto the blockchain through the smart contract.
-The smart contract is used to provide a globally consistent record for anyone to query a given TradeTrust document's issuance status.
+The smart contract is used to provide a globally consistent record for anyone to query a given TrustVC document's issuance status.
#### DNS Records
-A domain is required to issue a TradeTrust document. A DNS record must be inserted to the DNS to assert the identity of the TradeTrust document issuer.
+A domain is required to issue a TrustVC document. A DNS record must be inserted to the DNS to assert the identity of the TrustVC document issuer.
#### Verifiable Document File
-A Verifiable Document File is also known as the TradeTrust document. Machine-readable data of the TradeTrust document is stored in a `.json` file. In addition to the data, these `.json` files also contain information such as:
+A Verifiable Document File is also known as the TrustVC document. Machine-readable data of the TrustVC document is stored in a `.json` file. In addition to the data, these `.json` files also contain information such as:
- claim of issuer's identity
- document rendering information
@@ -45,7 +45,7 @@ A Verifiable Document File is also known as the TradeTrust document. Machine-rea
#### Decentralized Renderer
-The decentralized renderer gives the TradeTrust document a human-readable look. It is essentially a website which will take a TradeTrust document data as input and display the document in a web view. This allows anyone to style their document without submitting code change to another party.
+The decentralized renderer gives the TrustVC document a human-readable look. It is essentially a website which will take a TrustVC document data as input and display the document in a web view. This allows anyone to style their document without submitting code change to another party.
This tutorial will now require you to choose between the following options:
diff --git a/docs/how-tos/open-attestation/verifiable-documents/dns-txt/raw-document.mdx b/docs/how-tos/open-attestation/verifiable-documents/dns-txt/raw-document.mdx
index 9131db8..2caeae0 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/dns-txt/raw-document.mdx
+++ b/docs/how-tos/open-attestation/verifiable-documents/dns-txt/raw-document.mdx
@@ -9,13 +9,13 @@ import Flow from "./flow.mdx";
-Every TradeTrust document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) is stored onto the document store as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issued onto the blockchain.
+Every TrustVC document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) is stored onto the document store as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issued onto the blockchain.
In this guide, we will learn how to create one raw document that conforms to the OpenAttestation v2 Schema.
-## Understanding TradeTrust Document Schema
+## Understanding TrustVC Document Schema
-Because TradeTrust is build using Open Attestation, we will be using OpenAttestation v2.0 schema. It defines the shape of data for the `raw document` - the data before the wrapping process. It is defined in [JSON Schema](https://json-schema.org/) format.
+Because TrustVC is build using Open Attestation, we will be using OpenAttestation v2.0 schema. It defines the shape of data for the `raw document` - the data before the wrapping process. It is defined in [JSON Schema](https://json-schema.org/) format.
The official OpenAttestation v2.0 schema can be found at https://schema.openattestation.com/2.0/schema.json
diff --git a/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-cli.mdx b/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-cli.mdx
index 3b76d18..a44671d 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-cli.mdx
+++ b/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-cli.mdx
@@ -12,7 +12,7 @@ import Flow from "../flow.mdx";
> For the current step, you can either opt to use the [CLI](/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-cli) or [Code](/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-code).
-Every TradeTrust document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be issued into the document store as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issue.
+Every TrustVC document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be issued into the document store as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issue.
Multiple documents can be wrapped at the same time in a single batch operation, creating a single checksum for the entire batch of raw documents. This is especially useful when using document store on the Ethereum blockchain to lower the transaction cost and time.
diff --git a/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-code.mdx b/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-code.mdx
index 62209f8..d963320 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-code.mdx
+++ b/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-code.mdx
@@ -12,7 +12,7 @@ import Flow from "../flow.mdx";
> For the current step, you can either opt to use the [CLI](/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-cli) or [Code](/docs/how-tos/open-attestation/verifiable-documents/dns-txt/wrapping-document/wrapping-document-code).
-Every TradeTrust document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be issued into the document store as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issue.
+Every TrustVC document has a checksum that provides it a tamper-proof property. At the same time, because the checksum can be used to uniquely identify a document, the checksum (or its derived value) will be issued into the document store as evidence of issuance. To compute the checksum, a `raw document` goes through a process known as `wrapping` to become a `wrapped document`. Only then, the document is ready to be issue.
Multiple documents can be wrapped at the same time in a single batch operation, creating a single checksum for the entire batch of raw documents. This is especially useful when using document store on the Ethereum blockchain to lower the transaction cost and time.
diff --git a/docs/how-tos/open-attestation/verifiable-documents/overview.md b/docs/how-tos/open-attestation/verifiable-documents/overview.md
index 8f38532..aaa02fe 100644
--- a/docs/how-tos/open-attestation/verifiable-documents/overview.md
+++ b/docs/how-tos/open-attestation/verifiable-documents/overview.md
@@ -6,9 +6,9 @@ sidebar_label: Overview
-There are 2 type of verifiable documents which uses different types of issuer method, a blockchain issuer method (DNS-TXT) and a DID issuer method (DNS-DID). For the blockchain issuer method (DNS-TXT), the fingerprint of the wrapped TradeTrust file is then committed to a [Document Store](https://github.com/Open-Attestation/document-store) smart contract on the Blockchain, which serves as an immutable ledger. For the DID issuer method (DNS-DID), the document is signed instead of being committed to the blockchain.
+There are 2 type of verifiable documents which uses different types of issuer method, a blockchain issuer method (DNS-TXT) and a DID issuer method (DNS-DID). For the blockchain issuer method (DNS-TXT), the fingerprint of the wrapped TrustVC file is then committed to a [Document Store](https://github.com/Open-Attestation/document-store) smart contract on the Blockchain, which serves as an immutable ledger. For the DID issuer method (DNS-DID), the document is signed instead of being committed to the blockchain.
-Both the signed and committed TradeTrust file can then be distributed to recipients, who will be able to verify the file on https://ref.tradetrust.io simply by dragging and dropping it into the Web interface.
+Both the signed and committed TrustVC file can then be distributed to recipients, who will be able to verify the file on https://trustvc.io simply by dragging and dropping it into the Web interface.
### Types of Verifiable Documents
diff --git a/docs/how-tos/transactions.md b/docs/how-tos/transactions.md
index 1ba459e..565a9c9 100644
--- a/docs/how-tos/transactions.md
+++ b/docs/how-tos/transactions.md
@@ -15,9 +15,9 @@ A Title that can have its' Owner changed after issuance, is known as a **Negotia
In the case where a **Negotiable Title** has its' Owner changed, this procedure is termed **Endorsement**. This change of ownership is only allowed by its' current Owner.
-### TradeTrust Contribution
+### TrustVC Contribution
-As previously documented under the Token Registry section, we can represent control of a TradeTrust document uniquely and singularly by registering its' hash with the Issuer's token registry. This hash is also known as a **Token ID**. This control will also be referred to as the **Token**.
+As previously documented under the Token Registry section, we can represent control of a TrustVC document uniquely and singularly by registering its' hash with the Issuer's token registry. This hash is also known as a **Token ID**. This control will also be referred to as the **Token**.
However, as the ERC721 standard only specifies a single mode of ownership, it cannot represent the duality of physical possession and legal ownership.
diff --git a/docs/migration-guide/decentralized-renderer-oa-w3c-migration.md b/docs/migration-guide/decentralized-renderer-oa-w3c-migration.md
new file mode 100644
index 0000000..f8750c9
--- /dev/null
+++ b/docs/migration-guide/decentralized-renderer-oa-w3c-migration.md
@@ -0,0 +1,99 @@
+---
+id: w3c-vc-support
+title: Decentralized Renderer - W3C VC Support
+sidebar_label: Decentralized Renderer Migration
+---
+
+This guide helps you migrate a **decentralized renderer** so it supports **W3C Verifiable Credentials (VC)** alongside existing **OpenAttestation (OA)** documents.
+
+## Why this matters
+
+- **Future-proof document support:** One codebase handles OA and W3C VC.
+- **Simpler component code:** Shared types and a single payload path reduce branching.
+- **Consistent validation:** Canonical detection and known `@context` URLs avoid drift.
+
+---
+
+## 1) Update dependencies
+
+### 1.1 Core packages
+
+Use **published** packages from npm (avoid `file:` or other local path dependencies).
+
+Install the latest renderer components and TrustVC core:
+
+```bash
+npm install @trustvc/decentralized-renderer-react-components@latest @trustvc/trustvc@latest
+```
+
+---
+
+## 2) Type migration (OA + W3C)
+
+### 2.1 Import canonical types from TrustVC
+
+Define a single union type for documents your templates accept:
+
+```typescript
+import {
+ OpenAttestationDocument,
+ SignedVerifiableCredential,
+} from "@trustvc/trustvc";
+
+export type SupportedDocument = OpenAttestationDocument | SignedVerifiableCredential;
+```
+
+### 2.2 Add a payload extraction helper
+
+Use **one helper** to read display data for both formats:
+
+- **OA:** payload lives at the **root** of the document.
+- **W3C VC:** payload lives under **`credentialSubject`** (which may be an object or an array per the data model).
+
+```typescript
+import {
+ vc,
+ SignedVerifiableCredential,
+ OpenAttestationDocument,
+} from "@trustvc/trustvc";
+
+type SupportedDocument = OpenAttestationDocument | SignedVerifiableCredential;
+type GenericPayload = Record;
+
+export function getPayload(doc: SupportedDocument): GenericPayload {
+ if (vc.isSignedDocument(doc)) {
+ // W3C VC β credentialSubject may be object or array
+ const subject = (doc as SignedVerifiableCredential).credentialSubject;
+ return Array.isArray(subject)
+ ? Object.assign({}, ...subject)
+ : (subject as GenericPayload);
+ }
+ // OA β use root document as payload
+ return doc as unknown as GenericPayload;
+}
+```
+
+## 3) W3C VC support (new documents)
+
+### 3.1 Replace custom W3C checks
+
+Use TrustVCβs canonical detection instead of ad hoc helpers:
+
+```typescript
+import { vc } from "@trustvc/trustvc";
+
+const isW3CVC = vc.isSignedDocument(document);
+```
+
+Remove legacy custom W3C utility modules after switching, so you do not maintain **two** detection paths.
+
+## 4) Verify both formats
+
+After migration:
+
+- Render at least **one OA** sample document end to end.
+- Render at least **one W3C VC** sample document end to end.
+
+## Result
+
+Your decentralized renderer can serve **OA and W3C VC** from one codebase, with backward compatibility for existing OA documents and a clear path for new W3C VC issuers.
diff --git a/docs/migration-guide/migration-tr-v5.md b/docs/migration-guide/migration-tr-v5.md
index 0da24c2..46e2294 100644
--- a/docs/migration-guide/migration-tr-v5.md
+++ b/docs/migration-guide/migration-tr-v5.md
@@ -10,7 +10,7 @@ This migration guide helps you transition from Token Registry v4 to **TrustVC**
**TrustVC Integration**
-- **TrustVC** is a comprehensive library that combines several TradeTrust libraries, including Token Registry v5, W3C Verifiable Credentials, and OpenAttestation Verifiable Documents. By using **TrustVC**, you can manage both credential documents and token-based credentials seamlessly in a unified solution.
+- **TrustVC** is a comprehensive library that combines several TrustVC libraries, including Token Registry v5, W3C Verifiable Credentials, and OpenAttestation Verifiable Documents. By using **TrustVC**, you can manage both credential documents and token-based credentials seamlessly in a unified solution.
**Token Registry v5**
diff --git a/docs/migration-guide/trustvc.md b/docs/migration-guide/trustvc.md
index c183af9..16cf9d2 100644
--- a/docs/migration-guide/trustvc.md
+++ b/docs/migration-guide/trustvc.md
@@ -6,7 +6,7 @@ sidebar_label: "Introduction: TrustVC"
[**TrustVC**](https://github.com/TrustVC/trustvc) is a comprehensive library designed to simplify the signing and verification processes for [TrustVC W3C Verifiable Credentials (VC)](https://github.com/TrustVC/w3c) and [OpenAttestation Verifiable Documents (VD)](https://github.com/Open-Attestation/open-attestation/). It adheres to the **W3C VC Data Model v2.0** ([W3C Standard](https://www.w3.org/TR/vc-data-model/)), ensuring compatibility and interoperability for Verifiable Credentials.
-With **TrustVC**, developers can seamlessly handle both W3C Verifiable Credentials and OpenAttestation Verifiable Documents through an integrated set of functionalities. The library not only simplifies signing and verification but also imports and integrates existing TradeTrust libraries and smart contracts for token registry (V4 and V5), making it a versatile tool for decentralized identity and trust solutions.
+With **TrustVC**, developers can seamlessly handle both W3C Verifiable Credentials and OpenAttestation Verifiable Documents through an integrated set of functionalities. The library not only simplifies signing and verification but also imports and integrates existing TrustVC libraries and smart contracts for token registry (V4 and V5), making it a versatile tool for decentralized identity and trust solutions.
## Key Features
@@ -131,9 +131,9 @@ const signedDocument = {
const resultFragments = await verifyDocument(signedDocument);
```
-### 3. Integration with Other TradeTrust Libraries
+### 3. Integration with Other TrustVC Libraries
-**TrustVC** is designed to work seamlessly with other TradeTrust libraries, extending their functionality and making it easier to integrate decentralized identity solutions. By leveraging existing TradeTrust tools, **TrustVC** enhances its capabilities for signing, verifying, and managing credentials and documents.
+**TrustVC** is designed to work seamlessly with other TrustVC libraries, extending their functionality and making it easier to integrate decentralized identity solutions. By leveraging existing TrustVC tools, **TrustVC** enhances its capabilities for signing, verifying, and managing credentials and documents.
- **@trustvc/w3c**:
diff --git a/docs/tutorial/decentralized-renderer.md b/docs/tutorial/decentralized-renderer.md
index cc34825..57f550e 100644
--- a/docs/tutorial/decentralized-renderer.md
+++ b/docs/tutorial/decentralized-renderer.md
@@ -8,7 +8,7 @@ This guide walks you through the process of creating a custom decentralized rend
## Source code and demo repository
-TrustVC provides a template repository to help you get started quickly: [TradeTrust/decentralized-renderer](https://github.com/TradeTrust/tradetrust-decentralized-renderer). You can use this as a starting point, fork it for your own renderer implementation.
+TrustVC provides a template repository to help you get started quickly: [TrustVC/decentralized-renderer](https://github.com/TrustVC/decentralized-renderer). You can use this as a starting point, fork it for your own renderer implementation.
## Prerequisites
@@ -28,7 +28,7 @@ Before starting, ensure you have the following installed:
Start by cloning the template repository and setting up your project:
```bash
-git clone https://github.com/TradeTrust/decentralized-renderer.git
+git clone https://github.com/TrustVC/decentralized-renderer.git
cd decentralized-renderer
rm -rf .git
git init
diff --git a/package-lock.json b/package-lock.json
index b633818..30ee337 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -1,12 +1,12 @@
{
"name": "trustvc-documentation",
- "version": "0.0.0",
+ "version": "0.0.1",
"lockfileVersion": 3,
"requires": true,
"packages": {
"": {
"name": "trustvc-documentation",
- "version": "0.0.0",
+ "version": "0.0.1",
"dependencies": {
"@docusaurus/core": "^3.1.1",
"@docusaurus/preset-classic": "^3.1.1",
diff --git a/package.json b/package.json
index d940257..ff2e026 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
{
"name": "trustvc-documentation",
- "version": "0.0.0",
+ "version": "0.0.1",
"private": true,
"scripts": {
"docusaurus": "docusaurus",
diff --git a/sidebars.json b/sidebars.json
index e3345cf..49574c5 100644
--- a/sidebars.json
+++ b/sidebars.json
@@ -198,7 +198,8 @@
"migration-guide/w3c-vc-v2",
"migration-guide/igp-i",
"migration-guide/migration-tr-v5",
- "migration-guide/migration-tt-cli-v5"
+ "migration-guide/migration-tt-cli-v5",
+ "migration-guide/w3c-vc-support"
],
"Community": ["community/contributing"],
"Common Issues & Solutions": [
diff --git a/static/docs/reference/tradetrust-website/address-resolved.png b/static/docs/reference/tradetrust-website/address-resolved.png
deleted file mode 100644
index e437add..0000000
Binary files a/static/docs/reference/tradetrust-website/address-resolved.png and /dev/null differ
diff --git a/static/docs/reference/tradetrust-website/local-csv.png b/static/docs/reference/tradetrust-website/local-csv.png
deleted file mode 100644
index 5009829..0000000
Binary files a/static/docs/reference/tradetrust-website/local-csv.png and /dev/null differ
diff --git a/static/docs/reference/tradetrust-website/qrcode.png b/static/docs/reference/tradetrust-website/qrcode.png
deleted file mode 100644
index 21818b0..0000000
Binary files a/static/docs/reference/tradetrust-website/qrcode.png and /dev/null differ
diff --git a/static/docs/reference/tradetrust-website/return-search.png b/static/docs/reference/tradetrust-website/return-search.png
deleted file mode 100644
index 25d2c69..0000000
Binary files a/static/docs/reference/tradetrust-website/return-search.png and /dev/null differ
diff --git a/static/docs/reference/trustvc-website/address-resolved.png b/static/docs/reference/trustvc-website/address-resolved.png
new file mode 100644
index 0000000..8e0cf9e
Binary files /dev/null and b/static/docs/reference/trustvc-website/address-resolved.png differ
diff --git a/static/docs/reference/trustvc-website/address-resolver-empty-form.png b/static/docs/reference/trustvc-website/address-resolver-empty-form.png
new file mode 100644
index 0000000..1f746e8
Binary files /dev/null and b/static/docs/reference/trustvc-website/address-resolver-empty-form.png differ
diff --git a/static/docs/reference/trustvc-website/address-resolver-filled-form.png b/static/docs/reference/trustvc-website/address-resolver-filled-form.png
new file mode 100644
index 0000000..5a967d6
Binary files /dev/null and b/static/docs/reference/trustvc-website/address-resolver-filled-form.png differ
diff --git a/static/docs/reference/tradetrust-website/api-gateway.png b/static/docs/reference/trustvc-website/api-gateway.png
similarity index 100%
rename from static/docs/reference/tradetrust-website/api-gateway.png
rename to static/docs/reference/trustvc-website/api-gateway.png
diff --git a/static/docs/reference/tradetrust-website/create-key.png b/static/docs/reference/trustvc-website/create-key.png
similarity index 100%
rename from static/docs/reference/tradetrust-website/create-key.png
rename to static/docs/reference/trustvc-website/create-key.png
diff --git a/static/docs/reference/tradetrust-website/create-project.png b/static/docs/reference/trustvc-website/create-project.png
similarity index 100%
rename from static/docs/reference/tradetrust-website/create-project.png
rename to static/docs/reference/trustvc-website/create-project.png
diff --git a/static/docs/reference/tradetrust-website/enable-api.png b/static/docs/reference/trustvc-website/enable-api.png
similarity index 100%
rename from static/docs/reference/tradetrust-website/enable-api.png
rename to static/docs/reference/trustvc-website/enable-api.png
diff --git a/static/docs/reference/trustvc-website/local-csv.png b/static/docs/reference/trustvc-website/local-csv.png
new file mode 100644
index 0000000..5af6b26
Binary files /dev/null and b/static/docs/reference/trustvc-website/local-csv.png differ
diff --git a/static/docs/reference/trustvc-website/return-search.png b/static/docs/reference/trustvc-website/return-search.png
new file mode 100644
index 0000000..c40610f
Binary files /dev/null and b/static/docs/reference/trustvc-website/return-search.png differ
diff --git a/static/docs/reference/tradetrust-website/route53.png b/static/docs/reference/trustvc-website/route53.png
similarity index 100%
rename from static/docs/reference/tradetrust-website/route53.png
rename to static/docs/reference/trustvc-website/route53.png
diff --git a/static/docs/reference/trustvc-website/settings-address-book.png b/static/docs/reference/trustvc-website/settings-address-book.png
new file mode 100644
index 0000000..dc7a07a
Binary files /dev/null and b/static/docs/reference/trustvc-website/settings-address-book.png differ
diff --git a/static/docs/reference/trustvc-website/settings-address-book1.png b/static/docs/reference/trustvc-website/settings-address-book1.png
new file mode 100644
index 0000000..98510d7
Binary files /dev/null and b/static/docs/reference/trustvc-website/settings-address-book1.png differ