flowchart LR
    subgraph ACA-PY
    AR[1. Anoncreds Registry]
    ANE[Anoncreds Endpoints]
    IE[Issuance and Presentation Endpoints]
    IF[4. Issuance and Presentation Anoncreds Formats]
    AH[Anoncreds Handlers]
    DME[2. DID Management Endpoints]
    DMM[Manager]
    CON[/Connection/]
    LW[(Wallet/DB)]
    PD[\5. Public DID/]
    DME<-->DMM
    DMM<-->LW
    IE-->IF
    IF-->AH
    AH<-->AR
    AR<-->LW
    PD<-->LW
    end
    C((Controller))
    H((Holder))
    L[(3. Distributed Datasource ex: Ledger)]
    C-->DME
    C-->ANE
    AH<-->CON
    ANE<-->AR
    C-->IE
    CON<-->H
    AR<-->L
    DMM<-->L
    C<-->PD

1. Anoncreds Registry

  • Add to core at acapy_agent/anoncreds/default or load as plugin as done in acapy_agent/anoncreds/__init__.py
  • Must implement the registry interface and registrar and resolver abstract classes found in file acapy_agent/anoncreds/base.py
  • register schemas, credential definitions, revocation registry definitions, revocation list, etc.

2. Managing DID's: Common interface for creating, updating, deleting and dereferencing DID's

  • Every DID method has it's own designated endpoints. For example did:tdw would have it's own /did/tdw/create, /did/tdw/update, did/tdw/delete endpoints.
  • Each method should have a manager class that handles the logic, instead of doing it in the route controller. This is common in aca-py but should be avoided for separation of concerns reasons.
  • The payload should be common amongst all did methods for ease of use. It will include a features and options object.
  • features are things that the creator wants the did to support. The format for representing these is TBD. See https://hackmd.io/06YnFvnVQLyP_BzGQjEdIg?view#Registrars.
Details:

  • Create:

    • POST
    • body payload:
    ​​​​{
​​​​    "features": {},
​​​​    "options": {}
​​​​}
    • response body:
    ​​​​{
​​​​     "did_doc": { complex object},
​​​​     "did_metadata": { complex object}
​​​​}

  • Update:

    • PUT
    • body payload:
    ​​​​{
​​​​    "features": {},
​​​​    "options": {}
​​​​}
    • response: (TBD)

  • Delete:

    • DELETE
    • body payload:
    ​​​​{
​​​​    "did": "<did>"
​​​​}
    • response (TBD)

3. Connection to the distributed datasource (ledger)

Currently ACA-Py is very dependent on connecting to an indy ledger. You can start an agent without connection to an indy ledger with the --no-ledger true configuration option but the is no option for connecting to different types of ledgers or data sources. If a genesis transaction is configured for an agent it must connect on startup.

We need to be able to remove this restriction and allow multiple types of datasources with custom configurations to be used.

  1. Add a new configuration option with adequate format for connecting to any type of datasource.
  2. Enable ability to connect to an indy ledger using this option and remove indy logic from startup and profile initialization including class binding and api routes.
  3. Depreciate the old indy specific configuration in favor of the new datasource (ledger) agnostic configuration.

Configuration proposal:

    distributed-datasource-type: indy
    distributed-datasource-config: { complex object }
  • The type will tell acapy which class to use to validate the configuration and create the connection with the datasource. This connection should then be available for the anoncreds registry.
  • This should be designed in a way to make it pluggable.

4. Issuance and Presentation Formats

5. Public DID

  • ACA-Py currently uses a public did concept which is like an active did that is used to create indy ledger objects. This shouldn't be required with anoncreds as the issuer will send the did it wants to use in the payload of the create object request. This public did concept needs to not cause any problems with additional did methods.

This is building off of some thought and work in this document https://hackmd.io/06YnFvnVQLyP_BzGQjEdIg?view#Proposed-Solution-Technical-Architecture

Select a repo