ACA-Py + did:tdw

Authors

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

• Daniel Bluhm daniel@indicio.tech

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."

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 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.

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