# OrgBook Enhancements

### Existing Aries-VCR Architecture

## UNTP Goals
_The [UN Transparency Protocol](https://uncefact.github.io/spec-untp/) aims to support governments and industry with practical measures to counter greenwashing by implementing supply chain traceability and transparency at the scale needed to achieve meaningful impacts on global sustainability outcomes._

UNTP utilizes the defined standard for Verifiable Credentials (VCs) developed by the World-Wide-Web Consortium (W3C). A VC is a portable digital version of everyday credentials like education certificates, permits, licenses, registrations, and so on. A related W3C standard called Decentralized Identifiers (DIDs) provides a mechanism to manage the cryptographic keys used by verifiable credentials and also to link multiple credentials into verifiable trust graphs.

UNTP defines a **Digital Product Passport** which accompanies a good and makes claims about it's non-functional performance, like where it came from, it's carbon intesity, etc. Those claims can be supported by evidence in the form of **Conformity Credentials** which are signed by trusted authorities of that industry which could be public governments or private organizations.

### EMDT Goals

BCGov can be a leader in trusted DMTs

## OrgBook Enhancements
Orgbook is a public repository of verifiable credentials, centred around the [**Business Registration Credential**](https://test.orgbook.gov.bc.ca/search?credential_type_id=1&page=1) to be used as a root of trust, which is signed by BC Registries. Aries VCR enables other credentials to be issued against the subject of the root of trust credentials.

### 1. did:web for BC Government Issuers

#### 1.1 Data

BC Government issuers of digital credentials have DIDs (distributed identifiers), some exist on the CANdy ledger, but cannot be referenced by the did:web method required by W3C Verifiable Credentials, like the ones used in UNTP.

#### 1.2 Why Orgbook

Hosting these DIDs in a central location adds to their usability and continuity. Ihe identification of the BC Government issuer should exist on a platform designed for long term storage.

#### 1.3 Verification

a. Orgbook could rely on the existence of the did:indy:candy to trust it's origin as the BC Government along with checking the endorser itself

b. A more manual registration process from the public authority could establish the trust needed.

### 2. W3C Verifiable Credentials

#### 2.1 Data
W3C Verifiable Credentials, are documents signed by the issuers that are not bound to the holder and can discovered anywhere. The credentials will reference BC Businesses by their BC Registries identifier, similar to the AnonCreds Orgbook already accepts, but in this new credential type.

#### 2.2 Why Orgbook

W3C Verifiable Credentials that directly relate to BC Businesses all be housed in the same platform allows for improved validation of data. For example, Mines Act Permits are currently issued to Permittees by a name, which is not always the companies legal name, verifiable representations of the Mines Act Permits will need to reference the exact identifier used by BC Registries.

#### 2.3 Verification

Data will be crytographically signed by authority's private key. Orgbook can verify that credentials that reference BC Businesses actually exists. A credential that references a business id that does not exist should be rejected.

### 3. BC Business did:web

#### 3.1 Data

Orgbook can attest that "Company X" is a real company, but how does "Company X" with it's own digital wallet, prove that it's the same "Company X" that Orgbook attests too. This 'holder binding' is implicit in AnonCreds, but needs to be explicit with W3C Credentials.

#### 3.2 Why Orgbook
A credential from BC Registries into Orgbook that attests to the did:web of a company allows that company to 'access' the highly trusted data in Orgbook.

#### 3.3 Verification
There must be existing trusted processes to prove that an individual is the owner or operator of a company. The attestation of BC Registries that a BC Business Licence credential belongs to a given did:web is only as strong as the process for this link.

## Orgbook Enhanced
This shows how BC Government could publish BC Mines Act Permits to be used as conformity credentials when mining companies sell their raw materials on the global market.

### Architecture

cloud ledger as l{
    component "CANdy-ledger" as candy{
        interface "did:indy:candy" #lightgreen
        interface "AnonCred schema"
        interface "AnonCred cred_def"
    }
}

component Orgbook {
    port public
    portout vcr_endpoint
    
    component "VCR Wallet" as vw {
        interface "Mines Act Permit" as map #pink
        interface "Company did:web" as cdw #lightblue
        interface "BCGov Authority did:web" as bcdw #lightgreen
        
        
        cdw -- Registration
        Registration -up- "Business Number"
        Registration -- map
    }
    
    [API] -up- vw
    public - [API]
    [DB] -- [API]
    public - [Website]    
    [API] - [Website]
    vw -- vcr_endpoint
    vcr_endpoint -- candy
}

component "Mines Digital Services"{
    component [CPO-Wallet] as cpow
    component [Core-api] as capi
    component [Core-db] as cdb

    capi -- cdb
    capi -- cpow 
    portout cpo_endpoint
    
    cpow - cpo_endpoint
    cpo_endpoint - candy
    cpo_endpoint -- vcr_endpoint 
}

component company{
    [corp-wallet]
}

### Orgbook Supporting UNTP - Sequence Diagram

box "Chief Permitting Officer"
actor cpo
participant CORE
collections "cpo-traction" as cpow
end box


box orgbook
participant "orgbook-app" as obapp
collections "orgbook-agent" as obw
database "orgbook-db" as obdb
boundary "orgbook-api" as obapi
end box

box mining-company
actor company as co
collections "company-wallet" as cw
boundary "company-web" as cweb
boundary "logistics-erp" as logsys
end box

entity "Digital Product Passport" as dpp

cpow -> cw: existing AnonCred issue process is unchanged
cw -> cweb: publish company did:web
cw -> obapp: **register did:web with orgbook entity
cpow -> obapp: push cpo did:web
obapp -> obdb: store did:web did doc for availablily
CORE -> cpow: regular data processing
cpow -> obw : issue-credential-v2 json-ld UNTP-CC
obw <-> obapp: vaildate entity relationship
obapp -> obdb: store json-ld cred
logsys -> cw: Product claims used to produce dpp
cw -> dpp: signs and publishes
dpp <--> obapi: references MAP CC by url
dpp <--> obapi: CC references CPO did by did:web
dpp <--> cweb: reference company did:web