## Intent
Traction tenant connects to an Endorser as part of setting up issuance.
We've been using an endorser with Auto Accept connection on. Either one we deployed ourselves to **bc0192-tools**, or if local an endorser that stands up with the Docker Compose env.

For properly using hosted Endorsers, we probably can't have Auto Accept going. So see how we can handle this flow with the current common hosted Endorser setup.

**Note**: the flow below will be different after multi-ledger selection is integrated from https://github.com/bcgov/traction/pull/790. Though the same connection call will be done.

## Endorsers
- Using the **BCovrin DEV** endorser in [4a9599-dev](https://console.apps.silver.devops.gov.bc.ca/topology/ns/4a9599-dev)
- Service API Swagger [here](https://bcovrin-endorser-service-dev.apps.silver.devops.gov.bc.ca/endorser/docs#/)
- Agent Swagger [here](https://aries-endorser-agent-admin-dev.apps.silver.devops.gov.bc.ca/api/doc)

## Setup
* Put your Traction instance on BCovrin Dev
* Acapy Genesis URL to http://dev.bcovrin.vonx.io/genesis
* Tails server (base, upload) https://tails-dev.vonx.io

* Set Endorser public DID in your Traction to corresponding BCovrin dev one
* N5bxk3jWkpZ2tEaMtjPjPa

Tried all this on **local** Docker Traction setup and it did not work, as the Endorser in 4a9599-dev could not call back to local ngrok.

2023-09-11 18:33:19,191 aries_cloudagent.transport.outbound.manager ERROR >>> Error when posting to: https://a094-23-16-82-223.ngrok.io; Error: (<class 'aiohttp.client_exceptions.ClientConnectorError'>, ClientConnectorError(ConnectionKey(host='a094-23-16-82-223.ngrok.io', port=443, is_ssl=True, ssl=None, proxy=None, proxy_auth=None, proxy_headers_hash=None), OSError(101, 'Network is unreachable')), <traceback object at 0x7f3e3d13d108>); Re-queue failed message ...

Not sure if related to NSP or what, but moved on to trying in a Traction Pull Request instead.

Set in values-pr.yaml

  argfile.yml:
    endorser-public-did: 'N5bxk3jWkpZ2tEaMtjPjPa'
    genesis-url: http://dev.bcovrin.vonx.io/genesis
    tails-server-base-url: https://dev-test.vonx.io
    tails-server-upload-url: https://dev-test.vonx.io

# Making an Issuer

## Testing Endorser Connection

**NOTE:** Below is only working with the ACA-Py 0.10.2rc. There's a bug in 0.10.1

Go to **Tenant UI** and try connecting to the Endorser.

It remains in `Request` state


[Check](https://bcovrin-endorser-service-dev.apps.silver.devops.gov.bc.ca/endorser/docs#/endorser/get_connections_v1_connections__get) in Endorser Service if connection is there. It is.


[Accept the connection](https://bcovrin-endorser-service-dev.apps.silver.devops.gov.bc.ca/endorser/docs#/endorser/accept_connection_v1_connections__connection_id__accept_post) in the Endorser Service

Get a 200 back

On the Endorser Service (and/or Agent) end, check it's showing `active` on the connection.


Check back in the Tenant UI and refresh the profile page for the Endorser Details info again.
It should show `active` there on the Traction Tenant end through the Tenant UI.

So the Endorser connection in the Tenant UI sits waiting until someone accepts it on the Endorser end.

:thumbsup:

## Testing DID Registration

The Tenant UI does 3 calls when Registering a DID as a single button step.

- /wallet/did/create
- /ledger/register-nym
- /wallet/did/public

#### Step 1
/wallet/did/create succeeds and returns the DID
Ex

    "result": {
        "did": "Qmt8CmcZhzo3crfKG3pcwp",
        "verkey": "DxYALaGkhJbCoax2sVM8bh1UiRFnx2QFmKP7htCGjiCz",
        "posture": "wallet_only",
        "key_type": "ed25519",
        "method": "sov"
    }
}

#### Step 2
/ledger/register-nym using that **DID** and **verkey** from above succeeds as far as the Tenant caller knows.

But on the Endorser side it results in a request_received Transaction.

#### Step 3
Posting wallet/did/public?did=`<DID from above>`

This fails with a 404 since it can't find the DID on the Ledger until the Endorser endorses the Txn from Step 2.

If you go and Endorse it manually, then replay that API call it will work.

Then going into the Tenant UI and refreshing you are all good.


# Cred Setup

## Schema Create

Creating a schema through the Tenant UI kind of disapears it, since it doesn't propagate back to Schema Storage after a callback.


Good news is if you then go to the Endorser service and endorse that Transaction it just shows up after a refresh. The Schema Storage record is in Traction.

## Cred Def Create

Same deal as above, UX is not nice, but endorse and refresh and it's all good.
(Tried with a revocable cred)

# Put Config to Auto endorse

Steps
1. In Tenant UI connect to Endorser
2. In Endorser Service accept connection
3. In Service, PUT config to auto endorse (below)

After this it's smooth sailing, can Register Public DID without needing endorsement after register-nym.

Can create schemas and cred defs without endorsement

# Next Steps

So for endorser connection, looks like the current UX would work, in that you can do the connection, then leave and wait until the Endorser manually approves.

After that it depends on if we can put the **AutoEndorse** config for what needs to happen next.

The Register DID steps will need an indeterminate leave-and-wait after register-nym so the Endorser can **endorse** the Transaction. Right now it just fails on the 3rd part of the single step.

I can make everything work and become an issuer doing manual API calls to finish up the Register DID stuff. So that's good, under the current UI it would just be breaking things apart by one extra action.

However, the new UI from the aforementioned multi-ledger PR will probably need a big adjustment as it only does a single step to connect and then move on to registration all at once for ledger selection.

Schema and Cred Def creation would at least need some UX consideration in the Tenant UI (unless using AutoEndorse).