# ACA-Py Endorser Implementation through Registry Interface

All AnonCreds registration operations return a result object. The result object can represent three different states:

- Finished - the object is fully registered to the registry
- If the object is in this state, the identifier for the object MUST be known.
- Failed - the object could not be written to the registry
- Wait - the object is pending registration to the registry
- IF the object is in this state, a "job id" MUST be provided and the identifier for the object MAY be unknown.

> Note: An `action` state was previously included in the models as well. The intent of this was to indicate to the caller that some action was required on their part to complete the registration process. It was determined that this state was redundant; action required states will be handled at the registry rather than at the anoncreds interface. There may be action required of the controller but this is not exposed in the interface and is a concern of the registry exclusively.
>
> The `action` state lingers in the implementation and ought to be removed.

For example, here is a schema result object:

{
  "job_id": "123456",
  "schema_state": {
    "state": "wait",
    "schema_id": null,
    "schema": {
      "issuerId": "did:example:abc123",
      "attrNames": [
        "firstname",
        "lastname"
      ],
      "name": "example",
      "version": "1.0"
    }
  }
}

- This schema is not yet fully registered.
- A job id is provided.
- The schema id is unknown (given that the registry may depend on a transaction id that will only exist after registration).

To complete registration of this schema, the registry must handle events or take Admin API input that advance the schema to a completed state and then call [`AnonCredsIssuer.finish_schema`](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/anoncreds/issuer.py#L230). This method takes as parameters the `job_id` and the `schema_id`. This will advance the schema to state `finished` and trigger event handlers defined elsewhere in the AnonCreds interface (i.e. automated revocation setup).

Let's take a look at another example, cred defs:

{
  "job_id": "8901234",
  "credential_definition_state": {
    "state": "wait",
    "credential_definition_id": null,
    "credential_definition": {
      "issuerId": "did:example:abc123",
      "schemaId": "did:example:abc123/anoncreds/v0/SCHEMA/example/1.0",
      "type": "CL",
      "tag": "default",
      "value": { ... }
    }
  }
}

- This cred def is not yet fully registered.
- A job id is provided.
- The cred def id is unknown.

To complete registration, registry will call [`AnonCredsIssuer.finish_cred_def`](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/anoncreds/issuer.py#L391). This method, similar to the schema variant, takes a `job_id` and a `cred_def_id`. This will fire events that cause the default revocation setup strategy to trigger creation of revocation registries in the background (which in turn will also be handled asynchronously through job ids and `AnonCredsRevocation.finish_revocation_registry_definition`).

## Vision for Endorser Support

The default Legacy Indy implementation assumes that the public DID has endorser permissions on the network it uses. Therefore, the registry interface for Indy will always have a result with state `finished` since there are no other pending steps to the registration of AnonCreds objects.

To implement endorser support, which depends on an external service that will itself respond asynchronously, an "IndyEndorserRegistry" must implement returning a `wait` state result and later triggering `finish_*` for the object in question.

Aca-Py must be updated for both the Endorser and Author roles, to use the new AnonCreds functionality.

On the Endorser side:

- remove message exchange when a commection is tagged
- remove the Endorser capability to "write transactions" (the author will always write the transaction to the ledger)
- for signing, use the anoncreds registry to access the ledger's signing method
- for writing the Author DID to the ledger, use the anoncreds registry functionality

On the Author side:

- remove message exchange when a commection is tagged
- remove support for asking the Endorser to write the ledger transaction (except for DID)
- Update the DID registration process
- add Endorser support for creating Schema
- add Endorser support for creating Credential Definitions
- add Endorser support for creating Revocation Registry (and related objects)
- add support for "workflows" - what happens after a DID is registered
- add support for "workflows" - what happens after a Credential Definition is registered (with revocation support)