Daniel Bluhm
Daniel Bluhm
So far, only the PPv2 implementation has been updated to use the new anoncreds interface. We should update the PPv1 implementation as well.
With the recent updates to didexchange adding support for did:peer:2/4, we also added support for the `did_rotate~attach` attachment. This technically bumps our protocol support up to 1.1. Credo correctly made...
Extend the implementation in ACA-Py to support AnonCreds RS by adding Endorser support. @dbluhm created the following [design document](https://hackmd.io/@dbluhm/acapy-endorser-registry) about this. A meeting was held about the design and the...
When we receive a DID Document in Connections or DID Exchange, we store the document. The document is never deleted after the associated connection is deleted. We should do that.
In https://github.com/hyperledger/aries-acapy-plugins/pull/47, we implemented verification of additional signature types. The current `/wallet/jwt/verify` endpoint only accepts Ed25519 signatures right now. It should be (was, in the plugin) pretty straightforward to verify...
See discussion in https://github.com/hyperledger/aries-cloudagent-python/pull/2615#issuecomment-1820272993
While working on #2566, I discovered that there are some tests that need attention in `aries_cloudagent/revocation/tests/test_routes.py` in the `TestDeleteTails` test case. These tests were not being run (despite the appearance...
See: https://github.com/hyperledger/aries-cloudagent-python/blob/anoncreds-rs/aries_cloudagent/anoncreds/revocation.py#L654-L656 The `handle_full_registry` method is currently stubbed out. This method should trigger rotating out the full registry, in similar fashion to what is now being done over here: https://github.com/hyperledger/aries-cloudagent-python/blob/2b0e27abb598cadc6453202aec593512c29abf3f/aries_cloudagent/revocation/indy.py#L111-L113
https://github.com/hyperledger/aries-cloudagent-python/blob/39cac36d8937ce84a9307ce100aaefb8bc05ec04/aries_cloudagent/resolver/did_resolver.py#L66-L74 The `service_accept` parameter in `DIDResolver.resolve` is questionable to me. The value is used exclusively by the Indy resolver and appears to be used to influence the `accept` parameter in...
This might be a crazy idea but what if we moved the old connection protocol code out into a plugin? As it stands, with recent fixes and updates, the protocol...