# ACA-Py + did:tdw

### Authors

> Feel free to add yourself to the list as you contribute to this document

- Daniel Bluhm <[e-mail]>

## Introduction

Implement did:tdw in ACA-Py, enabling creation, resolution, issuance, and verification.

## Context

Trust DID Web (`did:tdw`) is "[an enhancement to the `did:web` DID Method, providing complementary web-based features that address `did:web`'s limitations][abstract]."

[abstract]: https://bcgov.github.io/trustdidweb/#abstract

Aries Cloud Agent - Python is an extensible foundation for decentralized identity solutions. It has long been possible to create plugins to support a wide array of use cases. However, much of ACA-Py's history and success to this point is heavily influenced by supporting Hyperledger Indy and building AnonCreds solutions based on Indy.

By integrating support for did:tdw into ACA-Py, including support for building AnonCreds solutions based on did:tdw, we will:

- Demonstrate ACA-Py's utility in both ledger based and non-ledger based decentralized identity solutions.
- Increase ACA-Py's versatility, making it even more relevant in use cases that would have otherwise required more plugin-based support.
- Further mature ACA-Py's extensible nature by eliminating Indy-isms that have persisted in the code base beyond their usefulness.
- Enable deploying an ACA-Py + AnonCreds solution with fewer external dependencies (e.g. a distributed ledger).

## Goals

- Creation of a did:tdw resolver that fits with the current resolution functionality.
- Verify that we have sufficient DID resolution support.
- Support a generic AnonCreds object resolution with a did:tdw implementation.
- Define the DID URL support ACA-Py needs to provide.
- Called within ACA-Py
- Called by the Controller.
- did:tdw resolver returns a DIDDoc or as defined by the supported DID URLs
- DID registration Controller management of DIDDoc content by feature vs. direct content
- Keep controllers simple by having ACA-Py worry about did:doc construction
- Enumerated uses of DIDs
- What does ACA-Py support today?
- Are there other features that we should define?
- What generic features get added by did:tdw?
- What DID Method specific features are needed?
- DID Method specific support for registered DID features.
- did:tdw authorization keys vs. DIDDoc keys (signing, encryption)
- did:tdw publishing -- to implictly include endorsing
- Asynchronous response to publish request.
- did:tdw witnesses
- DID Metadata management
- DID indexing by DID, verification method, verkey
- Caching(?)
- Creation of did:tdw DIDs
- Including a convention as to where DIDs are published
- Pattern to follow for other DID methods
- Separation of concerns for keys -- key(s) for authorizing updates to the DID and key(s) used by the DID
- Future: Managing key pre-rotation for authorization key
- Separation of active and pre-rotation key
- Issuance
- Including non-AnonCreds VCs/VPs
- Including publishing of AnonCreds Objects using the mechanism defined in the [Python Trust DID Web](https://github.com/bcgov/trustdidweb-py) implementation.
- Publishing
- Separation of did:tdw handling within ACA-Py from publishing did:tdw DIDs on a server.
- Future: "Endorser" concept as part of did:tdw handling. Likely transparent to ACA-Py instance.
- Resolution
- Support for "whois"
- Verification
- Including resolving of AnonCreds Objects

## Non-Goals

To be addressed in the future:

- Pre-rotation
- Witnesses

Out of scope:

- ???

## Proposed Solution (Technical Architecture)

### ACA-Py

> - did:tdw registrar
> - Possibly supporting key rotation
> - did:web registrar
> - did:tdw resolver
> - whois VP and publication

#### Registrars

- Opinionated implementation: expect to publish to a remote service with a particular interface
- Those who disagree with the opinionated implementation can always write their own plugin (may already have for did:web)
- Establish new pattern: `/did/<method>/*`, in particular `/did/<method>/create`

New Admin API Endpoints:
- POST /did/tdw/create
- Proposal: activate features we want the DID to support:
- DIDComm v1 - cause inclusion of DIDComm v1 services and keys
- DIDComm v2 - cause inclusion of DIDComm v2 services and keys
- AnonCreds - add necessary bits to do AnonCreds
- VC-DI - add ed25519 key to assertionMethod relationship
- Minimally include Ed25519 key in authentication relationship
- Number of pre-rotation keys
- Returns the created DID Document, DID Metadata
- Separate endpoints for more granular control; these can be added later (if ever)
- Providing insulation from the specifics of DIDs and DID Documents from controllers is preferable; makes complexity opt-in
- POST /did/tdw/rotate
- POST /did/web/create
- Similar options to `POST /did/tdw/create`

#### Resolvers

- Resolver is straightforward and the pattern is well established.

#### Key Management

- All keys associated with a DID should be identified by their verification method ID and not the verkey
- DID Metadata should include IDs of pre-rotation keys
- pre-rotation keys should be identified by same hash included in the DID parameters.

##### "Verkey" Usage Analysis

- As default key ID
- Stored on key creation
- As part of DID Info
- As sender and recipient in DIDComm v1
- Packing messages is dependent on verkey as ID in wallet
- Unpacking messages is dependent on verkey as ID in wallet
- Inbound key -> did -> conn lookup is not dependent on usage of verkey as ID in wallet
- Outbound target resolution is now DID native; keys are determined from DID Doc and VM refs
- As key identifier for signing
- Usually obtained by looking up DID and then using DID Info verkey attribute; could be a generic ID

"Verkey" representation of different key types is not always straightforward. Only well defined for K256 and Ed25519. A generic ID or Verification Method ID would be cleaner identifiers for a key types beyond Ed25519.

For DIDComm v1, since Ed25519 and X25519 are strictly expected, the concept of the verkey will be retained.

#### AnonCreds Registry Support

- See [Implementing a New AnonCreds Registry in ACA-Py](https://hackmd.io/@dbluhm/acapy-anoncreds-new-registry-notes).

#### LDP-VC Support

I assume this would morph into VC-DI support before too long.

- Issuance: Add did:tdw to DefaultVerificationKeyStrategy or use Verification Method ID to specify key to sign with directly
- Verification: Should be good once resolver is available

### DID Server

> - OpenAPI for resolvers -- a logical web file server
> - Authenticated API for authorized users and Endorser capabilities
> - With an endorsement configuration/UI/workflow engine.
> - Trust Registry
> - Governance Documents
> - Publish whois and DID-related files

Existing DID Web Server Implementation is promising but needs did:tdw support.

https://dws.identinet.io/

## Alternative Solutions

### ACA-Py Plugin instead of DID Server

- Supports a more "boxed" solution, limits the need for external dependencies.
- Would not support all the features of a DID Server but supports enough to publish, issue, and verify.

## Open Questions

## Glossary