---
# System prepended metadata

title: Protocol for Initializing Business Wallet

---

# Protocol for Initializing Business Wallet

This is a high level overview of how to get a Business trusted by a Source of Truth, so it can be issued a credential that other Businesses will trust.


## Short Term Goals

### Schemas

1. Business Registration credentials (BizNum) - issued to Businesses
2. Business Relationship credentials to an officer/director of a registered Business (BizRel) - issued to Individuals


### Actors

1. Corporate Registrar (REG): source of truth for Business numbers, knows who the directors of a company. Has ability to issue BizNum credentials to Business and BizRel credentials to an officer/director of a registered Business.
2. Business (ABC): a registered business, known to REG
3. Director for ABC (IND): a registered director or officer of REG, has a personal wallet on phone

### Concepts

1. Connections and Partners may have disconnected state. The connection at the aca-py level can be active, but the Partnership may be inactive or unknown. There will be business rules required to set a Partner to active.
2. Partners can be tagged or some how classified into logical groups (ie. Individual, Director, Trusted Issuer, etc)
3. All business rules and logic will vary from BPA to BPA.

### Flow

#### Director Issued Personal Credential from Corporate Registrar

* IND to REG: in person, presents personal id and Business Incorporation papers.  
* REG  inspects the personal id credential and the Business Incorporation papers, determines that IND is indeed a director for ABC and is who they say they are.  
* REG creates invitation to IND (generates a QR Code). 
* IND opens their wallet, scans the QR Code and accepts invitation.  
* REG makes the connection to IND active and tags Partnership as needed.  

REG and IND are now connected to each other; REG can issue credential.  

* REG issues BizRel credential to IND, indicating they are a director of ABC. Included in that credential is a hashcode or key (could be the credential id) that REG tracks that indicates the IND and BIZ.  
* IND reviews and accepts the credential.  
* IND has a VC in their wallet relating them to ABC from REG.  

#### Director sets up a Business Wallet  

* IND sets up a BPA for ABC, and registers it on the same ledger as REG.  
* IND creates a self attested Business Registration credentials (BizNum) with ABC Business Number.  

ABC wallet is empty.  

* ABC creates invitation to IND, generates a QR code.  
* IND opens their wallet, scans QR Code and accepts invitation.  
* ABC sets connection active, partner is in unknown state.  
* ABC requests proof of BizRel from IND (where business number = ABCs business number).  
* IND sees proof request from ABC in phone, selects their ABC Biz Rel credential and sends the Proof (which includes the hashcode/key/id that pairs the IND to ABC in REG).  
* ABC receives the proof and knows that IND is indeed a director/officer of ABC, sets the partner state to active and tags partner as Individual and Director.  
* ABC updates their self attested Business Registration credentials (BizNum). 

#### Business wants their Credential from Corporate Registrar
* ABC initiates connection with REG.  
* REG accepts invitation and activates connect, but partnership is inactive/unknown.  
* ABC sends a Presentation Proposal of their self-attested Business Number document (contains their Business Number and the hashcode/key from the IND BizRel proof) to REG.  
* REG inspects the proposal, matches the Business Number and IND hashcode, sets partnership active and tags them for grouping/sorting/id.  
* REG issues Business Registration credentials (BizNum).  
* ABC receives Business Registration credentials. 
* ABC can put partnership with REG into a good state and tag them.   

ABC has a credential in their wallet issued from Corporate Registrar.

## Long Term Vision
1. IND would come to REG with a personal id credential, REG would ask for proof of id after connection.
1. REG would have business logic that would automatically inspect the BizNum proposal and issue the credential if all is valid.
1. ABC would have business logic to ask for proofs after connection, connection from IND would have to present proof of BizRel, and would create the self attested BizNum document automatically. Next would be to send the proposal to REG to get their BizNum credential.

# Timeline Diagram

![](https://i.imgur.com/R74dFAt.png)


### Process

#### Assumption

Director/officer (IND) of a business got a BizReg Credential from the corporate registrar which includes at least
- The registration number of the business
- A secret the BPA has to provide when requesting the BizNum Credential

in her personal wallet.


```plantuml
@startuml
"IND"->"Agency": Request BPA instance
"Agency"->"IND": Presentation Request: BizRel Credential
"IND"->"Agency": Send BizRel Presentation with registration number x
"Agency"->"BPA": Provision BPA for business with reg number x. 
"Agency"->"IND": Provide link to BPA instance
"IND"->"BPA": Login 
"BPA"->"IND": Presentation Request: BizRel with reg number == x (incl. secret)
"IND"->"BPA": Send Presentation
"BPA"->"BPA": IND logged in with admin privileges
"BPA"->"BPA": Create BizNum Document with reg number and secret
"BPA"->"REG": Create Connection with REG and send BizNum verification request
"REG"->"REG": Match secret
"REG"->"BPA": Issue BizNum credential
@enduml
```
 