---
tags: Design
---

# Integrate Commercial Registry Entry in Public Profile

## Motivation

The Commercial Registry Entry serves the following functions:

- Should demonstrate an authoritative binding of a DID to an organization
- Should fix the gap, that currently ACA-PY does not allow connections based on public DIDs
- Should demonstrate the transfer of verified (or authoritative) master data

## Resolutions from Sprint Planning

In the last sprint planning, we defined the following approach:

- Commercial Registry Entry Credential can be made public
- We don't allow to add a Commercial Registry Entry *Document*
- Requesting Commerical Registry Entry Credentials happen outside the Business Partner, e.g. using [Open Corporates Proxy Issuer](https://oc-proxy.dev.economyofthings.io/#/requestIdentity)

## User Experience

Assuming Alice has a Commercial Registry Entry added to her public profile. We distinguish between two scenerios:

### 1. Alice adds Bob as a business partner

- In Bob's Business Partner Agent a new Business Partner with name Alice appears

Bob has no additional info Alice, because the connection is based on a new pairwise DID.

- Bob requests a Commercial Registry Entry from Alice
- Bob receives the presentation, gets the public DID from the presentation and requests the public profile.
- The Partner View now displays the public profile including the Commercial Registry entry and displays the Commercial Registry Entry in the Received Presentations

### 2. Bob adds Alice as a business partner

- The Partner View (Bob looking at partner Alice) displays the public profile including the Commercial Registry Entry as a self-signed verifiable presentation, but we have not yet received a _real_ verifiable presentation based on the original verifiable credential.
- We would need to request this preesentation manually.

## Wireframe


## Implementation Details / Backend Requirements

### Adding to public profile requires JSON-LD context
We could either define a custom mapping and context similar to the bank account or generate a canonical context which could be used for indy schemas in general. This is described [here](https://hackmd.io/cME-B1fMTUqkR5BDREaSOQ#Transformation-from-IndyDocumentsIndyVerifiedDocuments-to-JsonLdDocuments)

Specifying an explicit context would require an additional explicit type.

### Should we specify an explicity type?

One reason for a specific type is the custom logic to use the DID in the credential as the DID for the partner and we can't hardcode a schemaID, since it should work on different ledgers.

## Unresolved Issues

- Data in the Public Profile might be contradictory, because data in the OrgProfile and the Commercial Registry Entry might differ
- Do we need to specify an additional explicit type?
- We should allow to set the mapping between a schema and a type in the configuration/schema settings.