diff --git a/LTS-Strategy.md b/LTS-Strategy.md index 264cb485a2..a75c209e14 100644 --- a/LTS-Strategy.md +++ b/LTS-Strategy.md @@ -1,6 +1,6 @@ -# LTS Strategy +# ACA-Py LTS Strategy -This document defines the Long-term support (LTS) release strategy for Hyperledger Aries Cloud Agent Python (ACA-Py). This document is inspired from the [Hyperledger Fabric Release Strategy](https://github.com/hyperledger/fabric-rfcs/blob/main/text/0005-lts-release-strategy.md). +This document defines the Long-term support (LTS) release strategy for ACA-Py. This document is inspired from the [Hyperledger Fabric Release Strategy](https://github.com/hyperledger/fabric-rfcs/blob/main/text/0005-lts-release-strategy.md). Long-term support definition from wikipedia.org: @@ -10,14 +10,14 @@ Long-term support definition from wikipedia.org: ## Motivation -Many of those using ACA-Py rely upon the [Docker images](https://github.com/hyperledger/aries-cloudagent-python/pkgs/container/aries-cloudagent-python) which are published nightly and the [releases](https://github.com/hyperledger/aries-cloudagent-python/releases). These images contain the project dependencies/libraries which need constant security vulnerability monitoring and patching. +Many of those using ACA-Py rely upon the [Docker images](https://github.com/openwallet-foundation/acapy/pkgs/container/acapy-agent) which are published nightly and the [releases](https://github.com/openwallet-foundation/acapy/releases). These images contain the project dependencies/libraries which need constant security vulnerability monitoring and patching. -This is one of the factors which motivated setting up the LTS releases which requires the docker images to be scanned regularly and patching them for vulnerabilies. +This is one of the factors which motivated setting up the LTS releases which requires the docker images to be scanned regularly and patching them for vulnerabilities. In addition to this, administrators can expect the following of a LTS release: - Stable and well-tested code -- A list of supported RFCs and features for each LTS version from this [document](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/SupportedRFCs.md). +- A list of supported RFCs and features for each LTS version from this [document](https://github.com/openwallet-foundation/acapy/blob/main/docs/features/SupportedRFCs.md). - Minimal set of feature additions and other changes that can easily be applied, reducing the risk of functional regressions and bugs Similarly, there are benefits to ACA-Py maintainers, code contributors, and the wider community: @@ -43,7 +43,7 @@ If a major release is not delivered for an extended period of time, the maintain ### LTS 3rd Digit Patch Releases -For LTS releases, 3rd digit patch releases will be provided for bug and security fixes approximately every three months based on the fixes (or lack thereof) to be applied. In order to ensure the stability of the LTS release and reduce the risk of functional regressions and bugs, significant new features and other changes occuring on the `main` branch, and released in later minor or major versions will not be included in LTS patch releases. +For LTS releases, 3rd digit patch releases will be provided for bug and security fixes approximately every three months based on the fixes (or lack thereof) to be applied. In order to ensure the stability of the LTS release and reduce the risk of functional regressions and bugs, significant new features and other changes occurring on the `main` branch, and released in later minor or major versions will not be included in LTS patch releases. ### LTS Release Duration @@ -51,18 +51,17 @@ When a *new* LTS release is designated, an "end-of-life" date will be set as bei ### LTS to LTS Compatibility -Features related to ACA-Py capabilities are documented in the [Supported RFCs and features](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/SupportedRFCs.md), in the ACA-Py [ChangeLog](https://github.com/hyperledger/aries-cloudagent-python/blob/main/CHANGELOG.md), and in documents updated and added as part of each ACA-Py Release. LTS to LTS compatibility can be determined from reviewing those sources. +Features related to ACA-Py capabilities are documented in the [Supported RFCs and features](https://github.com/openwallet-foundation/acapy/blob/main/docs/features/SupportedRFCs.md), in the ACA-Py [ChangeLog](https://github.com/openwallet-foundation/acapy/blob/main/CHANGELOG.md), and in documents updated and added as part of each ACA-Py Release. LTS to LTS compatibility can be determined from reviewing those sources. ### Upgrade Testing -The ACA-Py project expects to test and provide guidance on all major/minor upgrades (e.g. 0.11 to 0.12). Other upgrade paths will not be tested and are not guaranteed to work. Consult the [ChangeLog](https://github.com/hyperledger/aries-cloudagent-python/blob/main/CHANGELOG.md) and its pointers to release-to-release upgrade information for guidance. +The ACA-Py project expects to test and provide guidance on all major/minor upgrades (e.g. 0.11 to 0.12). Other upgrade paths will not be tested and are not guaranteed to work. Consult the [ChangeLog](https://github.com/openwallet-foundation/acapy/blob/main/CHANGELOG.md) and its pointers to release-to-release upgrade information for guidance. ## Prior art and alternatives -[prior-art]: #prior-art While many open source projects provide LTS releases, there is no industry standard for LTS release approach. Projects use many different variants of LTS approaches to best suit their project's particular needs. -This release strategy was based on the following opensource projects: +This release strategy was based on the following open source projects: - [Hyperledger Fabric](https://github.com/hyperledger/fabric-rfcs/blob/main/text/0005-lts-release-strategy.md) - [NodeJS](https://nodejs.org/en/about/previous-releases) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 245b421a13..0d4b41853a 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -3,7 +3,7 @@ ## Maintainer Scopes, GitHub Roles and GitHub Teams The Maintainers of this repo, defined as GitHub users with escalated privileges -in the repo, are managed in the Hyperledger "governance" repo's [access-control.yaml](https://github.com/hyperledger/governance/blob/main/access-control.yaml) file. Consult that to see: +in the repo, are managed in the Hyperledger "governance" repo's [access-control.yaml](https://github.com/openwallet-foundation/governance/blob/main/config.yaml) file. Consult that to see: - What teams have escalated privileges to this repository. - What GitHub roles those teams have in the repository. diff --git a/Managing-ACA-Py-Doc-Site.md b/Managing-ACA-Py-Doc-Site.md index a14ab43ecb..6355385afb 100644 --- a/Managing-ACA-Py-Doc-Site.md +++ b/Managing-ACA-Py-Doc-Site.md @@ -11,7 +11,7 @@ after creation. From time to time, some "extra" maintenance on the versions are needed and this document describes those activities. [MkDocs Material]: https://squidfunk.github.io/mkdocs-material/ -[publish-docs]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/.github/workflows/publish-docs.yml +[publish-docs]: https://github.com/openwallet-foundation/acapy/blob/main/.github/workflows/publish-docs.yml ## Generation Process @@ -35,8 +35,8 @@ When the GitHub Action fires, it runs a container that carries out the following to look at. The process uses the [mkdocs.yml] configuration file in generating the site. -[scripts/prepmkdocs.sh]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/scripts/prepmkdocs.sh -[mkdocs.yml]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/mkdocs.yml +[scripts/prepmkdocs.sh]: https://github.com/openwallet-foundation/acapy/blob/main/scripts/prepmkdocs.sh +[mkdocs.yml]: https://github.com/openwallet-foundation/acapy/blob/main/mkdocs.yml ## Preparing for a Release diff --git a/NOTICES b/NOTICES index bf9636c516..4cde701bae 100644 --- a/NOTICES +++ b/NOTICES @@ -1,4 +1,4 @@ -The aries-cloudagent-python project relies on the following open source +The ACA-Py project relies on the following open source components for run-time execution. These components are released under separate copyright notices and license terms. diff --git a/PUBLISHING.md b/PUBLISHING.md index 4634bdc199..d0eb2e500d 100644 --- a/PUBLISHING.md +++ b/PUBLISHING.md @@ -57,9 +57,9 @@ The output should look like this -- and what you see in [CHANGELOG.md](CHANGELOG ```text - - chore(deps): Bump mkdocs-material from 9.5.34 to 9.5.36 [\#3249](https://github.com/hyperledger/aries-cloudagent-python/pull/3249) [app/dependabot](https://github.com/app/dependabot) - - chore(deps-dev): Bump ruff from 0.6.5 to 0.6.7 [\#3248](https://github.com/hyperledger/aries-cloudagent-python/pull/3248) [app/dependabot](https://github.com/app/dependabot) - - Feature multikey management [\#3246](https://github.com/hyperledger/aries-cloudagent-python/pull/3246) [PatStLouis](https://github.com/PatStLouis) + - Only change interop testing fork on pull requests [\#3218](https://github.com/openwallet-foundation/acapy/pull/3218) [jamshale](https://github.com/jamshale) + - Remove the RC from the versions table [\#3213](https://github.com/openwallet-foundation/acapy/pull/3213) [swcurran](https://github.com/swcurran) + - Feature multikey management [\#3246](https://github.com/openwallet-foundation/acapy/pull/3246) [PatStLouis](https://github.com/PatStLouis) ``` @@ -72,7 +72,7 @@ Once you have the list of PRs: ```text - Dependabot PRs - - [List of Dependabot PRs in this release](https://github.com/hyperledger/aries-cloudagent-python/pulls?q=is%3Apr+is%3Amerged+merged%3A2024-08-16..2024-09-16+author%3Aapp%2Fdependabot+) + - [List of Dependabot PRs in this release](https://github.com/openwallet-foundation/acapy/pulls?q=is%3Apr+is%3Amerged+merged%3A2024-08-16..2024-09-16+author%3Aapp%2Fdependabot+) ``` Include a PR for this soon-to-be PR. You can guess at the number of the PR by using this command `gh issue list -s all -L 2; gh pr ls -s all -L 2` to see the highest PR and issues, but you still might have to correct the number after you create the PR if someone sneaks one in before you submit your PR. @@ -116,7 +116,7 @@ Include a PR for this soon-to-be PR. You can guess at the number of the PR by us 10. Immediately after it is merged, create a new GitHub tag representing the version. The tag name and title of the release should be the same as the - version in [pyproject.toml](https://github.com/hyperledger/aries-cloudagent-python/tree/main/pyproject.toml). Use + version in [pyproject.toml](https://github.com/openwallet-foundation/acapy/tree/main/pyproject.toml). Use the "Generate Release Notes" capability to get a sequential listing of the PRs in the release, to complement the manually curated Changelog. Verify on PyPi that the version is published. @@ -124,8 +124,8 @@ Include a PR for this soon-to-be PR. You can guess at the number of the PR by us 11. New images for the release are automatically published by the GitHubAction Workflows: [publish.yml] and [publish-indy.yml]. The actions are triggered when a release is tagged, so no manual action is needed. The images are - published in the [Hyperledger Package Repository under - aries-cloudagent-python](https://github.com/orgs/hyperledger/packages?repo_name=aries-cloudagent-python) + published in the [OpenWallet Foundation Package Repository under + acapy](https://github.com/openwallet-foundation/packages?repo_name=acapy) and a link to the packages added to the repositories main page (under "Packages"). @@ -135,10 +135,10 @@ Include a PR for this soon-to-be PR. You can guess at the number of the PR by us In addition, the published documentation site [https://aca-py.org] should be automatically updated to include the new release via the [publish-docs] GitHub Action. Additional information about that process and some related maintenance activities that are needed from time to time can be found in the [Updating the ACA-Py Documentation Site] document. -[publish.yml]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/.github/workflows/publish.yml -[publish-indy.yml]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/.github/workflows/publish-indy.yml +[publish.yml]: https://github.com/openwallet-foundation/acapy/blob/main/.github/workflows/publish.yml +[publish-indy.yml]: https://github.com/openwallet-foundation/acapy/blob/main/.github/workflows/publish-indy.yml -12. When a new release is tagged, create a new branch at the same commit with +1. When a new release is tagged, create a new branch at the same commit with the branch name in the format `docs-v`, for example, `docs-v1.0.1rc1`. The creation of the branch triggers the execution of the [publish-docs] GitHub Action which generates the documentation for the new release, @@ -148,7 +148,7 @@ Include a PR for this soon-to-be PR. You can guess at the number of the PR by us publishing process and some related maintenance activities that are needed from time to time can be found in the [Managing the ACA-Py Documentation Site] document. -[publish-docs]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/.github/workflows/publish-docs.yml +[publish-docs]: https://github.com/openwallet-foundation/acapy/blob/main/.github/workflows/publish-docs.yml [Managing the ACA-Py Documentation Site]: Managing-ACA-Py-Doc-Site.md [https://aca-py.org]: https://aca-py.org diff --git a/README.md b/README.md index 08921dd4b5..2e6a569b2f 100644 --- a/README.md +++ b/README.md @@ -1,25 +1,25 @@ -# Hyperledger Aries Cloud Agent - Python +# ACA-Py -- A Cloud Agent - Python 🚨 **ACA-Py is transitioning to the [OpenWallet Foundation] (OWF)!** 🚨 [OpenWallet Foundation]: https://openwallet.foundation/ -We’re excited to announce that the ACA-Py project will soon be moving to the OWF's GitHub organization under the [new "acapy" project](https://github.com/openwallet-foundation/project-proposals/pull/42). This is an important transition for the community, and we’ll ensure it's smooth and well-documented. +We’re excited to announce that the ACA-Py project has moved to the OWF's GitHub organization as the [new "acapy" project](https://github.com/openwallet-foundation/project-proposals/blob/main/projects/aca-py.md). -For details on what this means for ACA-Py users, including steps for updating deployments, please follow the updates in [GitHub Issue #3250]. We'll keep you informed about the approach, timeline, and progress of the move. Stay tuned! +For details on what this means for ACA-Py users, including steps for updating deployments, please follow the updates in [GitHub Issue #3250]. We'll keep you informed about how to update your deployment to reflect this change. Stay tuned! -[GitHub Issue #3250]: https://github.com/hyperledger/aries-cloudagent-python/issues/3250 +[GitHub Issue #3250]: https://github.com/openwallet-foundation/acapy/issues/3250

- + - -   -   -   + +   +   +  

-> An easy to use Aries agent for building SSI services using any language that supports sending/receiving HTTP requests. +> An easy to use enterprise wallet for building decentralized trust services using any language that supports sending/receiving HTTP requests. Full access to an organized set of all of the ACA-Py documents is available at [https://aca-py.org](https://aca-py.org). Check it out! It's much easier to navigate than the ACA-Py GitHub repo for reading the documentation. @@ -28,16 +28,16 @@ Check it out! It's much easier to navigate than the ACA-Py GitHub repo for readi ## Overview -Hyperledger Aries Cloud Agent Python (ACA-Py) is a foundation for building Verifiable Credential (VC) ecosystems. It operates in the second and third layers of the [Trust Over IP framework (PDF)](https://trustoverip.org/wp-content/uploads/2020/05/toip_050520_primer.pdf) using [DIDComm messaging](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0005-didcomm) and [Hyperledger Aries](https://www.hyperledger.org/use/aries) protocols. The "cloud" in the name means that ACA-Py runs on servers (cloud, enterprise, IoT devices, and so forth), and is not designed to run on mobile devices. +ACA-Py is a foundation for building Verifiable Credential (VC) ecosystems. It operates in the second and third layers of the [Trust Over IP framework (PDF)](https://trustoverip.org/wp-content/uploads/2020/05/toip_050520_primer.pdf) using a variety of verifiable credential formats and protocols. ACA-Py runs on servers (cloud, enterprise, IoT devices, and so forth), and is not designed to run on mobile devices. -ACA-Py is built on the Aries concepts and features that make up [Aries Interop Profile (AIP) 2.0](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#aries-interop-profile-version-20). [ACA-Py’s supported Aries protocols](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/SupportedRFCs.md) include, most importantly, protocols for issuing, verifying, and holding verifiable credentials using both [Hyperledger AnonCreds] verifiable credential format, and the [W3C Standard Verifiable Credential Data Model] format using JSON-LD with LD-Signatures and BBS+ Signatures. Coming soon -- issuing and presenting [Hyperledger AnonCreds] verifiable credentials using the [W3C Standard Verifiable Credential Data Model] format. +ACA-Py includes support for the concepts and features that make up [Aries Interop Profile (AIP) 2.0](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#aries-interop-profile-version-20). [ACA-Py’s supported features](./docs/features/SupportedRFCs.md) include, most importantly, protocols for issuing, verifying, and holding verifiable credentials using both [Hyperledger AnonCreds] verifiable credential format, and the [W3C Standard Verifiable Credential Data Model] format using JSON-LD with LD-Signatures and BBS+ Signatures. Coming soon -- issuing and presenting [Hyperledger AnonCreds] verifiable credentials using the [W3C Standard Verifiable Credential Data Model] format. [Hyperledger AnonCreds]: https://www.hyperledger.org/use/anoncreds [W3C Standard Verifiable Credential Data Model]: https://www.w3.org/TR/vc-data-model/ -To use ACA-Py you create a business logic controller that "talks to" an ACA-Py instance (sending HTTP requests and receiving webhook notifications), and ACA-Py handles the Aries and DIDComm protocols and related functionality. Your controller can be built in any language that supports making and receiving HTTP requests; knowledge of Python is not needed. Together, this means you can focus on building VC solutions using familiar web development technologies, instead of having to learn the nuts and bolts of low-level cryptography and Trust over IP-type Aries protocols. +To use ACA-Py you create a business logic "controller" that talks to an ACA-Py instance (sending HTTP requests and receiving webhook notifications), and ACA-Py handles the various protocols and related functionality. Your controller can be built in any language that supports making and receiving HTTP requests; knowledge of Python is not needed. Together, this means you can focus on building VC solutions using familiar web development technologies, instead of having to learn the nuts and bolts of low-level cryptography and Trust over IP-type protocols. -This [checklist-style overview document](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/SupportedRFCs.md) provides a full list of the features in ACA-Py. +This [checklist-style overview document](./docs/features/SupportedRFCs.md) provides a full list of the features in ACA-Py. The following is a list of some of the core features needed for a production deployment, with a link to detailed information about the capability. ## LTS Releases @@ -45,15 +45,15 @@ The following is a list of some of the core features needed for a production dep The ACA-Py community provides periodic releases with new features and improvements. Certain releases are designated by the ACA-Py maintainers as long-term support (LTS) releases and listed in this document. Critical bugs and -important (as determined by the ACA-Py Maintainers) fixes will be backported to +important (as determined by the ACA-Py Maintainers) fixes are backported to the active LTS releases. Each LTS release will be supported with patches for **9 months** following the designation of the **next** LTS Release. For more details see the [LTS strategy](./LTS-Strategy.md). Current LTS releases are: -- [0.12](https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.12.1) **Current LTS Release** -- [0.11](https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.11.1) **End of Life: January 2025** +- [0.12](https://github.com/openwallet-foundation/acapy/releases/tag/0.12.1) **Current LTS Release** +- [0.11](https://github.com/openwallet-foundation/acapy/releases/tag/0.11.1) **End of Life: January 2025** Unless specified in the **Breaking Changes** section of the ACA-Py [CHANGELOG](./CHANGELOG.md), all LTS patch releases will be able to be deployed @@ -64,19 +64,19 @@ at [https://aca-py.org](https://aca-py.org) from the markdown files in this repository. ACA-Py releases and release notes can be found on the [GitHub releases -page](https://github.com/hyperledger/aries-cloudagent-python/releases). +page](https://github.com/openwallet-foundation/acapy/releases). ### Multi-Tenant -ACA-Py supports "multi-tenant" scenarios. In these scenarios, one (scalable) instance of ACA-Py uses one database instance, and are together capable of managing separate secure storage (for private keys, DIDs, credentials, etc.) for many different actors. This enables (for example) an "issuer-as-a-service", where an enterprise may have many VC issuers, each with different identifiers, using the same instance of ACA-Py to interact with VC holders as required. Likewise, an ACA-Py instance could be a "cloud wallet" for many holders (e.g. people or organizations) that, for whatever reason, cannot use a mobile device for a wallet. Learn more about multi-tenant deployments [here](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/Multitenancy.md). +ACA-Py supports "multi-tenant" scenarios. In these scenarios, one (scalable) instance of ACA-Py uses one database instance, and are together capable of managing separate secure storage (for private keys, DIDs, credentials, etc.) for many different actors. This enables (for example) an "issuer-as-a-service", where an enterprise may have many VC issuers, each with different identifiers, using the same instance of ACA-Py to interact with VC holders as required. Likewise, an ACA-Py instance could be a "cloud wallet" for many holders (e.g. people or organizations) that, for whatever reason, cannot use a mobile device for a wallet. Learn more about multi-tenant deployments [here](./docs/features/Multitenancy.md). ### Mediator Service -Startup options allow the use of an ACA-Py as an Aries [mediator](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0046-mediators-and-relays#summary) using core Aries protocols to coordinate its mediation role. Such an ACA-Py instance receives, stores and forwards messages to Aries agents that (for example) lack an addressable endpoint on the Internet such as a mobile wallet. A live instance of a public mediator based on ACA-Py is available [here](https://indicio-tech.github.io/mediator/) from Indicio Technologies. Learn more about deploying a mediator [here](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/Mediation.md). See the [Aries Mediator Service](https://github.com/hyperledger/aries-mediator-service) for a "best practices" configuration of an Aries mediator. +Startup options allow the use of an ACA-Py as a DIDComm [mediator](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0046-mediators-and-relays#summary) using core DIDComm protocols to coordinate its mediation role. Such an ACA-Py instance receives, stores and forwards messages to DIDComm agents that (for example) lack an addressable endpoint on the Internet such as a mobile wallet. A live instance of a public mediator based on ACA-Py is available [here](https://indicio-tech.github.io/mediator/) from [Indicio, PBC](https://indicio.tech). Learn more about deploying a mediator [here](./docs/features/Mediation.md). See the [Aries Mediator Service](https://github.com/hyperledger/aries-mediator-service) for a "best practices" configuration of an Aries mediator. ### Indy Transaction Endorsing -ACA-Py supports a Transaction Endorsement protocol, for agents that don't have write access to an Indy ledger. Endorser support is documented [here](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/Endorser.md). +ACA-Py supports a Transaction Endorsement protocol, for agents that don't have write access to an Indy ledger. Endorser support is documented [here](./features/Endorser.md). ### Scaled Deployments @@ -84,7 +84,7 @@ ACA-Py supports deployments in scaled environments such as in Kubernetes environ ### VC-API Endpoints -A set of endpoints conforming to the vc-api specification are included to manage w3c credentials and presentations. They are documented [here](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/JsonLdCredentials.md#vc-api) and a postman demo is available [here](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/JsonLdCredentials.md#vc-api). +A set of endpoints conforming to the vc-api specification are included to manage w3c credentials and presentations. They are documented [here](./docs/features/JsonLdCredentials.md#vc-api) and a postman demo is available [here](./docs/features/JsonLdCredentials.md#vc-api). ## Example Uses @@ -100,14 +100,14 @@ The business logic you use with ACA-Py is limited only by your imagination. Poss ## Getting Started -For those new to SSI, Aries and ACA-Py, there are a couple of Linux Foundation edX courses that provide a good starting point. +For those new to SSI, Wallets, and ACA-Py, there are a couple of Linux Foundation edX courses that provide a good starting point. * [Identity in Hyperledger: Indy, Aries and Ursa](https://www.edx.org/course/identity-in-hyperledger-aries-indy-and-ursa) * [Becoming a Hyperledger Aries Developer](https://www.edx.org/course/becoming-a-hyperledger-aries-developer) The latter is the most useful for developers wanting to get a solid basis in using ACA-Py and other Aries Frameworks. -Also included here is a much more concise (but less maintained) [Getting Started Guide](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/gettingStarted/README.md) that will take you from knowing next to nothing about decentralized identity to developing Aries-based business apps and services. You’ll run an Indy ledger (with no ramp-up time), ACA-Py apps and developer-oriented demos. The guide has a table of contents so you can skip the parts you already know. +Also included here is a much more concise (but less maintained) [Getting Started Guide](./docs/gettingStarted/README.md) that will take you from knowing next to nothing about decentralized identity to developing Aries-based business apps and services. You’ll run an Indy ledger (with no ramp-up time), ACA-Py apps and developer-oriented demos. The guide has a table of contents so you can skip the parts you already know. ### Understanding the Architecture @@ -115,22 +115,22 @@ There is an [architectural deep dive webinar](https://www.youtube.com/watch?v=FX ![drawing](./aca-py_architecture.png) -You can extend ACA-Py using plug-ins, which can be loaded at runtime. Plug-ins are mentioned in the [webinar](https://docs.google.com/presentation/d/1K7qiQkVi4n-lpJ3nUZY27OniUEM0c8HAIk4imCWCx5Q/edit#slide=id.g5d43fe05cc_0_145) and are [described in more detail here](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/PlugIns.md). An ever-expanding set of ACA-Py plugins can be found -in the [Aries ACA-Py Plugins repository]. Check them out -- it might have the very plugin you need! +You can extend ACA-Py using plug-ins, which can be loaded at runtime. Plug-ins are mentioned in the [webinar](https://docs.google.com/presentation/d/1K7qiQkVi4n-lpJ3nUZY27OniUEM0c8HAIk4imCWCx5Q/edit#slide=id.g5d43fe05cc_0_145) and are [described in more detail here](./docs/features/PlugIns.md). An ever-expanding set of ACA-Py plugins can be found +in the [ACA-Py Plugins repository]. Check them out -- it might already have the very plugin you need! -[Aries ACA-Py Plugins repository]: https://github.com/hyperledger/aries-acapy-plugins +[ACA-Py Plugins repository]: https://plugins.aca-py.org ### Installation and Usage -Use the ["install and go" page for developers](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/DevReadMe.md) if you are comfortable with Trust over IP and Aries concepts. ACA-Py can be run with Docker without installation (highly recommended), or can be installed [from PyPi](https://pypi.org/project/aries-cloudagent/). In the repository `/demo` folder there is a full set of demos for developers to use in getting up to speed quickly. Start with the [Traction Workshop] to go through a complete ACA-Py-based Issuer-Holder-Verifier flow in about 20 minutes. Next, the [Alice-Faber Demo](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/demo/README.md) is a great way for developers try a zero-install example of how to use the ACA-Py API to operate a couple of Aries Agents. The [Read the Docs](https://aries-cloud-agent-python.readthedocs.io/en/latest/) overview is also a way to understand the internal modules and APIs that make up an ACA-Py instance. +Use the ["install and go" page for developers](./docs/features/DevReadMe.md) if you are comfortable with decentralized trust concepts. ACA-Py can be run with Docker without installation (highly recommended), or can be installed [from PyPi](https://pypi.org/project/acapy-agent/). In the repository `/demo` folder there is a full set of demos for developers to use in getting up to speed quickly. Start with the [Traction Workshop] to go through a complete ACA-Py-based Issuer-Holder-Verifier flow in about 20 minutes. Next, the [Alice-Faber Demo](./docs/demo/README.md) is a great way for developers try a zero-install example of how to use the ACA-Py API to operate a couple of Agents. The [Read the Docs](https://aries-cloud-agent-python.readthedocs.io/en/latest/) overview is also a way to understand the internal modules and APIs that make up an ACA-Py instance. -If you would like to develop on ACA-Py locally note that we use Poetry for dependency management and packaging, if you are unfamiliar with poetry please see our [cheat sheet](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/deploying/Poetry.md) +If you would like to develop on ACA-Py locally note that we use Poetry for dependency management and packaging. If you are unfamiliar with poetry please see our [cheat sheet](./docs/deploying/Poetry.md) -[Traction Workshop]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/demo/Aries-Workshop.md +[Traction Workshop]: ./docs/demo/Aries-Workshop.md ## About the ACA-Py Admin API -The [overview of ACA-Py’s API](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/features/AdminAPI.md) is a great starting place for learning about the ACA-Py API when you are starting to build your own controller. +The [overview of ACA-Py’s API](./docs/features/AdminAPI.md) is a great starting place for learning about the ACA-Py API when you are starting to build your own controller. An ACA-Py instance puts together an OpenAPI-documented REST interface based on the protocols that are loaded. This is used by a controller application (written in any language) to manage the behavior of the agent. The controller can initiate actions (e.g. issuing a credential) and can respond to agent events (e.g. sending a presentation request after a connection is accepted). Agent events are delivered to the controller as webhooks to a configured URL. @@ -140,14 +140,14 @@ Technical note: the administrative API exposed by the agent for the controller t There are a number of resources for getting help with ACA-Py and troubleshooting any problems you might run into. The -[Troubleshooting](https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/testing/Troubleshooting.md) document contains some +[Troubleshooting](./testing/Troubleshooting.md) document contains some guidance about issues that have been experienced in the past. Feel free to submit PRs to supplement the troubleshooting document! Searching the [ACA-Py -GitHub issues](https://github.com/hyperledger/aries-cloudagent-python/issues) +GitHub issues](https://github.com/openwallet-foundation/acapy/issues) may uncovers challenges you are having that others have experienced, often -with solutions. As well, there is the "aries-cloudagent-python" -channel on the Hyperledger Discord chat server ([invitation -here](https://discord.gg/hyperledger)). +with solutions. As well, there is the "aca-py" +channel on the OpenWallet Foundation Discord chat server ([invitation +here](https://discord.gg/openwalletfoundation)). ## Credit @@ -155,14 +155,14 @@ The initial implementation of ACA-Py was developed by the Government of British [BC Digital Trust]: https://digital.gov.bc.ca/digital-trust/ -See the [MAINTAINERS.md](https://github.com/hyperledger/aries-cloudagent-python/blob/main/MAINTAINERS.md) file for a list of the current ACA-Py -maintainers, and the guidelines for becoming a Maintainer. We'd love to have you -join the team if you are willing and able to carry out the [duties of a Maintainer](https://github.com/hyperledger/aries-cloudagent-python/blob/main/MAINTAINERS.md#the-duties-of-a-maintainer). +See the [MAINTAINERS.md](./MAINTAINERS.md) file for how to find a list of the current ACA-Py +maintainers, and guidelines for becoming a Maintainer. We'd love to have you +join the team if you are willing and able to carry out the [duties of a Maintainer](./MAINTAINERS.md#the-duties-of-a-maintainer). ## Contributing -Pull requests are welcome! Please read our [contributions guide](https://github.com/hyperledger/aries-cloudagent-python/blob/main/CONTRIBUTING.md) and submit your PRs. We enforce [developer certificate of origin](https://developercertificate.org/) (DCO) commit signing — [guidance](https://github.com/apps/dco) on this is available. We also welcome issues submitted about problems you encounter in using ACA-Py. +Pull requests are welcome! Please read our [contributions guide](./CONTRIBUTING.md) and submit your PRs. We enforce [developer certificate of origin](https://developercertificate.org/) (DCO) commit signing — [guidance](https://github.com/apps/dco) on this is available. We also welcome issues submitted about problems you encounter in using ACA-Py. ## License -[Apache License Version 2.0](https://github.com/hyperledger/aries-cloudagent-python/blob/main/LICENSE) +[Apache License Version 2.0](https://github.com/openwallet-foundation/acapy/blob/main/LICENSE) diff --git a/demo/README.md b/demo/README.md index 82f3ef4304..18d1e7b7d7 100644 --- a/demo/README.md +++ b/demo/README.md @@ -1,4 +1,4 @@ -# Aries Cloud Agent Python (ACA-Py) Demos +# ACA-Py Demos The documentation for the ACA-Py demos is published on the [aca-py.org](https://aca-py.org) documentation site in the `Demos` tab. Jump over there to learn more about using ACA-Py and going through the many demos available. diff --git a/docs/README.md b/docs/README.md index 95a18c0dae..9c544ea4de 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,6 +1,6 @@ # The ACA-Py `docs` Folder -The Aries Cloud Agent Python docs folder contains the source content for the +The ACA-Py `docs` folder contains the source content for the ACA-Py documentation site [aca-py.org] and for the ACA-Py source code internals documentation project at ReadTheDocs, published at [https://aries-cloud-agent-python.readthedocs.io]. diff --git a/docs/UpdateRTD.md b/docs/UpdateRTD.md index 6b273af186..bc44201a86 100644 --- a/docs/UpdateRTD.md +++ b/docs/UpdateRTD.md @@ -1,4 +1,4 @@ -# Managing Aries Cloud Agent Python `Read The Docs` Documentation +# Managing ACA-Py `Read The Docs` Documentation This document describes how to maintain the `Read The Docs` documentation that is generated from the ACA-Py code base. As the structure of the ACA-Py code @@ -16,7 +16,7 @@ and verify the installation on your system. To rebuild the project and settings from scratch (you'll need to move the generated index file up a level): -`rm -rf generated; sphinx-apidoc -f -M -o ./generated ../aries_cloudagent/ $(find ../aries_cloudagent/ -name '*tests*')` +`rm -rf generated; sphinx-apidoc -f -M -o ./generated ../acapy_agent/ $(find ../acapy_agent/ -name '*tests*')` Note that the `find` command that is used to exclude any of the `test` python files from the RTD documentation. @@ -49,10 +49,10 @@ to adhere to the rules around processing docstrings, and especially around JSON ### Checking for missing modules The file `index.rst` in the ACA-Py `docs` folder drive the RTD generation. It picks up all the modules -in the source code, starting from the root `../aries_cloudagent` folder. However, some modules +in the source code, starting from the root `../acapy_agent` folder. However, some modules are not picked up automatically from the root and have to be manually added to `index.rst`. To do that: -- Get a list of all generated modules by running: `ls generated | grep "aries_cloudagent.[a-z]*.rst"` +- Get a list of all generated modules by running: `ls generated | grep "acapy_agent.[a-z]*.rst"` - Compare that list with the modules listed in the "Subpackages" section of the left side menu in your browser, including any listed below the "Submodules". If any are missing, you likely need to add them to the `index.rst` file in the `toctree` section of the file. diff --git a/docs/aca-py.org.md b/docs/aca-py.org.md index 5c6c394712..8d1f08e36b 100644 --- a/docs/aca-py.org.md +++ b/docs/aca-py.org.md @@ -2,12 +2,17 @@ ![Hyperledger Aries](https://raw.githubusercontent.com/hyperledger/aries-acapy-docs/main/assets/Hyperledger_Aries_Logo_Color.png) -Welcome to the Aries Cloud Agent Python documentation site. On this site you -will find documentation for recent releases of ACA-Py. You'll find a few of the -older versions of ACA-Py (pre-`0.8.0`), all versions since `0.8.0`, and the -`main` branch, which is the latest and greatest. +Welcome to the ACA-Py documentation site! On this site you +will find documentation for all of the recent releases of ACA-Py -- starting from +LTS release 0.11.0. -All of the documentation here is extracted from the [Aries Cloud Agent Python repository]. +> [!NOTE] +> ACA-Py has recently moved to the [OpenWallet +> Foundation](https://openwallet.foundation/). ACA-Py used to be called "Aries +> Cloud Agent Python", but in the move to OWF, we dropped the "Aries" part, and +> made the acronym the name. So ACA-Py it is! + +All of the documentation here is extracted from the [ACA-Py repository]. If you want to contribute to the documentation, please start there. Ready to go? Scan the tabs in the page header to find the documentation you need now! @@ -17,13 +22,12 @@ Ready to go? Scan the tabs in the page header to find the documentation you need In addition to this documentation site, the ACA-Py community also maintains an ACA-Py internals documentation site. The internals documentation consists of the `docstrings` extracted from the ACA-Py Python code and covers all of the -(non-test) modules in the codebase. Check it out on the [Aries Cloud -Agent-Python ReadTheDocs site](https://aries-cloud-agent-python.readthedocs.io/en/latest/). +(non-test) modules in the codebase. Check it out on the [ACA-Py ReadTheDocs site](https://aries-cloud-agent-python.readthedocs.io/en/latest/). As with this site, the ReadTheDocs documentation is version specific. Got questions? -- Join us on the [Hyperledger Discord Server](https://chat.hyperledger.org), in the `#aries-cloudagent-python` channel. -- Add an issue in the [Aries Cloud Agent Python repository]. +- Join us on the [OpenWallet Foundation Discord Server](https://discord.gg/openwallet-foundation), in the `#aca-py` channel. +- Add an issue in the [ACA-Py repository]. -[Aries Cloud Agent Python repository]: https://github.com/hyperledger/aries-cloudagent-python +[ACA-Py repository]: https://github.com/openwallet-foundation/acapy diff --git a/docs/conf.py b/docs/conf.py index c5ead40f54..e81bb10889 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -62,17 +62,17 @@ "uuid_utils", ] -# "aries_cloudagent.tests.test_conductor", -# "aries_cloudagent.tests.test_init", -# "aries_cloudagent.messaging.connections.tests", -# "aries_cloudagent.messaging.connections.messages.tests", -# "aries_cloudagent.messaging.introduction.messages.tests" +# "acapy_agent.tests.test_conductor", +# "acapy_agent.tests.test_init", +# "acapy_agent.messaging.connections.tests", +# "acapy_agent.messaging.connections.messages.tests", +# "acapy_agent.messaging.introduction.messages.tests" # -- Project information ----------------------------------------------------- -project = "Aries Cloud Agent - Python" -copyright = "2023, Province of British Columbia" +project = "ACA-Py" +copyright = "2024, Province of British Columbia" author = "Province of British Columbia" # The short X.Y version @@ -128,7 +128,7 @@ "GettingStartedAriesDev/*", "assets/*", "Poetry.md", - "aries_cloudagent/*", + "acapy_agent/*", ] # The name of the Pygments (syntax highlighting) style to use. @@ -166,7 +166,7 @@ # -- Options for HTMLHelp output --------------------------------------------- # Output file base name for HTML help builder. -htmlhelp_basename = "AriesCloudAgentPythondoc" +htmlhelp_basename = "acapydoc" # -- Options for LaTeX output ------------------------------------------------ @@ -192,8 +192,8 @@ latex_documents = [ ( master_doc, - "AriesCloudAgentPython.tex", - "Aries Cloud Agent Python Documentation", + "ACA-Py.tex", + "ACA-Py Documentation", "See Contributors list on GitHub", "manual", ) @@ -207,8 +207,8 @@ man_pages = [ ( master_doc, - "ariescloudagentpython", - "Aries Cloud Agent Python Documentation", + "aca-py", + "ACA-Py Documentation", [author], 1, ) @@ -223,11 +223,11 @@ texinfo_documents = [ ( master_doc, - "AriesCloudAgentPython", - "Aries CloudAgent Python Documentation", + "ACA-Py", + "ACA-Py Documentation", author, - "AriesCloudAgentPython", - "A Hyperledger Aries cloud agent implemented in Python and\ + "ACA-Py", + "A Decentralized Trust Agent implemented in Python and\ suitable for use in (almost) any non-mobile environment.", "Miscellaneous", ) diff --git a/docs/demo/Aries-Workshop.md b/docs/demo/ACA-Py-Workshop.md similarity index 95% rename from docs/demo/Aries-Workshop.md rename to docs/demo/ACA-Py-Workshop.md index e972fd76da..c7bc397a41 100644 --- a/docs/demo/Aries-Workshop.md +++ b/docs/demo/ACA-Py-Workshop.md @@ -1,4 +1,4 @@ -# A Hyperledger Aries/AnonCreds Workshop Using Traction Sandbox +# ACA-Py and AnonCreds Workshop Using Traction Sandbox ## Introduction @@ -9,15 +9,15 @@ walk through the steps exactly as laid out, it only takes about 20 minutes to complete the whole process. Of course, we hope you get curious, experiment, and learn a lot more about the information provided in the labs. -To run the labs, you’ll need a Hyperledger Aries agent to be able to issue and +To run the labs, you’ll need an ACA-Py agent to be able to issue and verify verifiable credentials. For that, we're providing your with your very own tenant in a BC Gov "**sandbox**" deployment of an open source tool called -[Traction], a managed, production-ready, multi-tenant Aries agent built on -[Hyperledger Aries Cloud Agent Python] (ACA-Py). *Sandbox* in this context means +[Traction], a managed, production-ready, multi-tenant decentralized trust agent built on +[ACA-Py]. *Sandbox* in this context means that you can do whatever you want with your tenant agent, but we make no promises about the stability of the environment (but it’s pretty robust, so chances are, things will work...), **and on the 1st and 15th of each month, -we’ll reset the entire sandbox and all your work will be gone — poof!** Keep +we’ll reset the entire sandbox and all your work will be gone — poof! **Keep that in mind, as you use the Traction sandbox. We recommend you keep a notebook at your side, tracking the important learnings you want to remember. As you create code that uses your sandbox agent make sure you create simple-to-update @@ -36,7 +36,7 @@ Once you are done the labs, there are [suggestions](#whats-next) for next steps for developers, such as experimenting with the Traction/ACA-Py [Traction]: https://digital.gov.bc.ca/digital-trust/technical-resources/traction/ -[Hyperledger Aries Cloud Agent Python]: https://aca-py.org +[ACA-Py]: https://aca-py.org [Traction Sandbox]: https://traction-sandbox-tenant-ui.apps.silver.devops.gov.bc.ca/ [BCovrin Test Ledger]: http://test.bcovrin.vonx.io/ [Traction Sandbox Workshop FAQ and Questions]: https://github.com/bcgov/traction/issues/927 @@ -226,7 +226,7 @@ environments. Contributions back to the project are always welcome! ### What’s Next: The ACA-Py OpenAPI -Are you going to build an app that uses Traction or an instance of the [Aries Cloud Agent Python](https://aca-py.org/) (ACA-Py)? If so, your next step is to try out the ACA-Py OpenAPI (aka Swagger)—by hand at first, and then from your application. This is a VERY high level overview, assuming a developer is following this, and knows a bunch about Aries protocols, using HTTP APIs, and using OpenAPI interfaces. +Are you going to build an app that uses Traction or an instance of [ACA-Py](https://aca-py.org/)? If so, your next step is to try out the ACA-Py OpenAPI (aka Swagger)—by hand at first, and then from your application. This is a VERY high level overview, assuming a developer is following this, and knows a bunch about Aries protocols, using HTTP APIs, and using OpenAPI interfaces. To access and use your Tenant's OpenAPI (aka Swagger) interface: @@ -252,7 +252,7 @@ invoking the right sequence of OpenAPI calls. ### What's Next: Experiment With an Issuer Web App -If you are challenged to use Traction or [Aries Cloud Agent Python] to become an +If you are challenged to use Traction or [ACA-Py] to become an issuer, you will likely be building API calls into your Line of Business web application. To get an idea of what that will entail, we're delighted to direct you to a very simple Web App that one of your predecessors on this same journey @@ -262,4 +262,4 @@ yourself, with your Sandbox tenant. Once you review the code, you should have an excellent idea of how you can add these same capabilities to your line of business application. -[Traction Issuance Demo]: https://github.com/hyperledger/aries-acapy-controllers/tree/main/TractionIssuanceDemo +[Traction Issuance Demo]: https://github.com/openwallet-foundation/acapy-controllers/tree/main/TractionIssuanceDemo diff --git a/docs/demo/AcmeDemoWorkshop.md b/docs/demo/AcmeDemoWorkshop.md index d02dc22b7e..d137114bf4 100644 --- a/docs/demo/AcmeDemoWorkshop.md +++ b/docs/demo/AcmeDemoWorkshop.md @@ -15,8 +15,8 @@ To run the Acme controller template, first run Alice and Faber so that Alice can Open 2 bash shells, and in each run: ```bash -git clone https://github.com/hyperledger/aries-cloudagent-python.git -cd aries-cloudagent-python/demo +git clone https://github.com/openwallet-foundation/acapy.git +cd acapy/demo ``` In one shell run Faber: diff --git a/docs/demo/AliceGetsAPhone.md b/docs/demo/AliceGetsAPhone.md index 59fedb108a..21796673d8 100644 --- a/docs/demo/AliceGetsAPhone.md +++ b/docs/demo/AliceGetsAPhone.md @@ -44,8 +44,8 @@ Of course for this, you need to have a mobile agent. To find, install and setup Open a new bash shell and in a project directory run the following: ```bash -git clone https://github.com/hyperledger/aries-cloudagent-python.git -cd aries-cloudagent-python/demo +git clone https://github.com/openwallet-foundation/acapy.git +cd acapy/demo ``` We'll come back to this in a minute, when we start the `faber` agent! @@ -94,8 +94,8 @@ To run the necessary terminal sessions in your browser, go to the Docker playgro Open a new bash shell and in a project directory run the following: ```bash -git clone https://github.com/hyperledger/aries-cloudagent-python.git -cd aries-cloudagent-python/demo +git clone https://github.com/openwallet-foundation/acapy.git +cd acapy/demo ``` We'll come back to this in a minute, when we start the `faber` agent! @@ -139,7 +139,7 @@ Note that with _Play with Docker_ it can be challenging to capture the informati #### Running locally in a bash shell? If you are running in a _local bash shell_, navigate to the `demo` directory in -your fork/clone of the Aries Cloud Agent Python repository and run: +your fork/clone of the ACA-Py repository and run: ```bash TAILS_NETWORK=docker_tails-server LEDGER_URL=http://test.bcovrin.vonx.io ./run_demo faber --aip 10 --revocation --events @@ -152,7 +152,7 @@ The `TAILS_NETWORK` parameter lets the demo script know how to connect to the ta #### Running in Play with Docker? If you are running in _Play with Docker_, navigate to the `demo` folder in the -clone of Aries Cloud Agent Python and run the following: +clone of ACA-Py and run the following: ```bash PUBLIC_TAILS_URL=https://c4f7fbb85911.ngrok.io LEDGER_URL=http://test.bcovrin.vonx.io ./run_demo faber --aip 10 --revocation --events diff --git a/docs/demo/AliceWantsAJsonCredential.md b/docs/demo/AliceWantsAJsonCredential.md index 644e287dd0..f2a5fb332d 100644 --- a/docs/demo/AliceWantsAJsonCredential.md +++ b/docs/demo/AliceWantsAJsonCredential.md @@ -9,8 +9,8 @@ The JSON-LD support is documented [here](../features/JsonLdCredentials.md) - thi Clone this repository to a directory on your local: ```bash -git clone https://github.com/hyperledger/aries-cloudagent-python.git -cd aries-cloudagent-python/demo +git clone https://github.com/openwallet-foundation/acapy.git +cd acapy/demo ``` Open up a second shell (so you have 2 shells open in the `demo` directory) and in one shell: diff --git a/docs/demo/Endorser.md b/docs/demo/Endorser.md index c29798180a..fc84594fb2 100644 --- a/docs/demo/Endorser.md +++ b/docs/demo/Endorser.md @@ -9,7 +9,7 @@ This approach runs Faber as an un-privileged agent, and starts a dedicated Endor Start a VON Network instance and a Tails server: - Following the [Building and Starting](https://github.com/bcgov/von-network/blob/main/docs/UsingVONNetwork.md#building-and-starting) section of the VON Network Tutorial to get ledger started. You can leave off the `--logs` option if you want to use the same terminal for running both VON Network and the Tails server. When you are finished with VON Network, follow the [Stopping And Removing a VON Network](https://github.com/bcgov/von-network/blob/main/docs/UsingVONNetwork.md#stopping-and-removing-a-von-network) instructions. -- Run an AnonCreds revocation registry tails server in order to support revocation by following the instructions in the [Alice gets a Phone](https://github.com/hyperledger/aries-cloudagent-python/blob/master/demo/AliceGetsAPhone.md#run-an-instance-of-indy-tails-server) demo. +- Run an AnonCreds revocation registry tails server in order to support revocation by following the instructions in the [Alice gets a Phone](https://github.com/openwallet-foundation/acapy/blob/master/demo/AliceGetsAPhone.md#run-an-instance-of-indy-tails-server) demo. Start up Faber as Author (note the tails file size override, to allow testing of the revocation registry roll-over): diff --git a/docs/demo/AriesOpenAPIDemo.md b/docs/demo/OpenAPIDemo.md similarity index 99% rename from docs/demo/AriesOpenAPIDemo.md rename to docs/demo/OpenAPIDemo.md index b43bb72737..4778b0f06a 100644 --- a/docs/demo/AriesOpenAPIDemo.md +++ b/docs/demo/OpenAPIDemo.md @@ -69,8 +69,8 @@ To run the necessary terminal sessions in your browser, go to the Docker playgro In a browser, go to the [Play with Docker](https://labs.play-with-docker.com/) home page, Login (if necessary) and click "Start." On the next screen, click (in the left menu) "+Add a new instance." That will start up a terminal in your browser. Run the following commands to start the Faber agent. ```bash -git clone https://github.com/hyperledger/aries-cloudagent-python -cd aries-cloudagent-python/demo +git clone https://github.com/openwallet-foundation/acapy +cd acapy/demo LEDGER_URL=http://test.bcovrin.vonx.io ./run_demo faber --events --no-auto --bg ``` @@ -97,8 +97,8 @@ Once the Faber agent has started up (with the invite displayed), click the link Now to start Alice's agent. Click the "+Add a new instance" button again to open another terminal session. Run the following commands to start Alice's agent: ```bash -git clone https://github.com/hyperledger/aries-cloudagent-python -cd aries-cloudagent-python/demo +git clone https://github.com/openwallet-foundation/acapy +cd acapy/demo LEDGER_URL=http://test.bcovrin.vonx.io ./run_demo alice --events --no-auto --bg ``` @@ -135,8 +135,8 @@ To begin running the demo in Docker, open up two terminal windows, one each for In the first terminal window, clone the ACA-Py repo, change into the demo folder and start the Faber agent: ```bash -git clone https://github.com/hyperledger/aries-cloudagent-python -cd aries-cloudagent-python/demo +git clone https://github.com/openwallet-foundation/acapy +cd acapy/demo LEDGER_URL=http://test.bcovrin.vonx.io ./run_demo faber --events --no-auto --bg ``` diff --git a/docs/demo/AriesPostmanDemo.md b/docs/demo/PostmanDemo.md similarity index 90% rename from docs/demo/AriesPostmanDemo.md rename to docs/demo/PostmanDemo.md index 03fccec7d2..40c74e5773 100644 --- a/docs/demo/AriesPostmanDemo.md +++ b/docs/demo/PostmanDemo.md @@ -32,7 +32,7 @@ Create a new postman workspace labeled "acapy-demo". ### Importing the environment -In the environment tab from the left, click the import button. You can paste this [link](https://raw.githubusercontent.com/hyperledger/aries-cloudagent-python/main/demo/postman/environment.json) which is the [environment file](https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/postman/environment.json) in the ACA-Py repository. +In the environment tab from the left, click the import button. You can paste this [link](https://raw.githubusercontent.com/openwallet-foundation/acapy/main/demo/postman/environment.json) which is the [environment file](https://github.com/openwallet-foundation/acapy/blob/main/demo/postman/environment.json) in the ACA-Py repository. Make sure you have the environment set as your active environment. @@ -42,7 +42,7 @@ In the collections tab from the left, click the import button. The following collections are available: -- [vc-api](https://raw.githubusercontent.com/hyperledger/aries-cloudagent-python/main/demo/postman/collections/vc-api.json) +- [vc-api](https://raw.githubusercontent.com/openwallet-foundation/acapy/main/demo/postman/collections/vc-api.json) ### Postman basics diff --git a/docs/demo/README.md b/docs/demo/README.md index 6b4ccc71f5..91ad52af90 100644 --- a/docs/demo/README.md +++ b/docs/demo/README.md @@ -1,4 +1,4 @@ -# Aries Cloud Agent Python (ACA-Py) Demos +# ACA-Py Demos There are several demos available for ACA-Py mostly (but not only) aimed at developers learning how to deploy an instance of the agent and an ACA-Py controller to implement an application. @@ -21,7 +21,6 @@ There are several demos available for ACA-Py mostly (but not only) aimed at deve - [Revocation](#revocation) - [DID Exchange](#did-exchange) - [Endorser](#endorser) - - [Run Indy-SDK Backend](#run-indy-sdk-backend) - [Mediation](#mediation) - [Multi-ledger](#multi-ledger) - [Multi-tenancy](#multi-tenancy) @@ -41,16 +40,16 @@ The Alice/Faber demo is the (in)famous first verifiable credentials demo. Alice, In your browser, go to the docker playground service [Play with Docker](https://labs.play-with-docker.com/). On the title screen, click "Start". On the next screen, click (in the left menu) "+Add a new instance". That will start up a terminal in your browser. Run the following commands to start the Faber agent: ```bash -git clone https://github.com/hyperledger/aries-cloudagent-python -cd aries-cloudagent-python/demo +git clone https://github.com/openwallet-foundation/acapy +cd acapy/demo LEDGER_URL=http://test.bcovrin.vonx.io ./run_demo faber ``` Now to start Alice's agent. Click the "+Add a new instance" button again to open another terminal session. Run the following commands to start Alice's agent: ```bash -git clone https://github.com/hyperledger/aries-cloudagent-python -cd aries-cloudagent-python/demo +git clone https://github.com/openwallet-foundation/acapy +cd acapy/demo LEDGER_URL=http://test.bcovrin.vonx.io ./run_demo alice ``` @@ -67,13 +66,13 @@ Open three `bash` shells. For Windows users, `git-bash` is highly recommended. b In the first terminal window, start `von-network` by following the [Building and Starting](https://github.com/bcgov/von-network/blob/main/docs/UsingVONNetwork.md#building-and-starting) instructions. -In the second terminal, change directory into `demo` directory of your clone of the Aries Cloud Agent Python repository. Start the `faber` agent by issuing the following command: +In the second terminal, change directory into `demo` directory of your clone of the ACA-Py repository. Start the `faber` agent by issuing the following command: ``` bash ./run_demo faber ``` -In the third terminal, change directory into `demo` directory of your clone of the Aries Cloud Agent Python repository. Start the `alice` agent by issuing the following command: +In the third terminal, change directory into `demo` directory of your clone of the ACA-Py repository. Start the `alice` agent by issuing the following command: ``` bash ./run_demo alice @@ -279,14 +278,6 @@ With DID Exchange, you can also enable use of the inviter's public DID for invit This is described in [Endorser.md](Endorser.md) -### Run Indy-SDK Backend - -This runs using the older (and not recommended) indy-sdk libraries instead of [Aries Askar](https://github.com/hyperledger/aries-ask): - -```bash -./run_demo faber --wallet-type indy -``` - ### Mediation To enable mediation, run the `alice` or `faber` demo with the `--mediation` option: @@ -386,15 +377,15 @@ You can inspect the additional multi-tenancy admin API's (i.e. the "agency API" Note that with multi-tenancy enabled: - The "base" wallet will have access to this new "agency API" - the agent's admin key, if enabled, must be provided in a header -- "Base wallet" API calls are handled [here](https://github.com/hyperledger/aries-cloudagent-python/blob/244194e68330835e5e2e53cc6c2993899d2437fb/demo/runners/support/agent.py#L606) -- The "sub-wallets" will have access to the "normal" ACA-Py admin API - to identify the sub-wallet, a JWT token must be provided, this token is created upon creation of the new wallet (see: [this code here](https://github.com/hyperledger/aries-cloudagent-python/tree/main/demo/runners/support/agent.py#L378)) -- "Sub-wallet" API calls are handled [here](https://github.com/hyperledger/aries-cloudagent-python/blob/244194e68330835e5e2e53cc6c2993899d2437fb/demo/runners/support/agent.py#L632) +- "Base wallet" API calls are handled [here](https://github.com/openwallet-foundation/acapy/blob/244194e68330835e5e2e53cc6c2993899d2437fb/demo/runners/support/agent.py#L606) +- The "sub-wallets" will have access to the "normal" ACA-Py admin API - to identify the sub-wallet, a JWT token must be provided, this token is created upon creation of the new wallet (see: [this code here](https://github.com/openwallet-foundation/acapy/tree/main/demo/runners/support/agent.py#L378)) +- "Sub-wallet" API calls are handled [here](https://github.com/openwallet-foundation/acapy/blob/244194e68330835e5e2e53cc6c2993899d2437fb/demo/runners/support/agent.py#L632) -Documentation on ACA-Py's multi-tenancy support can be found [here](https://github.com/hyperledger/aries-cloudagent-python/blob/master/Multitenancy.md). +Documentation on ACA-Py's multi-tenancy support can be found [here](https://github.com/openwallet-foundation/acapy/blob/main/docs/features/Multitenancy.md). ### Multi-tenancy *with Mediation*!!! -There are two options for configuring mediation with multi-tenancy, documented [here](https://github.com/hyperledger/aries-cloudagent-python/blob/master/Multitenancy.md#mediation). +There are two options for configuring mediation with multi-tenancy, documented [here](https://github.com/openwallet-foundation/acapy/blob/main/docs/features/Multitenancy.md#mediation). This demo implements option #2 - each sub-wallet is configured with a separate connection to the mediator. @@ -440,15 +431,15 @@ Run Command: These Alice and Faber scripts (in the `demo/runners` folder) implement the controller and run the agent as a sub-process (see the documentation for `aca-py`). The controller publishes a REST service to receive web hook callbacks from their agent. Note that this architecture, running the agent as a sub-process, is a variation on the documented architecture of running the controller and agent as separate processes/containers. -The controllers for this demo can be found in the [alice.py](https://github.com/hyperledger/aries-cloudagent-python/tree/main/demo/runners/alice.py) and [faber.py](https://github.com/hyperledger/aries-cloudagent-python/tree/main/demo/runners/faber.py) files. Alice and Faber are instances of the agent class found in [agent.py](https://github.com/hyperledger/aries-cloudagent-python/tree/main/demo/runners/support/agent.py). +The controllers for this demo can be found in the [alice.py](https://github.com/openwallet-foundation/acapy/tree/main/demo/runners/alice.py) and [faber.py](https://github.com/openwallet-foundation/acapy/tree/main/demo/runners/faber.py) files. Alice and Faber are instances of the agent class found in [agent.py](https://github.com/openwallet-foundation/acapy/tree/main/demo/runners/support/agent.py). ## OpenAPI (Swagger) Demo -Developing an ACA-Py controller is much like developing a web app that uses a REST API. As you develop, you will want an easy way to test out the behaviour of the API. That's where the industry-standard OpenAPI (aka Swagger) UI comes in. ACA-Py (optionally) exposes an OpenAPI UI in ACA-Py that you can use to learn the ins and outs of the API. This [Aries OpenAPI demo](AriesOpenAPIDemo.md) shows how you can use the OpenAPI UI with an ACA-Py agent by walking through the connecting, issuing a credential, and presenting a proof sequence. +Developing an ACA-Py controller is much like developing a web app that uses a REST API. As you develop, you will want an easy way to test out the behaviour of the API. That's where the industry-standard OpenAPI (aka Swagger) UI comes in. ACA-Py (optionally) exposes an OpenAPI UI in ACA-Py that you can use to learn the ins and outs of the API. This [ACA-Py OpenAPI demo](OpenAPIDemo.md) shows how you can use the OpenAPI UI with an ACA-Py agent by walking through the connecting, issuing a credential, and presenting a proof sequence. ## Performance Demo -Another example in the `demo/runners` folder is [performance.py](https://github.com/hyperledger/aries-cloudagent-python/tree/main/demo/runners/performance.py), that is used to test out the performance of interacting agents. The script starts up agents for Alice and Faber, initializes them, and then runs through an interaction some number of times. In this case, Faber issues a credential to Alice 300 times. +Another example in the `demo/runners` folder is [performance.py](https://github.com/openwallet-foundation/acapy/tree/main/demo/runners/performance.py), that is used to test out the performance of interacting agents. The script starts up agents for Alice and Faber, initializes them, and then runs through an interaction some number of times. In this case, Faber issues a credential to Alice 300 times. To run the demo, make sure that you shut down any running Alice/Faber agents. Then, follow the same steps to start the Alice/Faber demo, but: @@ -489,7 +480,7 @@ Now that you have a solid foundation in using ACA-Py, time for a coding challeng * ACME requesting a proof of her College degree * ACME issuing Alice a credential after she is hired. -The framework for the code is in the [acme.py](https://github.com/hyperledger/aries-cloudagent-python/tree/main/demo/runners/acme.py) file, but the code is incomplete. Using the knowledge you gained from running demo and viewing the alice.py and faber.py code, fill in the blanks for the code. When you are ready to test your work: +The framework for the code is in the [acme.py](https://github.com/openwallet-foundation/acapy/tree/main/demo/runners/acme.py) file, but the code is incomplete. Using the knowledge you gained from running demo and viewing the alice.py and faber.py code, fill in the blanks for the code. When you are ready to test your work: * Use the instructions above to start the Alice/Faber demo (above). * Start another terminal session and run the same commands as for "Alice", but replace "alice" with "acme". diff --git a/docs/deploying/AnonCredsWalletType.md b/docs/deploying/AnonCredsWalletType.md index 9c8dac8817..e7de807989 100644 --- a/docs/deploying/AnonCredsWalletType.md +++ b/docs/deploying/AnonCredsWalletType.md @@ -8,7 +8,7 @@ A new wallet type has been added to Aca-Py to support the new anoncreds-rs libra When Aca-Py is run with this wallet type it will run with an Askar format wallet (and askar libraries) but will use `anoncreds-rs` instead of `credx`. -There is a new package under `aries_cloudagent/anoncreds` with code that supports the new library. +There is a new package under `acapy_agent/anoncreds` with code that supports the new library. There are new endpoints (under `/anoncreds`) for managing schemas, cred defs and revocation objects. However the new anoncreds code is integrated into the existing Credential and Presentation endpoints (V2.0 endpoints only). @@ -17,17 +17,17 @@ Within the protocols, there are new `handler` libraries to support the new `anon The existing `indy` code are in: ```bash -aries_cloudagent/protocols/issue_credential/v2_0/formats/indy/handler.py -aries_cloudagent/protocols/indy/anoncreds/pres_exch_handler.py -aries_cloudagent/protocols/present_proof/v2_0/formats/indy/handler.py +acapy_agent/protocols/issue_credential/v2_0/formats/indy/handler.py +acapy_agent/protocols/indy/anoncreds/pres_exch_handler.py +acapy_agent/protocols/present_proof/v2_0/formats/indy/handler.py ``` The new `anoncreds` code is in: ```bash -aries_cloudagent/protocols/issue_credential/v2_0/formats/anoncreds/handler.py -aries_cloudagent/protocols/present_proof/anoncreds/pres_exch_handler.py -aries_cloudagent/protocols/present_proof/v2_0/formats/anoncreds/handler.py +acapy_agent/protocols/issue_credential/v2_0/formats/anoncreds/handler.py +acapy_agent/protocols/present_proof/anoncreds/pres_exch_handler.py +acapy_agent/protocols/present_proof/v2_0/formats/anoncreds/handler.py ``` The Indy handler checks to see if the wallet type is `askar-anoncreds` and if so delegates the calls to the anoncreds handler, for example: @@ -74,7 +74,7 @@ The changes are significant. Notably: The Tails File changes are minimal -- nothing about the file itself changed. What changed: - the tails-file-server can be published to WITHOUT knowing the ID of the RevRegEntry, since that is not known when the tails file is generated/published. See: [https://github.com/bcgov/indy-tails-server/pull/53](https://github.com/bcgov/indy-tails-server/pull/53) -- basically, by publishing based on the hash. -- The tails-file is not needed by the issuer after generation. It used to be needed for issuing and revoking credentials. Those are now done without the tails file. See: [https://github.com/hyperledger/aries-cloudagent-python/pull/2302/files](https://github.com/hyperledger/aries-cloudagent-python/pull/2302/files). That code is already in Main, so you should have it. +- The tails-file is not needed by the issuer after generation. It used to be needed for issuing and revoking credentials. Those are now done without the tails file. See: [https://github.com/openwallet-foundation/acapy/pull/2302/files](https://github.com/openwallet-foundation/acapy/pull/2302/files). That code is already in Main, so you should have it. ## Outstanding work @@ -86,8 +86,8 @@ The Tails File changes are minimal -- nothing about the file itself changed. Wh The main changes for the Credential and Presentation support are in the following two files: ```bash -aries_cloudagent/protocols/issue_credential/v2_0/messages/cred_format.py -aries_cloudagent/protocols/present_proof/v2_0/messages/pres_format.py +acapy_agent/protocols/issue_credential/v2_0/messages/cred_format.py +acapy_agent/protocols/present_proof/v2_0/messages/pres_format.py ``` The `INDY` handler just need to be re-pointed to the new anoncreds handler, and then all the old Indy code can be retired. @@ -99,7 +99,7 @@ The new code is already in place (in comments). For example for the Credential INDY = FormatSpec( "hlindy/", DeferLoad( - "aries_cloudagent.protocols.present_proof.v2_0" + "acapy_agent.protocols.present_proof.v2_0" ".formats.anoncreds.handler.AnonCredsPresExchangeHandler" ), ) diff --git a/docs/deploying/ContainerImagesAndGithubActions.md b/docs/deploying/ContainerImagesAndGithubActions.md index 91e96c8d37..1db5f8ccb7 100644 --- a/docs/deploying/ContainerImagesAndGithubActions.md +++ b/docs/deploying/ContainerImagesAndGithubActions.md @@ -1,21 +1,21 @@ # Container Images and Github Actions -Aries Cloud Agent - Python is most frequently deployed using containers. From +ACA-Py is most frequently deployed using containers. From the first release of ACA-Py up through 0.7.4, much of the community has built -their Aries stack using the container images graciously provided by BC Gov and +their deployments using the container images graciously provided by BC Gov and hosted through their `bcgovimages` docker hub account. These images have been -critical to the adoption of not only ACA-Py but also Hyperledger Aries and SSI +critical to the adoption of not only ACA-Py but also decentralized trust/SSI more generally. Recognizing how critical these images are to the success of ACA-Py and -consistent with Hyperledger's commitment to open collaboration, container images +consistent with the OpenWallet Foundation's commitment to open collaboration, container images are now built and published directly from the Aries Cloud Agent - Python project repository and made available through the [Github Packages Container Registry](https://ghcr.io). ## Image -This project builds and publishes the `ghcr.io/hyperledger/aries-cloudagent-python` image. +This project builds and publishes the `ghcr.io/openwallet-foundation/acapy` image. Multiple variants are available; see [Tags](#tags). ### Tags @@ -27,7 +27,7 @@ of environments and workflows. The following variants exist: - "Standard" - The default configuration of ACA-Py, including: - Aries Askar for secure storage - Indy VDR for Indy ledger communication - - Indy Shared Libraries for AnonCreds + - AnonCreds Rust for AnonCreds In the past, two image variants were published. These two variants are largely distinguished by providers for Indy Network and AnonCreds support. The Standard @@ -91,7 +91,7 @@ variants and between the BC Gov ACA-Py images. when manually triggered; builds and pushes the Standard ACA-Py variant to the Github Container Registry. - BDD Integration Tests (`.github/workflows/BDDTests.yml`) - Run on pull - requests (to the hyperledger fork only); runs BDD integration tests. + requests (to the openwallet-foundation fork only); runs BDD integration tests. - Format (`.github/workflows/format.yml`) - Run on pull requests; checks formatting of files modified by the PR. - CodeQL (`.github/workflows/codeql.yml`) - Run on pull requests; performs diff --git a/docs/deploying/Databases.md b/docs/deploying/Databases.md index c54deebbb0..af33e710e2 100644 --- a/docs/deploying/Databases.md +++ b/docs/deploying/Databases.md @@ -6,7 +6,7 @@ The wallet supports 2 different databases to store data, SQLite and PostgreSQL. ## SQLite -If the wallet is configured the default way in eg. [demo-args.yaml](https://github.com/hyperledger/aries-cloudagent-python/tree/main/demo/demo-args.yaml), without explicit wallet-storage, a sqlite database file is used. +If the wallet is configured the default way in eg. [demo-args.yaml](https://github.com/openwallet-foundation/acapy/tree/main/demo/demo-args.yaml), without explicit wallet-storage, a sqlite database file is used. ```yaml # demo-args.yaml diff --git a/docs/deploying/IndySDKtoAskarMigration.md b/docs/deploying/IndySDKtoAskarMigration.md index a95d8729b9..236209fee5 100644 --- a/docs/deploying/IndySDKtoAskarMigration.md +++ b/docs/deploying/IndySDKtoAskarMigration.md @@ -99,13 +99,13 @@ with the Indy SDK. Switch to Aries Askar to eliminate that warning. If you have an existing deployment, in changing the `--wallet-type` configuration setting, your database must be migrated from the Indy SDK format to Aries Askar format. In order to facilitate the migration, an Indy SDK to -Askar migration script has been published in the [aries-acapy-tools] repository. +Askar migration script has been published in the [acapy-tools] repository. There is lots of information in that repository about the migration tool and how to use it. The following is a summary of the steps you will have to perform. Of course, all deployments are a little (or a lot!) different, and your exact steps will be dependent on where and how you have deployed ACA-Py. -[aries-acapy-tools]: https://github.com/hyperledger/aries-acapy-tools +[acapy-tools]: https://github.com/openwallet-foundation/acapy-tools Note that in these steps you will have to take your ACA-Py instance offline, so scheduling the maintenance must be a part of your migration plan. You will also @@ -117,7 +117,7 @@ through these steps before upgrading your production deployment. As well, it is good if you can make a copy of your production database and test the migration on the real (copy) database before the actual upgrade. -* Prepare a way to run the Askar Upgrade script from the [aries-acapy-tools] +* Prepare a way to run the Askar Upgrade script from the [acapy-tools] repository. For example, you might want to prepare a container that you can run in the same environment that you run ACA-Py (e.g., within Kubernetes or OpenShift). @@ -155,8 +155,8 @@ about 7 minutes. The entire app downtime was less than 20 minutes. ## Questions? If you have questions, comments, or suggestions about the upgrade process, -please use the Aries Cloud Agent Python channel on [Hyperledger Discord], or +please use the ACA-Py channel on [OpenWallet Foundation Discord], or submit a [GitHub issue to the ACA-Py repository]. -[Hyperledger Discord]: https://discord.gg/hyperledger -[GitHub issue to the ACA-Py repository]: https://github.com/hyperledger/aries-cloudagent-python/issues +[OpenWallet Foundation Discord]: https://discord.gg/openwallet-foundation +[GitHub issue to the ACA-Py repository]: https://github.com/openwallet-foundation/acapy/issues diff --git a/docs/deploying/RedisPlugins.md b/docs/deploying/RedisPlugins.md index e3428a1238..51ddd59f33 100644 --- a/docs/deploying/RedisPlugins.md +++ b/docs/deploying/RedisPlugins.md @@ -1,11 +1,11 @@ # ACA-Py Redis Plugins -## [aries-acapy-plugin-redis-events](https://github.com/hyperledger/aries-acapy-plugins/blob/main/redis_events/README.md) `redis_queue` +## [acapy-plugin-redis-events](https://github.com/openwallet-foundation/acapy-plugins/blob/main/redis_events/README.md) `redis_queue` - + It provides a mechanism to persists both inbound and outbound messages using redis, deliver messages and webhooks, and dispatch events. -More details can be found [here](https://github.com/hyperledger/aries-acapy-plugins/blob/main/redis_events/README.md). +More details can be found [here](https://github.com/openwallet-foundation/acapy-plugins/blob/main/redis_events/README.md). ### Redis Queue configuration `yaml` @@ -67,20 +67,20 @@ redis_queue: #### Redis Plugin With Docker Running the plugin with docker is simple. An -example [docker-compose.yml](https://github.com/hyperledger/aries-acapy-plugins/blob/main/redis_events/docker/docker-compose.yml) file is available which launches both ACA-Py with redis and an accompanying Redis cluster. +example [docker-compose.yml](https://github.com/openwallet-foundation/acapy-plugins/blob/main/redis_events/docker/docker-compose.yml) file is available which launches both ACA-Py with redis and an accompanying Redis cluster. ```sh docker-compose up --build -d ``` -More details can be found [here](https://github.com/hyperledger/aries-acapy-plugins/blob/main/redis_events/README.md). +More details can be found [here](https://github.com/openwallet-foundation/acapy-plugins/blob/main/redis_events/README.md). #### Without Docker Installation ```bash -pip install git+https://github.com/bcgov/aries-acapy-plugin-redis-events.git +pip install git+https://github.com/openwallet-foundation/acapy-plugins.git ``` Startup ACA-Py with `redis_queue` plugin loaded @@ -204,7 +204,7 @@ Regardless of the options above, you will need to startup `deliverer` and `relay Both relay and mediator [demos](https://github.com/bcgov/aries-acapy-plugin-redis-events/tree/master/demo) are also available. -## [aries-acapy-cache-redis](https://github.com/Indicio-tech/aries-acapy-cache-redis/blob/main/README.md) `redis_cache` +## [acapy-cache-redis](https://github.com/Indicio-tech/aries-acapy-cache-redis/blob/main/README.md) `redis_cache` ACA-Py uses a modular cache layer to story key-value pairs of data. The purpose diff --git a/docs/deploying/UpgradingACA-Py.md b/docs/deploying/UpgradingACA-Py.md index 1b41c5e5d6..ed2f56a449 100644 --- a/docs/deploying/UpgradingACA-Py.md +++ b/docs/deploying/UpgradingACA-Py.md @@ -47,8 +47,8 @@ while offline, a new Upgrade feature will be added that will prevent the "auto upgrade" process from executing. See [Issue 2201] and [Pull Request 2204] for the status of that feature. -[Issue 2201]: https://github.com/hyperledger/aries-cloudagent-python/issues/2201 -[Pull Request 2204]: https://github.com/hyperledger/aries-cloudagent-python/pull/2204 +[Issue 2201]: https://github.com/openwallet-foundation/acapy/issues/2201 +[Pull Request 2204]: https://github.com/openwallet-foundation/acapy/pull/2204 Those deploying ACA-Py upgrades for production installations (forced offline or not) should check in each [CHANGELOG.md] release entry about what upgrades (if @@ -129,6 +129,6 @@ storage](#no-version-in-secure-storage)" handling, it is unlikely this capability will ever be needed. We expect to deprecate and remove these options in future (post-0.8.1) ACA-Py versions. -[CHANGELOG.md]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/CHANGELOG.md -[version.py]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/version.py -[Upgrade Definition YML file]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/commands/default_version_upgrade_config.yml +[CHANGELOG.md]: https://github.com/openwallet-foundation/acapy/blob/main/CHANGELOG.md +[version.py]: https://github.com/openwallet-foundation/acapy/blob/main/aries_cloudagent/version.py +[Upgrade Definition YML file]: https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/commands/default_version_upgrade_config.yml diff --git a/docs/deploying/deploymentModel.md b/docs/deploying/deploymentModel.md index 8d49bf80f4..49c5e4e5dc 100644 --- a/docs/deploying/deploymentModel.md +++ b/docs/deploying/deploymentModel.md @@ -1,11 +1,6 @@ - - -# Aries Cloud Agent-Python (ACA-Py) - Deployment Model - -This document is a "concept of operations" for an instance of an Aries cloud agent deployed from the primary artifact (a PyPi package) produced by this repo. In such a deployment there are **always** two components - a configured agent itself, and a controller that injects into that agent the business rules for the particular agent instance (see diagram). +This document is a "concept of operations" for an instance of an ACA-Py agent deployed from the primary artifact (a PyPi package) produced by this repo. In such a deployment there are **always** two components - a configured agent itself, and a controller that injects into that agent the business rules for the particular agent instance (see diagram). ![ACA-Py Deployment Overview](../assets/deploymentModel-full.png "ACA-Py Deployment Overview") @@ -19,49 +14,49 @@ Note: the ACA-Py agent is designed to be stateless, persisting connection and pr The sections below detail the internals of the ACA-Py and it's configurable elements, and the conceptual elements of a controller. There is no "Aries controller" repo to fork, as it is essentially just a web app. There are demos of using the elements in this repo, and several sample applications that you can use to get started on your on controller. -## Aries Cloud Agent +## ACA-Py -**Aries cloud agent** implement services to manage the execution of DIDComm messaging protocols for interacting with other DIDComm agents, and exposes an administrative HTTP API that supports a controller to direct how the agent should respond to messaging events. The agent relies on the controller to provide the business rules for handling the messaging events, and to initiate the execution of new DIDComm protocol instances. The internals of an ACA-Py instance is diagramed below. +**ACA-Py** implement services to manage the execution of DIDComm messaging protocols for interacting with other DIDComm agents, and exposes an administrative HTTP API that supports a controller to direct how the agent should respond to messaging events. The agent relies on the controller to provide the business rules for handling the messaging events, and to initiate the execution of new DIDComm protocol instances. The internals of an ACA-Py instance is diagramed below. ![ACA-Py Agent Internals](../assets/deploymentModel-agent.png "ACA-Py Agent Internals") -Instances of the Aries cloud agents are configured with the following sub-components: +Instances of the ACA-Py agents are configured with the following sub-components: - **Transport Plugins** - pluggable transport-specific message sender/receiver modules that interact with other agents. Messages outside the plugins are transport-agnostic JSON structures. Current modules include HTTP and WebSockets. In the future, we might add ZMQ, SMTP and so on. - **Conductor** receives inbound messages from, and sends outbound messages to, the transport plugins. After internal processing, the conductor passes inbound messages to, and receives outbound messages from, the Dispatcher. In processing the messages, the conductor manages the message’s protocol instance thread state, retrieving the state on inbound messages and saving the state on outbound messages. The conductor handles generic decorators in messages such as verifying and generating signatures on message data elements, internationalization and so on. -- **Dispatcher** handles the distribution of messages to the DIDComm protocol message handlers and the responses received. The dispatcher passes to the conductor the thread state to be persistance and message data (if any) to be sent out from the Aries cloud agent instance. +- **Dispatcher** handles the distribution of messages to the DIDComm protocol message handlers and the responses received. The dispatcher passes to the conductor the thread state to be persistance and message data (if any) to be sent out from the ACA-Py agent instance. - **DIDComm Protocols** - implement the DIDComm protocols supported by the agent instance, including the state object for the protocol, the DIDComm message handlers and the admin message handlers. Protocols are bundled as Python modules and loaded for during the agent deployment. Each protocol contributes the admin messages for the protocol to the controller REST interface. The protocols implement a number of events that invoke the controller via webhooks so that controller’s business logic can respond to the event. -- **Controller REST API** - a dynamically generated REST API (with a Swagger/OpenAPI user interface) based on the set of DIDComm protocols included in the agent deployment. The controller, activated via the webhooks from the protocol DIDComm message handlers, controls the Aries cloud agent by calling the REST API that invoke the protocol admin message handlers. -- **Handler API** - provides abstract interfaces to various handlers needed by the protocols and core Aries cloud agent components for accessing the secure storage (wallet), other storage, the ledger and so on. The API calls the handler implementations configured into the agent deployment. +- **Controller REST API** - a dynamically generated REST API (with a Swagger/OpenAPI user interface) based on the set of DIDComm protocols included in the agent deployment. The controller, activated via the webhooks from the protocol DIDComm message handlers, controls the ACA-Py agent by calling the REST API that invoke the protocol admin message handlers. +- **Handler API** - provides abstract interfaces to various handlers needed by the protocols and core ACA-Py agent components for accessing the secure storage (wallet), other storage, the ledger and so on. The API calls the handler implementations configured into the agent deployment. - **Handler Plugins** - are the handler implementations called from the Handler API. The plugins may be internal to the Agent (in the same process space) or could be external (for example, in other processes/containers). -- **Secure Storage Plugin** - the Indy SDK is embedded in the Aries cloud agent and implements the default secure storage. An Aries cloud agent can be configured to use one of a number of indy-sdk storage implementations - in-memory, SQLite and Postgres at this time. -- **Ledger Interface Plugin** - In the current Aries cloud agent implementation, the Indy SDK provides an interface to an Indy-based public ledger for verifiable credential protocols. In future, ledger implementations (including those other than Indy) might be moved into the DIDComm protocol modules to be included as needed within a configured Aries cloud agent instance based on the DIDComm protocols used by the agent. +- **Secure Storage Plugin** - the Indy SDK is embedded in the ACA-Py agent and implements the default secure storage. An ACA-Py agent can be configured to use one of a number of indy-sdk storage implementations - in-memory, SQLite and Postgres at this time. +- **Ledger Interface Plugin** - In the current ACA-Py agent implementation, the Indy SDK provides an interface to an Indy-based public ledger for verifiable credential protocols. In future, ledger implementations (including those other than Indy) might be moved into the DIDComm protocol modules to be included as needed within a configured ACA-Py agent instance based on the DIDComm protocols used by the agent. ## Controller -A controller provides the personality of Aries cloud agent instance - the business logic (human, machine or rules driven) that drive the behaviour of the agent. The controller’s “Business Logic” in a cloud agent could be built into the controller app, could be an integration back to an enterprise system, or even a user interface for an individual. In all cases, the business logic provide responses to agent events or initiates agent actions. A deployed controller talks to a single Aries cloud agent deployment and manages the configuration of that agent. Both can be configured and deployed to support horizontal scaling. +A controller provides the personality of ACA-Py agent instance - the business logic (human, machine or rules driven) that drive the behaviour of the agent. The controller’s “Business Logic” in a cloud agent could be built into the controller app, could be an integration back to an enterprise system, or even a user interface for an individual. In all cases, the business logic provide responses to agent events or initiates agent actions. A deployed controller talks to a single ACA-Py agent deployment and manages the configuration of that agent. Both can be configured and deployed to support horizontal scaling. ![Controller Internals](../assets/deploymentModel-controller.png "Controller Internals") -Generically, a controller is a web app invoked by HTTP webhook calls from its corresponding Aries cloud agent and invoking the DIDComm administration capabilities of the Aries cloud agent by calling the REST API exposed by that cloud agent. As well as responding to Aries cloud agent events, the controller initiates DIDComm protocol instances using the same REST API. +Generically, a controller is a web app invoked by HTTP webhook calls from its corresponding ACA-Py agent and invoking the DIDComm administration capabilities of the ACA-Py agent by calling the REST API exposed by that cloud agent. As well as responding to ACA-Py agent events, the controller initiates DIDComm protocol instances using the same REST API. -The controller and Aries cloud agent deployment **MUST** secure the HTTP interface between the two components. The interface provides the same HTTP integration between services as modern apps found in any enterprise today, and must be correspondingly secured. +The controller and ACA-Py agent deployment **MUST** secure the HTTP interface between the two components. The interface provides the same HTTP integration between services as modern apps found in any enterprise today, and must be correspondingly secured. A controller implements the following capabilities. -- **Initiator** - provides a mechanism to initiate new DIDComm protocol instances. The initiator invokes the REST API exposed by the Aries cloud agent to initiate the creation of a DIDComm protocol instance. For example, a permit-issuing service uses this mechanism to issue a Verifiable Credential associated with the issuance of a new permit. -- **Responder** - subscribes to and responds to events from the Aries cloud agent protocol message handlers, providing business-driven responses. The responder might respond immediately, or the event might cause a delay while the decision is determined, perhaps by sending the request to a person to decide. The controller may persist the event response state if the event is asynchronous - for example, when the event is passed to a person who may respond when they next use the web app. -- **Configuration** - manages the controller configuration data and the configuration of the Aries cloud agent. Configuration in this context includes things like: - - Credentials and Proof Requests to be Issued/Verified (respectively) by the Aries cloud agent. +- **Initiator** - provides a mechanism to initiate new DIDComm protocol instances. The initiator invokes the REST API exposed by the ACA-Py agent to initiate the creation of a DIDComm protocol instance. For example, a permit-issuing service uses this mechanism to issue a Verifiable Credential associated with the issuance of a new permit. +- **Responder** - subscribes to and responds to events from the ACA-Py agent protocol message handlers, providing business-driven responses. The responder might respond immediately, or the event might cause a delay while the decision is determined, perhaps by sending the request to a person to decide. The controller may persist the event response state if the event is asynchronous - for example, when the event is passed to a person who may respond when they next use the web app. +- **Configuration** - manages the controller configuration data and the configuration of the ACA-Py agent. Configuration in this context includes things like: + - Credentials and Proof Requests to be Issued/Verified (respectively) by the ACA-Py agent. - The configuration of the webhook handler to which the responder subscribes. -While there are several examples of controllers, there is no “cookie cutter” repository to fork and customize. A controller is just a web service that receives HTTP requests (webhooks) and sends HTTP messages to the Aries cloud agent it controls via the REST API exposed by that agent. +While there are several examples of controllers, there is no “cookie cutter” repository to fork and customize. A controller is just a web service that receives HTTP requests (webhooks) and sends HTTP messages to the ACA-Py agent it controls via the REST API exposed by that agent. ## Deployment -The Aries cloud agent CI pipeline configured into the repository generates a PyPi package as an artifact. Implementers will generally have a controller repository, possibly copied from an existing controller instance, that has the code (business logic) for the controller and the configuration (transports, handlers, DIDComm protocols, etc.) for the Aries cloud agent instance. In the most common scenario, the Aries cloud agent and controller instances will be deployed based on the artifacts (e.g. container images) generated from that controller repository. With the simple HTTP-based interface between the controller and Aries cloud agent, both components can be horizontally scaled as needed, with a load balancer between the components. The configuration of the Aries cloud agent to use the Postgres wallet supports enterprise scale agent deployments. +The ACA-Py agent CI pipeline configured into the repository generates a PyPi package as an artifact. Implementers will generally have a controller repository, possibly copied from an existing controller instance, that has the code (business logic) for the controller and the configuration (transports, handlers, DIDComm protocols, etc.) for the ACA-Py agent instance. In the most common scenario, the ACA-Py agent and controller instances will be deployed based on the artifacts (e.g. container images) generated from that controller repository. With the simple HTTP-based interface between the controller and ACA-Py agent, both components can be horizontally scaled as needed, with a load balancer between the components. The configuration of the ACA-Py agent to use the Postgres wallet supports enterprise scale agent deployments. -Current examples of deployed instances of Aries cloud agent and controllers include: +Current examples of deployed instances of ACA-Py agent and controllers include: - [indy-email-verification](https://github.com/bcgov/indy-email-verification) - a web app Controller that sends an email to a given email address with an embedded DIDComm invitation and on establishment of a connection, offers and provides the connected agent with an email control verifiable credential. - [iiwbook](https://github.com/bcgov/iiwbook) - a web app Controller that on creation of a DIDComm connection, requests a proof of email control, and then sends to the connection a verifiable credential proving attendance at IIW. In between the proof and issuance is a human approval step using a simple web-based UI that implements a request queue. diff --git a/docs/design/AnoncredsW3CCompatibility.md b/docs/design/AnoncredsW3CCompatibility.md index 31a48c668d..10e247e474 100644 --- a/docs/design/AnoncredsW3CCompatibility.md +++ b/docs/design/AnoncredsW3CCompatibility.md @@ -1,6 +1,6 @@ -# Supporting AnonCreds in W3C VC/VP Formats in Aries Cloud Agent Python +# Supporting AnonCreds in W3C VC/VP Formats in ACA-Py -This design proposes to extend the Aries Cloud Agent Python (ACA-PY) to support Hyperledger AnonCreds credentials and presentations in the W3C Verifiable Credentials (VC) and Verifiable Presentations (VP) Format. The aim is to transition from the legacy AnonCreds format specified in Aries-Legacy-Method to the W3C VC format. +This design proposes to extend the ACA-PY to support Hyperledger AnonCreds credentials and presentations in the W3C Verifiable Credentials (VC) and Verifiable Presentations (VP) Format. The aim is to transition from the legacy AnonCreds format specified in Aries-Legacy-Method to the W3C VC format. ## Overview @@ -79,7 +79,7 @@ It appears that the issue and presentation sides can be approached independently 1. Update Admin API endpoints to initiate an Issue Credential v2.0 protocol to issue an AnonCreds credential in W3C VC format using [RFC 0809 VC-DI] format attachments. 2. Add support for the [RFC 0809 VC-DI] message attachment formats. - 1. Should the attachment format be made pluggable as part of this? From the maintainers: _If we did make it pluggable, [this](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/issue_credential/v2_0/messages/cred_format.py#L23) would be the point where that would take place. Since these values are hard coded, it is not pluggable currently, as noted. I've been dissatisfied with how this particular piece works for a while. I think making it pluggable, if done right, could help clean it up nicely. A plugin would then define their own implementation of [V20CredFormatHandler](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/issue_credential/v2_0/formats/handler.py#L28). (@dbluhm)_ + 1. Should the attachment format be made pluggable as part of this? From the maintainers: _If we did make it pluggable, [this](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/issue_credential/v2_0/messages/cred_format.py#L23) would be the point where that would take place. Since these values are hard coded, it is not pluggable currently, as noted. I've been dissatisfied with how this particular piece works for a while. I think making it pluggable, if done right, could help clean it up nicely. A plugin would then define their own implementation of [V20CredFormatHandler](https://github.com/openwallet-foundation/acapy/protocols/issue_credential/v2_0/formats/handler.py#L28). (@dbluhm)_ 3. Update the v2.0 Issue Credential protocol handler to support a "[RFC 0809 VC-DI] mode" such that when a protocol instance starts with that format, it continues with it until completion, supporting issuing AnonCreds credentials in the process. This includes both the sending and receiving of all protocol message types. #### Present Proof @@ -125,11 +125,11 @@ The classes modified according to the same [PR](https://github.com/hyperledger/a #### Creating a W3C VC credential from credential definition, and issuing and presenting it as is -The issuance, presentation and verification of legacy anoncreds are implemented in this [./aries_cloudagent/anoncreds](https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/anoncreds) directory. Therefore, we will also start from there. +The issuance, presentation and verification of legacy anoncreds are implemented in this [./acapy_agent/anoncreds](https://github.com/openwallet-foundation/acapy/tree/main/acapy_agent/anoncreds) directory. Therefore, we will also start from there. Let us navigate these implementation examples through the respective processes of the concerning agents - **Issuer** and **Holder** as described in [https://github.com/hyperledger/anoncreds-rs/blob/main/README.md](https://github.com/hyperledger/anoncreds-rs/blob/main/README.md). We will proceed through the following processes in comparison with the legacy anoncreds implementations while watching out for signature differences between the two. -Looking at the [/anoncreds/issuer.py](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/anoncreds/issuer.py) file, from `AnonCredsIssuer` class: +Looking at the [/anoncreds/issuer.py](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/anoncreds/issuer.py) file, from `AnonCredsIssuer` class: Create VC_DI Credential Offer @@ -265,7 +265,7 @@ class Format(Enum): “vc_di/”, CredExRecordVCDI, DeferLoad( - “aries_cloudagent.protocols.issue_credential.v2_0” + “acapy_agent.protocols.issue_credential.v2_0” “.formats.vc_di.handler.AnonCredsW3CFormatHandler” ), ) @@ -376,7 +376,7 @@ Doing so would allow us to be more independent in defining the schema suited for ### Admin API Attachments -To make sure that once an endpoint has been called to trigger the `Issue Credential` flow in `0809 W3C_DI attachment formats` the subsequent endpoints also follow this format, we can keep track of this [ATTACHMENT_FORMAT](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/issue_credential/v2_0/message_types.py#L41-L59) dictionary with the proposed `VC_DI` format. +To make sure that once an endpoint has been called to trigger the `Issue Credential` flow in `0809 W3C_DI attachment formats` the subsequent endpoints also follow this format, we can keep track of this [ATTACHMENT_FORMAT](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/issue_credential/v2_0/message_types.py#L41-L59) dictionary with the proposed `VC_DI` format. ```python # Format specifications @@ -404,18 +404,18 @@ ATTACHMENT_FORMAT = { } ``` -And this [\_formats_filter](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/issue_credential/v2_0/routes.py#L442-L461) function takes care of keeping the attachment formats uniform across the iteration of the flow. We can see this function gets called in: +And this [\_formats_filter](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/issue_credential/v2_0/routes.py#L442-L461) function takes care of keeping the attachment formats uniform across the iteration of the flow. We can see this function gets called in: -- [\_create_free_offer](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/issue_credential/v2_0/routes.py#L877) function that gets called in the handler function of `/issue-credential-2.0/send-offer` route (in addition to other offer routes) -- [credential_exchange_send_free_request](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/issue_credential/v2_0/routes.py#L1229) handler function of `/issue-credential-2.0/send-request` route -- [credential_exchange_create](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/issue_credential/v2_0/routes.py#L630) handler function of `/issue-credential-2.0/create` route -- [credential_exchange_send](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/issue_credential/v2_0/routes.py#L721) handler function of `/issue-credential-2.0/send` route +- [\_create_free_offer](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/issue_credential/v2_0/routes.py#L877) function that gets called in the handler function of `/issue-credential-2.0/send-offer` route (in addition to other offer routes) +- [credential_exchange_send_free_request](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/issue_credential/v2_0/routes.py#L1229) handler function of `/issue-credential-2.0/send-request` route +- [credential_exchange_create](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/issue_credential/v2_0/routes.py#L630) handler function of `/issue-credential-2.0/create` route +- [credential_exchange_send](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/issue_credential/v2_0/routes.py#L721) handler function of `/issue-credential-2.0/send` route -The same goes for [ATTACHMENT_FORMAT](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/present_proof/v2_0/message_types.py#L33-L47) of `Present Proof` flow. In this case, DIF Presentation Exchange formats in these [test vectors](https://github.com/TimoGlastra/anoncreds-w3c-test-vectors/tree/main/test-vectors) that are influenced by [RFC 0510 DIF Presentation Exchange](https://github.com/hyperledger/aries-rfcs/blob/main/features/0510-dif-pres-exch-attach/README.md) will be implemented. Here, the [\_formats_attach](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/present_proof/v2_0/routes.py#L403-L422) function is the key for the same purpose above. It gets called in: +The same goes for [ATTACHMENT_FORMAT](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/present_proof/v2_0/message_types.py#L33-L47) of `Present Proof` flow. In this case, DIF Presentation Exchange formats in these [test vectors](https://github.com/TimoGlastra/anoncreds-w3c-test-vectors/tree/main/test-vectors) that are influenced by [RFC 0510 DIF Presentation Exchange](https://github.com/hyperledger/aries-rfcs/blob/main/features/0510-dif-pres-exch-attach/README.md) will be implemented. Here, the [\_formats_attach](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/present_proof/v2_0/routes.py#L403-L422) function is the key for the same purpose above. It gets called in: -- [present_proof_send_proposal](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/present_proof/v2_0/routes.py#L833) handler function of `/present-proof-2.0/send-proposal` route -- [present_proof_create_request](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/present_proof/v2_0/routes.py#L916) handler function of `/present-proof-2.0/create-request` route -- [present_proof_send_free_request](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/present_proof/v2_0/routes.py#L998) handler function of `/present-proof-2.0/send-request` route +- [present_proof_send_proposal](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/present_proof/v2_0/routes.py#L833) handler function of `/present-proof-2.0/send-proposal` route +- [present_proof_create_request](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/present_proof/v2_0/routes.py#L916) handler function of `/present-proof-2.0/create-request` route +- [present_proof_send_free_request](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/present_proof/v2_0/routes.py#L998) handler function of `/present-proof-2.0/send-request` route #### Credential Exchange Admin Routes @@ -608,7 +608,7 @@ Storing a credential in the wallet is somewhat dependent on the kinds of metadat One of the questions we need to answer is whether the preferred approach is to modify the existing store credential function so that any credential type is a valid input, or whether there should be a special function just for storing W3C credentials. -We will duplicate this [store_credential](https://github.com/hyperledger/aries-cloudagent-python/blob/8cfe8283ddb2a85e090ea1b8a916df2d78298ec0/aries_cloudagent/anoncreds/holder.py#L167) function and modify it: +We will duplicate this [store_credential](https://github.com/openwallet-foundation/acapy/blob/8cfe8283ddb2a85e090ea1b8a916df2d78298ec0/aries_cloudagent/anoncreds/holder.py#L167) function and modify it: ```python async def store_w3c_credential(...) { @@ -647,7 +647,7 @@ If AFJ lags behind in delivering equivalent functionality, we may not be able to ### Where should the new issuance code go? -So the [vc](https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/vc) directory contains code to verify vc's, is this a logical place to add the code for issuance? +So the [vc](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/vc) directory contains code to verify vc's, is this a logical place to add the code for issuance? ### What do we call the new things? Flexcreds? or just W3C_xxx diff --git a/docs/design/UpgradeViaApi.md b/docs/design/UpgradeViaApi.md index c704b6284a..f9a472e962 100644 --- a/docs/design/UpgradeViaApi.md +++ b/docs/design/UpgradeViaApi.md @@ -102,7 +102,7 @@ sequenceDiagram An example of the implementation can be found via the anoncreds upgrade components. -- `aries_cloudagent/wallet/routes.py` in the `upgrade_anoncreds` controller +- `acapy_agent/wallet/routes.py` in the `upgrade_anoncreds` controller - the upgrade code in `wallet/anoncreds_upgrade.py` - the middleware in `admin/server.py` in the `upgrade_middleware` function - the singleton sets in `wallet/singletons.py` diff --git a/docs/features/AnonCredsMethods.md b/docs/features/AnonCredsMethods.md index 882faf0f65..3ce39520c7 100644 --- a/docs/features/AnonCredsMethods.md +++ b/docs/features/AnonCredsMethods.md @@ -20,7 +20,7 @@ are quite familiar with using ACA-Py, have a good understanding of ACA-Py intern Python experts. See the [Questions or Comments](#questions-or-comments) section below for how to get help as you work through this. -[Hyperledger Discord Server]: https://discord.gg/hyperledger +[OpenWallet Foundation Discord Server]: https://discord.gg/openwallet-foundation ## Create a Plugin @@ -32,7 +32,7 @@ be part of ACA-Py core, get your plugin complete and raise the question of addin Maintainers will be happy to discuss the merits of the idea. No promises though. [ACA-Py plugins]: ./PlugIns.md -[aries-acapy-plugins]: https://github.com/hyperledger/aries-acapy-plugins +[aries-acapy-plugins]: https://github.com/openwallet-foundation/acapy-plugins Your AnonCreds plugin will have an [initialization routine] that will register your AnonCreds implementation. It will be registering the identifiers that your method will be using such. It @@ -40,8 +40,8 @@ will be the identifier constructs that will trigger the appropriate AnonCreds Re Resolver that will be called for any given AnonCreds object identifier. Check out this [example of the registration] of the ["legacy" Indy] AnonCreds method for more details. -[initialization routine]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/anoncreds/__init__.py -[example of the registration]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/anoncreds/default/legacy_indy/registry.py +[initialization routine]: https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/anoncreds/__init__.py +[example of the registration]: https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/anoncreds/default/legacy_indy/registry.py ## The Implementation @@ -49,21 +49,21 @@ The basic work involved in creating an AnonCreds method is the implementation of write AnonCreds objects to a VDR, and a "resolver" to read AnonCreds objects from a VDR. To do that for your new AnonCreds method, you will need to: -- Implement `BaseAnonCredsResolver` - [here](https://github.com/hyperledger/aries-cloudagent-python/blob/1786553ffea244c67d82ceaa3f1793dd1ec1c0f5/aries_cloudagent/anoncreds/base.py#L113) -- Implement `BaseAnonCredsRegistrar` - [here](https://github.com/hyperledger/aries-cloudagent-python/blob/1786553ffea244c67d82ceaa3f1793dd1ec1c0f5/aries_cloudagent/anoncreds/base.py#L139) +- Implement `BaseAnonCredsResolver` - [here](https://github.com/openwallet-foundation/acapy/blob/1786553ffea244c67d82ceaa3f1793dd1ec1c0f5/aries_cloudagent/anoncreds/base.py#L113) +- Implement `BaseAnonCredsRegistrar` - [here](https://github.com/openwallet-foundation/acapy/blob/1786553ffea244c67d82ceaa3f1793dd1ec1c0f5/aries_cloudagent/anoncreds/base.py#L139) The links above are to a specific commit and the code may have been updated since. You might want to -look at the methods in the current version of [aries_cloudagent/anoncreds/base.py](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/anoncreds/base.py) in the `main` branch. +look at the methods in the current version of [acapy_agent/anoncreds/base.py](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/anoncreds/base.py) in the `main` branch. The interface for those methods are very clean, and there are currently two implementations of the methods in the ACA-Py codebase -- the ["legacy" Indy] implementation, and the [did:indy] Indy implementation. There is also a [did:web] resolver implementation. -["legacy" Indy]: https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/anoncreds/default/legacy_indy -[did:indy]: https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/anoncreds/default/did_indy -[did:web]: https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/anoncreds/default/did_web +["legacy" Indy]: https://github.com/openwallet-foundation/acapy/tree/main/acapy_agent/anoncreds/default/legacy_indy +[did:indy]: https://github.com/openwallet-foundation/acapy/tree/main/acapy_agent/anoncreds/default/did_indy +[did:web]: https://github.com/openwallet-foundation/acapy/tree/main/acapy_agent/anoncreds/default/did_web -Models for the API are defined [here](https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/anoncreds/models) +Models for the API are defined [here](https://github.com/openwallet-foundation/acapy/tree/main/acapy_agent/anoncreds/models) ## Events @@ -78,13 +78,13 @@ credentials. Your AnonCreds method implementation doesn't have to do much to mak does it automatically -- but your implementation must call the `finish_*` to make trigger ACA-Py to continue the automation. You can see in [Revocation Setup] the automation setup. -[AnonCreds Issuer]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/anoncreds/issuer.py#L56 -[Revocation Setup]: https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/anoncreds/revocation_setup.py +[AnonCreds Issuer]: https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/anoncreds/issuer.py#L56 +[Revocation Setup]: https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/anoncreds/revocation_setup.py ## Questions or Comments The ACA-Py maintainers welcome questions from those new to the community that -have the skills to implement a new AnonCreds method. Use the `#aries-cloudagent-python` channel -on the [Hyperledger Discord Server] or open an issue in this repo to get help. +have the skills to implement a new AnonCreds method. Use the `#aca-py` channel +on the [OpenWallet Foundation Discord Server] or open an issue in this repo to get help. Pull Requests to the ACA-Py repository to improve this content are welcome! diff --git a/docs/features/AnoncredsProofValidation.md b/docs/features/AnoncredsProofValidation.md index aa4a599189..354d999496 100644 --- a/docs/features/AnoncredsProofValidation.md +++ b/docs/features/AnoncredsProofValidation.md @@ -1,8 +1,8 @@ -# Anoncreds Proof Validation in ACA-Py +# AnonCreds Proof Validation in ACA-Py -ACA-Py performs pre-validation when verifying Anoncreds presentations (proofs). Some scenarios are rejected (such as those indicative of tampering), while some attributes are removed before running the anoncreds validation (e.g., removing superfluous non-revocation timestamps). Any ACA-Py validations or presentation modifications are indicated by the "verify_msgs" attribute in the final presentation exchange object. +ACA-Py performs pre-validation when verifying AnonCreds presentations (proofs). Some scenarios are rejected (such as those indicative of tampering), while some attributes are removed before running the AnonCreds validation (e.g., removing superfluous non-revocation timestamps). Any ACA-Py validations or presentation modifications are indicated by the "verify_msgs" attribute in the final presentation exchange object. -The list of possible verification messages can be found [here](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/indy/verifier.py#L24), and consists of: +The list of possible verification messages can be found [here](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/indy/verifier.py#L24), and consists of: ```python class PresVerifyMsg(str, Enum): @@ -61,7 +61,7 @@ The following pre-verification checks are performed, which will cause the proof VALUE_ERROR:: ``` -These validations are all performed within the [Indy verifier class](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/indy/verifier.py) - to see the detailed validation, look for any occurrences of `raise ValueError(...)` in the code. +These validations are all performed within the [Indy verifier class](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/indy/verifier.py) - to see the detailed validation, look for any occurrences of `raise ValueError(...)` in the code. A summary of the possible errors includes: diff --git a/docs/features/DIDResolution.md b/docs/features/DIDResolution.md index 23144a894a..607d3f2dc3 100644 --- a/docs/features/DIDResolution.md +++ b/docs/features/DIDResolution.md @@ -176,7 +176,7 @@ plugin: The following is a fully functional Dockerfile encapsulating this setup: ```dockerfile= -FROM ghcr.io/hyperledger/aries-cloudagent-python:py3.9-0.12.1 +FROM ghcr.io/openwallet-foundation/acapy:py3.9-0.12.1 RUN pip3 install git+https://github.com/dbluhm/acapy-resolver-github CMD ["aca-py", "start", "-it", "http", "0.0.0.0", "3000", "-ot", "http", "-e", "http://localhost:3000", "--admin", "0.0.0.0", "3001", "--admin-insecure-mode", "--no-ledger", "--plugin", "acapy_resolver_github"] diff --git a/docs/features/DevReadMe.md b/docs/features/DevReadMe.md index debd55e5b3..f310acaa88 100644 --- a/docs/features/DevReadMe.md +++ b/docs/features/DevReadMe.md @@ -1,4 +1,4 @@ -# Developer's Read Me for Hyperledger Aries Cloud Agent - Python +# Developer's Read Me for ACA-Py See the [README](../../README.md) for details about this repository and information about how the Aries Cloud Agent - Python fits into the Aries project and relates to Indy. @@ -29,7 +29,7 @@ See the [README](../../README.md) for details about this repository and informat ## Introduction -Aries Cloud Agent Python (ACA-Py) is a configurable, extensible, non-mobile Aries agent that implements an easy way for developers to build decentralized identity services that use verifiable credentials. +ACA-Py is a configurable, extensible, non-mobile Aries agent that implements an easy way for developers to build decentralized identity services that use verifiable credentials. The information on this page assumes you are developer with a background in decentralized identity, Aries, DID Methods, and verifiable credentials, @@ -59,7 +59,7 @@ variable: For a comprehensive list of all arguments, argument groups, CLI args, and their environment variable equivalents, please see -the [argparse.py](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/config/argparse.py) +the [argparse.py](https://github.com/openwallet-foundation/acapy/blob/main/aries_cloudagent/config/argparse.py) file. @@ -126,7 +126,7 @@ aca-py start --inbound-transport http 0.0.0.0 8000 \ --outbound-transport http ``` -ACA-Py ships with both inbound and outbound transport drivers for `http` and `ws` (websockets). Additional transport drivers can be added as pluggable implementations. See the existing implementations in the [transports module](https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/transport) for getting started on adding a new transport. +ACA-Py ships with both inbound and outbound transport drivers for `http` and `ws` (websockets). Additional transport drivers can be added as pluggable implementations. See the existing implementations in the [transports module](https://github.com/openwallet-foundation/acapy/tree/main/aries_cloudagent/transport) for getting started on adding a new transport. Most configuration parameters are provided to the agent at startup. Refer to the `Running` sections above for details on listing the available command line parameters. @@ -258,7 +258,7 @@ Please also refer to the [contributing guidelines](../../CONTRIBUTING.md) and [c ## Publishing Releases -The [publishing](https://github.com/hyperledger/aries-cloudagent-python/blob/main/PUBLISHING.md) document provides information on tagging a release and publishing the release artifacts to PyPi. +The [publishing](../../PUBLISHING.md) document provides information on tagging a release and publishing the release artifacts to PyPi. ## Dynamic Injection of Services diff --git a/docs/features/Endorser.md b/docs/features/Endorser.md index a645309af0..71207fada7 100644 --- a/docs/features/Endorser.md +++ b/docs/features/Endorser.md @@ -63,11 +63,11 @@ Endorsement: Internally, the Endorsement functionality is implemented as a protocol, and is implemented consistently with other protocols: -- a [routes.py](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/endorse_transaction/v1_0/routes.py) file exposes the admin endpoints -- [handler files](https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/protocols/endorse_transaction/v1_0/handlers) implement responses to any received Endorse protocol messages -- a [manager.py](https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/endorse_transaction/v1_0/manager.py) file implements common functionality that is called from both the routes.py and handler classes (as well as from other classes that need to interact with Endorser functionality) +- a [routes.py](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/endorse_transaction/v1_0/routes.py) file exposes the admin endpoints +- [handler files](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/endorse_transaction/v1_0/handlers) implement responses to any received Endorse protocol messages +- a [manager.py](https://github.com/openwallet-foundation/acapy/blob/main/acapy_agent/protocols/endorse_transaction/v1_0/manager.py) file implements common functionality that is called from both the routes.py and handler classes (as well as from other classes that need to interact with Endorser functionality) -The Endorser makes use of the [Event Bus](https://github.com/hyperledger/aries-cloudagent-python/blob/main/CHANGELOG.md#july-14-2021) (links to the PR which links to a hackmd doc) to notify other protocols of any Endorser events of interest. For example, after a Credential Definition endorsement is received, the TransactionManager writes the endorsed transaction to the ledger and uses the Event Bus to notify the Credential Definition manager that it can do any required post-processing (such as writing the cred def record to the wallet, initiating the revocation registry, etc.). +The Endorser makes use of the [Event Bus](https://github.com/openwallet-foundation/acapy/blob/main/CHANGELOG.md#july-14-2021) (links to the PR which links to a hackmd doc) to notify other protocols of any Endorser events of interest. For example, after a Credential Definition endorsement is received, the TransactionManager writes the endorsed transaction to the ledger and uses the Event Bus to notify the Credential Definition manager that it can do any required post-processing (such as writing the cred def record to the wallet, initiating the revocation registry, etc.). The overall architecture can be illustrated as: diff --git a/docs/features/JsonLdCredentials.md b/docs/features/JsonLdCredentials.md index a5c087f848..ec062034d9 100644 --- a/docs/features/JsonLdCredentials.md +++ b/docs/features/JsonLdCredentials.md @@ -1,6 +1,6 @@ # JSON-LD Credentials in ACA-Py -By design Hyperledger Aries is credential format agnostic. This means you can use it for any credential format, as long as an RFC is defined for the specific credential format. ACA-Py currently supports two types of credentials, Indy and JSON-LD credentials. This document describes how to use the latter by making use of [W3C Verifiable Credentials](https://www.w3.org/TR/vc-data-model/) using [Linked Data Proofs](https://w3c-ccg.github.io/ld-proofs). +By design ACA-Py is credential format agnostic. This means you can use it for any credential format, as long as an RFC is defined for the specific credential format. ACA-Py currently supports two types of credentials, AnonCreds and JSON-LD credentials. This document describes how to use the latter by making use of [W3C Verifiable Credentials](https://www.w3.org/TR/vc-data-model/) using [Linked Data Proofs](https://w3c-ccg.github.io/ld-proofs). ## Table of Contents @@ -10,13 +10,14 @@ By design Hyperledger Aries is credential format agnostic. This means you can us - [JSON-LD Context](#json-ld-context) - [Writing JSON-LD Contexts](#writing-json-ld-contexts) - [Signature Suite](#signature-suite) - - [Did Method](#did-method) + - [DID Method](#did-method) - [`did:sov`](#didsov) - [`did:key`](#didkey) - [Issuing Credentials](#issuing-credentials) - [Retrieving Issued Credentials](#retrieving-issued-credentials) - [Present Proof](#present-proof) - [VC-API](#vc-api) +- [External Suite Provider](#external-suite-provider) ## General Concept @@ -211,7 +212,7 @@ Call the `/credentials/w3c` endpoint to retrieve all JSON-LD credentials in your ## Present Proof -> ⚠️ TODO: [https://github.com/hyperledger/aries-cloudagent-python/pull/1125](https://github.com/hyperledger/aries-cloudagent-python/pull/1125) +> ⚠️ TODO: [https://github.com/openwallet-foundation/acapy/pull/1125](https://github.com/openwallet-foundation/acapy/pull/1125) ## VC-API @@ -227,11 +228,11 @@ These endpoints include: - `POST /vc/presentations/prove` -> proves a presentation - `POST /vc/presentations/verify` -> verifies a presentation -To learn more about using these endpoints, please refer to the available [postman collection](../demo/AriesPostmanDemo.md#experimenting-with-the-vc-api-endpoints). +To learn more about using these endpoints, please refer to the available [postman collection](../demo/PostmanDemo.md#experimenting-with-the-vc-api-endpoints). ## External Suite Provider -It is possible to extend the signature suite support, including outsourcing signing JSON-LD Credentials to some other component (KMS, HSM, etc.), using the [`ExternalSuiteProvider` interface](https://github.com/hyperledger/aries-cloudagent-python/blob/d3ee92b1b86aff076b52f31eaecea59c18005079/aries_cloudagent/vc/vc_ld/external_suite.py#L27). This interface can be implemented and registered via plugin. The plugged in provider will be used by ACA-Py's LDP-VC subsystem to create a `LinkedDataProof` object, which is responsible for signing normalized credential values. +It is possible to extend the signature suite support, including outsourcing signing JSON-LD Credentials to some other component (KMS, HSM, etc.), using the [`ExternalSuiteProvider` interface](https://github.com/openwallet-foundation/acapy/blob/d3ee92b1b86aff076b52f31eaecea59c18005079/aries_cloudagent/vc/vc_ld/external_suite.py#L27). This interface can be implemented and registered via plugin. The plugged in provider will be used by ACA-Py's LDP-VC subsystem to create a `LinkedDataProof` object, which is responsible for signing normalized credential values. This interface enables taking advantage of ACA-Py's JSON-LD processing to construct and format the credential while exposing a simple interface to a plugin to make it responsible for signatures. This can also be combined with plugged in DID Methods, `VerificationKeyStrategy`, and other pluggable components. diff --git a/docs/features/Multicredentials.md b/docs/features/Multicredentials.md index 9822438bee..a29abb2eb0 100644 --- a/docs/features/Multicredentials.md +++ b/docs/features/Multicredentials.md @@ -2,8 +2,8 @@ It is a known fact that multiple AnonCreds can be combined to present a presentation proof with an "and" logical operator: For instance, a verifier can ask for the "name" claim from an eID and the "address" claim from a bank statement to have a single proof that is either valid or invalid. With the Present Proof Protocol v2, it is possible to have "and" and "or" logical operators for AnonCreds and/or W3C Verifiable Credentials. -With the Present Proof Protocol v2, verifiers can ask for a combination of credentials as proof. For instance, a Verifier can ask a claim from an AnonCreds **and** a verifiable presentation from a W3C Verifiable Credential, which would open the possibilities of Aries Cloud Agent Python being used for rather complex presentation proof requests that wouldn't be possible without the support of AnonCreds or W3C Verifiable Credentials. +With the Present Proof Protocol v2, verifiers can ask for a combination of credentials as proof. For instance, a Verifier can ask a claim from an AnonCreds **and** a verifiable presentation from a W3C Verifiable Credential, which would open the possibilities of ACA-Py being used for rather complex presentation proof requests that wouldn't be possible without the support of AnonCreds or W3C Verifiable Credentials. -Moreover, it is possible to make similar presentation proof requests using the or logical operator. For instance, a verifier can ask for either an eID in AnonCreds format or an eID in W3C Verifiable Credential format. This has the potential to solve the interoperability problem of different credential formats and ecosystems from a user point of view by shifting the requirement of holding/accepting different credential formats from identity holders to verifiers. Here again, using Aries Cloud Agent Python as the underlying verifier agent can tackle such complex presentation proof requests since the agent is capable of verifying both type of credential formats and proof types. +Moreover, it is possible to make similar presentation proof requests using the or logical operator. For instance, a verifier can ask for either an eID in AnonCreds format or an eID in W3C Verifiable Credential format. This has the potential to solve the interoperability problem of different credential formats and ecosystems from a user point of view by shifting the requirement of holding/accepting different credential formats from identity holders to verifiers. Here again, using ACA-Py as the underlying verifier agent can tackle such complex presentation proof requests since the agent is capable of verifying both type of credential formats and proof types. In the future, it would be even possible to put mDoc as an attachment with an and or or logical operation, along with AnonCreds and/or W3C Verifiable Credentials. For this to happen, Aca-Py either needs the capabilities to validate mDocs internally or to connect third-party endpoints to validate and get a response. diff --git a/docs/features/Multiledger.md b/docs/features/Multiledger.md index dba4cf6e41..eba1e87591 100644 --- a/docs/features/Multiledger.md +++ b/docs/features/Multiledger.md @@ -22,7 +22,7 @@ More background information including problem statement, design (algorithm) and Multi-ledger is disabled by default. You can enable support for multiple ledgers using the `--genesis-transactions-list` startup parameter. This parameter accepts a string which is the path to the `YAML` configuration file. For example: -`--genesis-transactions-list ./aries_cloudagent/config/multi_ledger_config.yml` +`--genesis-transactions-list ./acapy_agent/config/multi_ledger_config.yml` If `--genesis-transactions-list` is specified, then `--genesis-url, --genesis-file, --genesis-transactions` should not be specified. @@ -176,7 +176,7 @@ Once you re-start ACA-Py, you can check the `GET /ledger/taa` endpoint to verify There should be no impact/change in functionality to any ACA-Py protocols. -`IndySdkLedger` was refactored by replacing `wallet: IndySdkWallet` instance variable with `profile: Profile` and accordingly `.aries_cloudagent/indy/credex/verifier`, `.aries_cloudagent/indy/models/pres_preview`, `.aries_cloudagent/indy/sdk/profile.py`, `.aries_cloudagent/indy/sdk/verifier`, `./aries_cloudagent/indy/verifier` were also updated. +`IndySdkLedger` was refactored by replacing `wallet: IndySdkWallet` instance variable with `profile: Profile` and accordingly `.acapy_agent/indy/credex/verifier`, `.acapy_agent/indy/models/pres_preview`, `.acapy_agent/indy/sdk/profile.py`, `.acapy_agent/indy/sdk/verifier`, `./acapy_agent/indy/verifier` were also updated. Added `build_and_return_get_nym_request` and `submit_get_nym_request` helper functions to `IndySdkLedger` and `IndyVdrLedger`. @@ -184,31 +184,31 @@ Best practice/feedback emerging from `Askar session deadlock` issue and `endorse These changes are made here: -- `./aries_cloudagent/ledger/routes.py` -- `./aries_cloudagent/messaging/credential_definitions/routes.py` -- `./aries_cloudagent/messaging/schemas/routes.py` -- `./aries_cloudagent/protocols/actionmenu/v1_0/routes.py` -- `./aries_cloudagent/protocols/actionmenu/v1_0/util.py` -- `./aries_cloudagent/protocols/basicmessage/v1_0/routes.py` -- `./aries_cloudagent/protocols/coordinate_mediation/v1_0/handlers/keylist_handler.py` -- `./aries_cloudagent/protocols/coordinate_mediation/v1_0/routes.py` -- `./aries_cloudagent/protocols/endorse_transaction/v1_0/routes.py` -- `./aries_cloudagent/protocols/introduction/v0_1/handlers/invitation_handler.py` -- `./aries_cloudagent/protocols/introduction/v0_1/routes.py` -- `./aries_cloudagent/protocols/issue_credential/v1_0/handlers/credential_issue_handler.py` -- `./aries_cloudagent/protocols/issue_credential/v1_0/handlers/credential_offer_handler.py` -- `./aries_cloudagent/protocols/issue_credential/v1_0/handlers/credential_proposal_handler.py` -- `./aries_cloudagent/protocols/issue_credential/v1_0/handlers/credential_request_handler.py` -- `./aries_cloudagent/protocols/issue_credential/v1_0/routes.py` -- `./aries_cloudagent/protocols/issue_credential/v2_0/routes.py` -- `./aries_cloudagent/protocols/present_proof/v1_0/handlers/presentation_handler.py` -- `./aries_cloudagent/protocols/present_proof/v1_0/handlers/presentation_proposal_handler.py` -- `./aries_cloudagent/protocols/present_proof/v1_0/handlers/presentation_request_handler.py` -- `./aries_cloudagent/protocols/present_proof/v1_0/routes.py` -- `./aries_cloudagent/protocols/trustping/v1_0/routes.py` -- `./aries_cloudagent/resolver/routes.py` -- `./aries_cloudagent/revocation/routes.py` +- `./acapy_agent/ledger/routes.py` +- `./acapy_agent/messaging/credential_definitions/routes.py` +- `./acapy_agent/messaging/schemas/routes.py` +- `./acapy_agent/protocols/actionmenu/v1_0/routes.py` +- `./acapy_agent/protocols/actionmenu/v1_0/util.py` +- `./acapy_agent/protocols/basicmessage/v1_0/routes.py` +- `./acapy_agent/protocols/coordinate_mediation/v1_0/handlers/keylist_handler.py` +- `./acapy_agent/protocols/coordinate_mediation/v1_0/routes.py` +- `./acapy_agent/protocols/endorse_transaction/v1_0/routes.py` +- `./acapy_agent/protocols/introduction/v0_1/handlers/invitation_handler.py` +- `./acapy_agent/protocols/introduction/v0_1/routes.py` +- `./acapy_agent/protocols/issue_credential/v1_0/handlers/credential_issue_handler.py` +- `./acapy_agent/protocols/issue_credential/v1_0/handlers/credential_offer_handler.py` +- `./acapy_agent/protocols/issue_credential/v1_0/handlers/credential_proposal_handler.py` +- `./acapy_agent/protocols/issue_credential/v1_0/handlers/credential_request_handler.py` +- `./acapy_agent/protocols/issue_credential/v1_0/routes.py` +- `./acapy_agent/protocols/issue_credential/v2_0/routes.py` +- `./acapy_agent/protocols/present_proof/v1_0/handlers/presentation_handler.py` +- `./acapy_agent/protocols/present_proof/v1_0/handlers/presentation_proposal_handler.py` +- `./acapy_agent/protocols/present_proof/v1_0/handlers/presentation_request_handler.py` +- `./acapy_agent/protocols/present_proof/v1_0/routes.py` +- `./acapy_agent/protocols/trustping/v1_0/routes.py` +- `./acapy_agent/resolver/routes.py` +- `./acapy_agent/revocation/routes.py` ## Known Issues -- When in multi-ledger mode and switching ledgers (e.g.: the agent is registered on Ledger A and has published its DID there, and now wants to "move" to Ledger B) there is an [issue](https://github.com/hyperledger/aries-cloudagent-python/issues/2473) that will cause the registration to the new ledger to fail. +- When in multi-ledger mode and switching ledgers (e.g.: the agent is registered on Ledger A and has published its DID there, and now wants to "move" to Ledger B) there is an [issue](https://github.com/openwallet-foundation/acapy/issues/2473) that will cause the registration to the new ledger to fail. diff --git a/docs/features/Multitenancy.md b/docs/features/Multitenancy.md index 135f55656b..fb35bbeff3 100644 --- a/docs/features/Multitenancy.md +++ b/docs/features/Multitenancy.md @@ -9,11 +9,7 @@ This allows ACA-Py to be used for a wider range of use cases. One use case could - [General Concept](#general-concept) - [Base and Sub Wallets](#base-and-sub-wallets) - [Usage](#usage) -- [Multi-tenant Admin API](#multi-tenant-admin-api) -- [Managed vs Unmanaged Mode](#managed-vs-unmanaged-mode) - - [Managed Mode](#managed-mode) - - [Unmanaged Mode](#unmanaged-mode) - - [Mode Usage](#mode-usage) + - [Single Wallet vs Multiple Wallets](#single-wallet-vs-multiple-wallets) - [Message Routing](#message-routing) - [Relaying](#relaying) - [Mediation](#mediation) @@ -108,7 +104,7 @@ The mode used can be specified when creating a wallet using the `key_management_ ## Message Routing -In multi-tenant mode, when ACA-Py receives a message from another agent, it will need to determine which tenant to route the message to. Hyperledger Aries defines two types of routing methods, mediation and relaying. +In multi-tenant mode, when ACA-Py receives a message from another agent, it will need to determine which tenant to route the message to. ACA-Py defines two types of routing methods, mediation and relaying. See the [Mediators and Relays](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0046-mediators-and-relays/README.md) RFC for an in-depth description of the difference between the two concepts. @@ -385,7 +381,7 @@ curl -X POST "${ACAPY_ADMIN_URL}/multitenancy/wallet/{wallet_id}/remove" \ ### Per tenant settings -To allow the configuring of ACA-Py startup parameters/environment variables at a tenant/subwallet level. [PR#2233](https://github.com/hyperledger/aries-cloudagent-python/pull/2233) will provide the ability to update the following subset of settings when creating or updating the subwallet: +To allow the configuring of ACA-Py startup parameters/environment variables at a tenant/subwallet level. [PR#2233](https://github.com/openwallet-foundation/acapy/pull/2233) will provide the ability to update the following subset of settings when creating or updating the subwallet: | Labels | | Setting | |---|---|---| diff --git a/docs/features/PlugIns.md b/docs/features/PlugIns.md index 3f041f90bb..f3f929b69c 100644 --- a/docs/features/PlugIns.md +++ b/docs/features/PlugIns.md @@ -160,14 +160,14 @@ The following links may be helpful or provide additional context for the current Configuration params: -- https://github.com/hyperledger/aries-cloudagent-python/issues/1121 +- https://github.com/openwallet-foundation/acapy/issues/1121 - https://hackmd.io/ROUzENdpQ12cz3UB9qk1nA -- https://github.com/hyperledger/aries-cloudagent-python/pull/1226 +- https://github.com/openwallet-foundation/acapy/pull/1226 Loading plug-ins: -- https://github.com/hyperledger/aries-cloudagent-python/pull/1086 +- https://github.com/openwallet-foundation/acapy/pull/1086 Versioning for plug-ins: -- https://github.com/hyperledger/aries-cloudagent-python/pull/443 +- https://github.com/openwallet-foundation/acapy/pull/443 diff --git a/docs/features/SupportedRFCs.md b/docs/features/SupportedRFCs.md index 218291b590..d5cf331525 100644 --- a/docs/features/SupportedRFCs.md +++ b/docs/features/SupportedRFCs.md @@ -1,4 +1,4 @@ -# Aries AIP and RFCs Supported in Aries Cloud Agent Python +# Aries AIP and RFCs Supported in ACA-Py This document provides a summary of the adherence of ACA-Py to the [Aries Interop Profiles](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile), @@ -6,7 +6,7 @@ and an overview of the ACA-Py feature set. This document is manually updated and as such, may not be up to date with the most recent release of ACA-Py or the repository `main` branch. Reminders (and PRs!) to update this page are welcome! If you have any questions, please contact us on the #aries channel on -[Hyperledger Discord](https://discord.gg/hyperledger) or through an issue in this repo. +[OpenWallet Foundation Discord](https://discord.gg/openwallet-foundation) or through an issue in this repo. **Last Update**: 2024-10-08, Release 1.0.1 @@ -17,7 +17,7 @@ welcome! If you have any questions, please contact us on the #aries channel on See the [Aries Agent Test Harness](https://github.com/hyperledger/aries-agent-test-harness) and the [Aries Interoperability Status](https://aries-interop.info) for daily interoperability test run results between -ACA-Py and other Aries Frameworks and Agents. +ACA-Py and other decentralized trust Frameworks and Agents. | AIP Version | Supported | Notes | | - | :-------: | -------- | @@ -32,7 +32,7 @@ A summary of the Aries Interop Profiles and Aries RFCs supported in ACA-Py can b | ---------- | :----------------: | -------------------------------------------------------------------------------------------------------------------------- | | Server | :white_check_mark: | | | Kubernetes | :white_check_mark: | BC Gov has extensive experience running ACA-Py on Red Hat's OpenShift Kubernetes Distribution. | -| Docker | :white_check_mark: | Official docker images are published to the GitHub container repository at `ghcr.io/hyperledger/aries-cloudagent-python`. | +| Docker | :white_check_mark: | Official docker images are published to the GitHub container repository at [https://ghcr.io/openwallet-foundation/acapy](https://ghcr.io/openwallet-foundation/acapy). | | Desktop | :warning: | Could be run as a local service on the computer | | iOS | :x: | | | Android | :x: | | @@ -94,7 +94,7 @@ A summary of the Aries Interop Profiles and Aries RFCs supported in ACA-Py can b | Invitations using peer dids supporting connection reuse | :white_check_mark: | | | Implicit pickup of messages in role of mediator | :white_check_mark: | | | [Revocable AnonCreds Credentials](https://github.com/hyperledger/indy-hipe/tree/main/text/0011-cred-revocation) | :white_check_mark: | | -| Multi-Tenancy | :white_check_mark: | [Documentation](https://github.com/hyperledger/aries-cloudagent-python/blob/main/Multitenancy.md) | +| Multi-Tenancy | :white_check_mark: | [Documentation](https://github.com/openwallet-foundation/acapy/blob/main/Multitenancy.md) | | Multi-Tenant Management | :white_check_mark: | The [Traction] open source project from BC Gov is a layer on top of ACA-Py that enables the easy management of ACA-Py tenants, with an Administrative UI ("The Innkeeper") and a Tenant UI for using ACA-Py in a web UI (setting up, issuing, holding and verifying credentials) | | Connection-less (non OOB protocol / AIP 1.0) | :white_check_mark: | Only for issue credential and present proof | | Connection-less (OOB protocol / AIP 2.0) | :white_check_mark: | Only for present proof | diff --git a/docs/features/UsingOpenAPI.md b/docs/features/UsingOpenAPI.md index 8a826d3814..a102d92dd0 100644 --- a/docs/features/UsingOpenAPI.md +++ b/docs/features/UsingOpenAPI.md @@ -6,9 +6,9 @@ The running agent provides a `Swagger User Interface` that can be browsed and us ## ACA-Py, OpenAPI Raw Output Characteristics -ACA-Py uses [aiohttp_apispec](https://github.com/maximdanilchenko/aiohttp-apispec) tags in code to produce the OpenAPI spec file at runtime dependent on what features have been loaded. How these tags are created is documented in the [API Standard Behavior](https://github.com/hyperledger/aries-cloudagent-python/blob/main/AdminAPI.md#api-standard-behaviour) section of the [Admin API Readme](./AdminAPI.md). The OpenAPI spec is available in raw, unformatted form from a running ACA-Py instance using a route of `http:///api/docs/swagger.json` or from the browser `Swagger User Interface` directly. +ACA-Py uses [aiohttp_apispec](https://github.com/maximdanilchenko/aiohttp-apispec) tags in code to produce the OpenAPI spec file at runtime dependent on what features have been loaded. How these tags are created is documented in the [API Standard Behavior](./AdminAPI.md#api-standard-behaviour) section of the [Admin API Readme](./AdminAPI.md). The OpenAPI spec is available in raw, unformatted form from a running ACA-Py instance using a route of `http:///api/docs/swagger.json` or from the browser `Swagger User Interface` directly. -The ACA-Py Admin API evolves across releases. To track these changes and ensure conformance with the OpenAPI specification, we provide a tool located at [`scripts/generate-open-api-spec`](https://github.com/hyperledger/aries-cloudagent-python/blob/main/scripts/generate-open-api-spec). This tool starts ACA-Py, retrieves the `swagger.json` file, and runs codegen tools to generate specifications in both Swagger and OpenAPI formats with `json` language output. The output of this tool enables comparison with the checked-in `open-api/swagger.json` and `open-api/openapi.json`, and also serves as a useful resource for identifying any non-conformance to the OpenAPI specification. At the moment, `validation` is turned off via the `open-api/openAPIJSON.config` file, so warning messages are printed for non-conformance, but the `json` is still output. Most of the warnings reported by `generate-open-api-spec` relate to missing `operationId` fields which results in manufactured method names being created by codegen tools. At the moment, [aiohttp_apispec](https://github.com/maximdanilchenko/aiohttp-apispec) does not support adding `operationId` annotations via tags. +The ACA-Py Admin API evolves across releases. To track these changes and ensure conformance with the OpenAPI specification, we provide a tool located at [`scripts/generate-open-api-spec`](https://github.com/openwallet-foundation/acapy/blob/main/scripts/generate-open-api-spec). This tool starts ACA-Py, retrieves the `swagger.json` file, and runs codegen tools to generate specifications in both Swagger and OpenAPI formats with `json` language output. The output of this tool enables comparison with the checked-in `open-api/swagger.json` and `open-api/openapi.json`, and also serves as a useful resource for identifying any non-conformance to the OpenAPI specification. At the moment, `validation` is turned off via the `open-api/openAPIJSON.config` file, so warning messages are printed for non-conformance, but the `json` is still output. Most of the warnings reported by `generate-open-api-spec` relate to missing `operationId` fields which results in manufactured method names being created by codegen tools. At the moment, [aiohttp_apispec](https://github.com/maximdanilchenko/aiohttp-apispec) does not support adding `operationId` annotations via tags. The `generate-open-api-spec` tool was initially created to help identify issues with method parameters not being sorted, resulting in somewhat random ordering each time a codegen operation was performed. This is relevant for languages which do not have support for [named parameters](https://en.wikipedia.org/wiki/Named_parameter) such as `Javascript`. It is recommended that the `generate-open-api-spec` is run prior to each release, and the resulting `open-api/openapi.json` file checked in to allow tracking of API changes over time. At the moment, this process is not automated as part of the release pipeline. diff --git a/docs/features/W3cCredentials.md b/docs/features/W3cCredentials.md index c0a6441a94..72d871b7d9 100644 --- a/docs/features/W3cCredentials.md +++ b/docs/features/W3cCredentials.md @@ -1,27 +1,30 @@ -## Verifiable Credential Data Integrity (VC-DI) Credentials in Aries Cloud Agent Python (ACA-Py) +## Verifiable Credential Data Integrity (VC-DI) Credentials in ACA-Py This document outlines a new functionality within Aries Agent that facilitates the issuance of credentials and presentations in compliance with the W3C standard. ### Table of Contents -- [General Concept](#general-concept) -- [Prerequisites](#prerequisites) - - [Verifiable Credentials Data Model](#verifiable-credentials-data-model) - - [Verifiable Presentations Data Model](#verifiable-presentations-data-model) - - [DIF Presentation Format](#dif-presentation-format) -- [Preparing to Issue a Credential](#preparing-to-issue-a-credential) - - [VC-DI Context](#vc-di-context) - - [Signature Suite](#signature-suite) - - [DID Method](#did-method) -- [Issue a Credential](#issue-a-credential) -- [Verify a Credential](#verify-a-credential) -- [Present Proof](#present-proof) - - [Requesting Proof](#requesting-proof) - - [Presenting Proof](#presenting-proof) - - [Verifying Proof](#verifying-proof) -- [Appendix](#appendix) - - [Glossary of Terms](#glossary-of-terms) - - [References and Resources](#references-and-resources) +- [Verifiable Credential Data Integrity (VC-DI) Credentials in ACA-Py](#verifiable-credential-data-integrity-vc-di-credentials-in-aca-py) + - [Table of Contents](#table-of-contents) + - [General Concept](#general-concept) + - [Prerequisites](#prerequisites) + - [Verifiable Credentials Data Model](#verifiable-credentials-data-model) + - [Verifiable Presentations Data Model](#verifiable-presentations-data-model) + - [DIF Presentation Format](#dif-presentation-format) + - [Preparing to Issue a Credential](#preparing-to-issue-a-credential) + - [VC-DI Context](#vc-di-context) + - [Signature Suite](#signature-suite) + - [DID Method](#did-method) + - [`did:key`](#didkey) + - [Issue a Credential](#issue-a-credential) + - [Verify a Credential](#verify-a-credential) + - [Present Proof](#present-proof) + - [Requesting Proof](#requesting-proof) + - [Presenting Proof](#presenting-proof) + - [Verifying Proof](#verifying-proof) + - [Appendix](#appendix) + - [Glossary of Terms](#glossary-of-terms) + - [References and Resources](#references-and-resources) ### General Concept @@ -136,7 +139,7 @@ Ensure the credential data conforms to the VC-DI context. 2. **Select Credential type** The ability to choose the credential type (indy, vc_di) to be issued. The credential type is used to determine the schema for the credential data. -The format to change credential can be seen in the ["Demo Instruction"](../demo/README.md) +The format to change credential can be seen in the [Demo Instruction](../demo/README.md) 3. **Send the Credential:** Use the `/issue-credential-2.0/send` endpoint to issue the credential. @@ -630,9 +633,9 @@ To verify presented proof, follow these steps: #### References and Resources -- [Aries Cloud Agent Python Documentation](https://github.com/hyperledger/aries-cloudagent-python) +- [ACA-Py Documentation](https://aca-py.org) - [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/) - [Verifiable Presentations Data Model](https://www.w3.org/TR/vc-data-model/#presentations) - [DIF Presentation Format](https://identity.foundation/presentation-exchange/) - [did:key Method Specification](https://w3c-ccg.github.io/did-method-key/) -- ["Aries Cloud Agent Python (ACA-Py) Demos"](https://github.com/sarthakvijayvergiya/aries-cloudagent-python/blob/whatscookin/feat/vc-di-proof/docs/demo/README.md) \ No newline at end of file +- [ACA-Py Demos](https://github.com/sarthakvijayvergiya/aries-cloudagent-python/blob/whatscookin/feat/vc-di-proof/docs/demo/README.md) diff --git a/docs/features/devcontainer.md b/docs/features/devcontainer.md index 73dc62b1f4..f2391f2da1 100644 --- a/docs/features/devcontainer.md +++ b/docs/features/devcontainer.md @@ -9,7 +9,7 @@ By no means is ACA-Py limited to these tools; they are merely examples. ## Caveats -The primary use case for this `devcontainer` is for developing, debugging and unit testing (pytest) the [aries_cloudagent](https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent) source code. +The primary use case for this `devcontainer` is for developing, debugging and unit testing (pytest) the [aries_cloudagent](https://github.com/openwallet-foundation/acapy/tree/main/acapy_agent) source code. There are limitations running this devcontainer, such as all networking is within this container. This container has [docker-in-docker](https://github.com/microsoft/vscode-dev-containers/blob/main/script-library/docs/docker-in-docker.md) which allows running demos, building docker images, running `docker compose` all within this container. @@ -44,7 +44,7 @@ To open ACA-Py in a devcontainer, we open the *root* of this repository. We can #### devcontainer.json -When the [.devcontainer/devcontainer.json](https://github.com/hyperledger/aries-cloudagent-python/blob/main/.devcontainer/devcontainer.json) is opened, you will see it building... it is building a Python 3.12 image (bash shell) and loading it with all the ACA-Py requirements. We also load a few Visual Studio settings (for running Pytests and formatting with Ruff). +When the [.devcontainer/devcontainer.json](https://github.com/openwallet-foundation/acapy/blob/main/.devcontainer/devcontainer.json) is opened, you will see it building... it is building a Python 3.12 image (bash shell) and loading it with all the ACA-Py requirements. We also load a few Visual Studio settings (for running Pytests and formatting with Ruff). ### Poetry @@ -59,7 +59,7 @@ ruff check . poetry --version ``` -The first command should show you that `aries_cloudagent` module is loaded (ACA-Py). The others are examples of code quality checks that ACA-Py does on commits (if you have [`precommit`](https://pre-commit.com) installed) and Pull Requests. +The first command should show you that `acapy_agent` module is loaded (ACA-Py). The others are examples of code quality checks that ACA-Py does on commits (if you have [`precommit`](https://pre-commit.com) installed) and Pull Requests. When running `ruff check .` in the terminal, you may see `error: Failed to initialize cache at /.ruff_cache: Permission denied (os error 13)` - that's ok. If there are actual ruff errors, you should see something like: @@ -73,7 +73,7 @@ Found 1 error. We have added Ruff extensions. Although we have added launch settings for both `ruff`, you can also use the extension commands from the command palette. -- `ruff (format) - aries_cloudagent` +- `ruff (format) - acapy_agent` More importantly, these extensions are now added to document save, so files will be formatted and checked. We advise that after each time you rebuild the container that you also perform: `Developer: Reload Window` to ensure the extensions are loaded correctly. diff --git a/docs/gettingStarted/ACA-PyAgentArchitecture.md b/docs/gettingStarted/ACA-PyAgentArchitecture.md new file mode 100644 index 0000000000..093d245504 --- /dev/null +++ b/docs/gettingStarted/ACA-PyAgentArchitecture.md @@ -0,0 +1,16 @@ +# ACA-Py Internals: Agent and Controller + +This section talks in particular about the architecture of ACA-Py. An instance of an ACA-Py agent is actually made up of to two parts - the agent itself and a controller. + +![ACA-Py Deployment Overview](../assets/deploymentModel-full.png "ACA-Py Deployment Overview") + +The agent handles all of the core Aries/non-Aries functionality such as interacting with other agents, managing secure storage, sending event notifications to, and receiving directions from, the controller. The controller provides the business logic that defines how that particular agent instance behaves--how to respond to events in the agent, and when to trigger the agent to initiate events. The controller might be a web or native user interface for a person or it might be coded business rules driven by an enterprise system. + +Between the two is a simple interface. The agent sends event notifications to the controller and the controller sends administrator messages to the agent. The controller registers a webhook with the agent, and the event notifications are HTTP callbacks, and the agent exposes a REST API to the controller for all of the administrative messages it is configured to handle. Each of the DIDComm protocols supported by the agent adds a set of administrative messages for the controller to use in responding to events. The Aries cloud agent includes an [OpenAPI](https://swagger.io/tools/swagger-ui/) (aka Swagger) user interface for a developer to use to explore the API for a specific agent. + +As such, the agent is just a configured dependency in an ACA-Py deployment. Thus, the vast majority of ACA-Py developers will focus on building controllers (business logic) and perhaps some custom plugins (protocols, as we'll discuss soon) for the agent. Only a relatively small group of ACA-Py maintainers will focus on adding and maintaining the agent dependency. + +Want more details about the agent and controller internals? Take a look at the [ACA_Py deployment model](../deploying/deploymentModel.md) document. + +> Back to the [ACA-Py Developer - Getting Started Guide](./README.md). +> \ No newline at end of file diff --git a/docs/gettingStarted/ACA-PyBasics.md b/docs/gettingStarted/ACA-PyBasics.md new file mode 100644 index 0000000000..4f22e310a3 --- /dev/null +++ b/docs/gettingStarted/ACA-PyBasics.md @@ -0,0 +1,15 @@ +# What is ACA-Py? + +ACA-Py is a shared, reusable, interoperable tool kit designed for initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials. It is infrastructure for trusted, decentralized, peer-to-peer interactions. It includes a shared secure storage and a key management service for clients, as well as communication protocols for trusted interaction between agents. + +An ACA-Py agent (such as the one in this repository): + +* enables establishing connections with other DIDComm-based agents (using DIDComm encryption envelopes), +* exchanges messages between connected agents to execute message protocols using DIDComm and other protocols, +* sends notifications about protocol events to a controller, and +* exposes an API for responses from the controller with direction in handling protocol events. + +The some of the concepts and features that make up the ACA-Py project are documented in the [aries-rfcs](https://github.com/hyperledger/aries-rfcs) - but **don't** dive in there yet! We'll get to the features and concepts to be found there with a guided tour of the key RFCs. + +> Back to the [ACA-Py Developer - Getting Started Guide](./README.md). +> \ No newline at end of file diff --git a/docs/gettingStarted/ACA-PyBigPicture.md b/docs/gettingStarted/ACA-PyBigPicture.md new file mode 100644 index 0000000000..7b7b8a67f6 --- /dev/null +++ b/docs/gettingStarted/ACA-PyBigPicture.md @@ -0,0 +1,24 @@ +# ACA-Py Agents in context: The Big Picture + +ACA-Py agents can be used in a lot of places. This classic Indy Architecture picture shows five agents - the four around the outside (on a phone, a tablet, a laptop and an enterprise server) are referred to as "edge agents", and many cloud agents in the blue circle. + +![image](https://cryptocalibur.com/wp-content/uploads/2018/06/sovrin-ico-3-600x402.png) + +The agents in the picture shares many attributes: + +- They have some sort of storage for keys and other data related to their role as an agent +- They interact with other agents using secure, peer-to-peer messaging protocols +- They have some associated mechanism to provide "business rules" to control the behavior of the agent + - That is often a person for phone, tablet, laptop, etc. based agents + - That is often backend enterprise systems for enterprise agents + - Business rules for cloud agents are often about the routing of messages to and from edge agents + +While there can be many other agent setups, the picture above shows the most common ones - mobile wallets for people, edge agents for organizations and cloud agents for routing messages (although cloud agents could be edge agents. Sigh...). A significant emerging use case missing from that picture are agents embedded within/associated with IoT devices. In the common IoT case, IoT device agents are just variants of other edge agents, connected to the rest of the ecosystem through a cloud agent. All the same principles apply. + +Misleading in the picture is that (almost) all agents connect directly to the verifiable data repository. In this picture it's the Sovrin ledger, but that could be any ledger (e.g. set of nodes running ledger software) or non-ledger based verifiable data repositories -- such as web servers. That implies most agents embed a verifiable data registry client (usually, a DID Resolver) that makes calls to one or more types of verifiable data registries. Thus, unlike what is implied in the picture, edge agents (commonly) do not call a cloud agent to interact with the verifiable data registry - they do it directly. Super small IoT devices might be an exception to that - lacking compute/storage resources and/or connectivity, they might communicate with a cloud agent that would communicate with the verifiable data registry. + +The three most common purposes of cloud agents are verifiable credential issuers, verifiers and "mediators" -- agents that route messages to mobile wallets that lack a persistent endpoint. For the latter, rather than messages going directly to mobile wallet (which is often impossible - for example sending to a mobile wallet), messages intended for the agent are routed through a mediator who hold the messages until the agent picks up its messages. + +We also recommend **not** digging into all the layers described here. Just as you don't have to know how TCP/IP works to write a web app, you don't need to know how ledgers or the various protocols work to be able to build your first ACA-Py-based application. Later in this guide we'll covering the starting point you do need to know. + +> Back to the [ACA-Py Developer - Getting Started Guide](./README.md). diff --git a/docs/gettingStarted/AriesDeveloperDemos.md b/docs/gettingStarted/ACA-PyDeveloperDemos.md similarity index 84% rename from docs/gettingStarted/AriesDeveloperDemos.md rename to docs/gettingStarted/ACA-PyDeveloperDemos.md index 338498f69a..1160db2770 100644 --- a/docs/gettingStarted/AriesDeveloperDemos.md +++ b/docs/gettingStarted/ACA-PyDeveloperDemos.md @@ -1,6 +1,6 @@ -# Developer Demos and Samples of Aries Agent +# Developer Demos and Samples of ACA-Py Agent -Here are some demos that developers can use to get up to speed on Aries. You don't have to be a developer to use these. If you can use docker and JSON, then that's enough to give these a try. +Here are some demos that developers can use to get up to speed on ACA-Py. You don't have to be a developer to use these. If you can use docker and JSON, then that's enough to give these a try. ## Open API demo @@ -24,7 +24,7 @@ verifiable credential experience in 30 minutes or less. ## Indicio Developer Demo -Minimal Aca-Py demo that can be used by developers to isolat and test features: +Minimal Aca-Py demo that can be used by developers to isolate and test features: - Minimal Setup (everything runs in containers) - Quickly reproduce an issue or demonstrate a feature by writing one simple script or pytest tests. diff --git a/docs/gettingStarted/AgentConnections.md b/docs/gettingStarted/AgentConnections.md index 97605f32ec..ee8776bee6 100644 --- a/docs/gettingStarted/AgentConnections.md +++ b/docs/gettingStarted/AgentConnections.md @@ -1,9 +1,9 @@ -# Establishing a connection between Aries Agents +# Establishing a connection between ACA-Py Agents -Use an ACA-Py issuer/verifier to establish a connection with an Aries mobile +Use an ACA-Py issuer/verifier to establish a connection with a compatible mobile wallet. Run the [Traction AnonCreds Workshop]. Get your own (temporary -- it -will be gone in a few weeks!) Aries Cloud Agent Python-based issuer/verifier +will be gone in a few weeks!) ACA-Py-based issuer/verifier agent. Connect to the wallet on your mobile phone, issue a credential and then present it back. Lots to learn, without ever leaving your browser! -[Traction AnonCreds Workshop]: https://github.com/bcgov/traction/blob/main/docs/traction-anoncreds-workshop.md +[Traction AnonCreds Workshop]: ../demo/Aries-Workshop.md diff --git a/docs/gettingStarted/AriesAgentArchitecture.md b/docs/gettingStarted/AriesAgentArchitecture.md deleted file mode 100644 index 51399118df..0000000000 --- a/docs/gettingStarted/AriesAgentArchitecture.md +++ /dev/null @@ -1,16 +0,0 @@ -# Aries Cloud Agent Internals: Agent and Controller - -This section talks in particular about the architecture of this Aries cloud agent implementation. An instance of an Aries agent is actually made up of to two parts - the agent itself and a controller. - -![ACA-Py Deployment Overview](../assets/deploymentModel-full.png "ACA-Py Deployment Overview") - -The agent handles all of the core Aries functionality such as interacting with other agents, managing secure storage, sending event notifications to, and receiving directions from, the controller. The controller provides the business logic that defines how that particular agent instance behaves--how to respond to events in the agent, and when to trigger the agent to initiate events. The controller might be a web or native user interface for a person or it might be coded business rules driven by an enterprise system. - -Between the two is a simple interface. The agent sends event notifications to the controller and the controller sends administrator messages to the agent. The controller registers a webhook with the agent, and the event notifications are HTTP callbacks, and the agent exposes a REST API to the controller for all of the administrative messages it is configured to handle. Each of the DIDComm protocols supported by the agent adds a set of administrative messages for the controller to use in responding to events. The Aries cloud agent includes an [OpenAPI](https://swagger.io/tools/swagger-ui/) (aka Swagger) user interface for a developer to use to explore the API for a specific agent. - -As such, the agent is just a configured dependency in an Aries cloud agent deployment. Thus, the vast majority of Aries developers will focus on building controllers (business logic) and perhaps some custom plugins (protocols, as we'll discuss soon) for the agent. Only a relatively small group of Aries cloud agent maintainers will focus on adding and maintaining the agent dependency. - -Want more details about the agent and controller internals? Take a look at the [Aries cloud agent deployment model](../deploying/deploymentModel.md) document. - -> Back to the [Aries Developer - Getting Started Guide](./README.md). -> \ No newline at end of file diff --git a/docs/gettingStarted/AriesBasics.md b/docs/gettingStarted/AriesBasics.md deleted file mode 100644 index f8693df7dc..0000000000 --- a/docs/gettingStarted/AriesBasics.md +++ /dev/null @@ -1,17 +0,0 @@ -# What is Aries? - -[Hyperledger Aries](https://www.hyperledger.org/projects/aries) provides a shared, reusable, interoperable tool kit designed for initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials. It is infrastructure for blockchain-rooted, peer-to-peer interactions. It includes a shared cryptographic wallet for blockchain clients as well as a communications protocol for allowing off-ledger interaction between those clients. - -A Hyperledger Aries agent (such as the one in this repository): - -* enables establishing connections with other DIDComm-based agents (using DIDComm encryption envelopes), -* exchanges messages between connected agents to execute message protocols (using DIDComm protocols) -* sends notifications about protocol events to a controller, and -* exposes an API for responses from the controller with direction in handling protocol events. - -The concepts and features that make up the Aries project are documented in the [aries-rfcs](https://github.com/hyperledger/aries-rfcs) - but **don't** dive in there yet! We'll get to the features and concepts to be found there with a guided tour of the key RFCs. The [Aries Working Group](https://wiki.hyperledger.org/display/ARIES/Aries+Working+Group) meets weekly to expand the design and components of Aries. - -The Aries Cloud Agent Python currently only supports Hyperledger Indy-based verifiable credentials and public ledger. Longer term (as we'll see later in this guide) protocols will be extended or added to support other verifiable credential implementations and public ledgers. - -> Back to the [Aries Developer - Getting Started Guide](./README.md). -> \ No newline at end of file diff --git a/docs/gettingStarted/AriesBigPicture.md b/docs/gettingStarted/AriesBigPicture.md deleted file mode 100644 index 982ff3f6ad..0000000000 --- a/docs/gettingStarted/AriesBigPicture.md +++ /dev/null @@ -1,28 +0,0 @@ -# Aries Agents in context: The Big Picture - -Aries agents can be used in a lot of places. This classic Indy Architecture picture shows five agents - the four around the outside (on a phone, a tablet, a laptop and an enterprise server) are referred to as "edge agents", and many cloud agents in the blue circle. - -![image](https://cryptocalibur.com/wp-content/uploads/2018/06/sovrin-ico-3-600x402.png) - -The agents in the picture shares many attributes: - -- They have some sort of storage for keys and other data related to their role as an agent -- They interact with other agents using secure. peer-to-peer messaging protocols -- They have some associated mechanism to provide "business rules" to control the behavior of the agent - - That is often a person for phone, tablet, laptop, etc. based agents - - That is often backend enterprise systems for enterprise agents - - Business rules for cloud agents are often about the routing of messages to and from edge agents - -While there can be many other agent setups, the picture above shows the most common ones - edge agents for people, edge agents for organizations and cloud agents for routing messages (although cloud agents could be edge agents. Sigh...). A significant emerging use case missing from that picture are agents embedded within/associated with IoT devices. In the common IoT case, IoT device agents are just variants of other edge agents, connected to the rest of the ecosystem through a cloud agent. All the same principles apply. - -Misleading in the picture is that (almost) all agents connect directly to the Ledger network. In this picture it's the Sovrin ledger, but that could be any Indy network (e.g. set of nodes running indy-node software) and in future, ledgers from other providers. That implies most agents embed the ledger SDK (e.g. indy-sdk) and makes calls to the ledger SDK to interact with the ledger and other SDK controlled resources (e.g. secure storage). Thus, unlike what is implied in the picture, edge agents (commonly) do not call a cloud agent to interact with the ledger - they do it directly. Super small IoT devices are an instance of an exception to that - lacking compute/storage resources and/or connectivity, they might communicate with a cloud agent that would communicate with the ledger. - -While current Aries agents currently only support Indy-based ledgers, the intention is to add support for other ledgers. - -The (most common) purpose of cloud agents is to enable secure and privacy preserving routing of messages between edge agents. Rather than messages going directly from edge agent to edge agent (which is often impossible - for example sending to a mobile agent), messages sent from edge agent to edge agent are routed through a sequence of cloud agents. Some of those cloud agents might be controlled by the sender, some by the receiver and others might be gateways owned by agent vendors (called "Agencies"). In all cases, an edge agent tells routing agents "here's how to send messages to me", so a routing agent sending a message only has to know how to send a peer-to-peer message. While quite complicated, the protocols used by the agents largely take care of this complexity, and most developers don't have to know much about it. - -Note the many caveats in this section - "most common", "commonly", etc. There are many small building blocks available in Aries and underlying components that can be combined in infinite ways. We recommend not worrying about the alternate use cases for now. Focus on understanding the common use cases while remembering that other configurations are possible. - -We also recommend **not** digging into all the layers described here. Just as you don't have to know how TCP/IP works to write a web app, you don't need to know how indy-node or indy-sdk work to be able to build your first Aries-based application. Later in this guide we'll covering the starting point you do need to know. - -> Back to the [Aries Developer - Getting Started Guide](./README.md). diff --git a/docs/gettingStarted/AriesMessaging.md b/docs/gettingStarted/DIDCommMessaging.md similarity index 54% rename from docs/gettingStarted/AriesMessaging.md rename to docs/gettingStarted/DIDCommMessaging.md index c1ec2ab259..db7649ac2a 100644 --- a/docs/gettingStarted/AriesMessaging.md +++ b/docs/gettingStarted/DIDCommMessaging.md @@ -1,10 +1,10 @@ -# An overview of Aries messaging +# An overview of DIDComm messaging -Aries Agents communicate with each other via a message mechanism called DIDComm (DID Communication). DIDComm enables secure, asynchronous, end-to-end encrypted messaging between agents, with messages (usually) routed through some configuration of intermediary agents. Aries agents use (an early instance of) the [did:peer DID method](https://identity.foundation/peer-did-method-spec), which uses DIDs that are not published to a public ledger, but only shared privately between the communicating parties - usually just two agents. +ACA-Py Agents can communicate with each other via a message mechanism called DIDComm (DID Communication). DIDComm enables secure, asynchronous, end-to-end encrypted messaging between agents, with messages (usually) routed through some configuration of intermediary agents. ACA-Py agents use the [did:peer DID method](https://identity.foundation/peer-did-method-spec), which uses DIDs that are not published to a public verifiable data registry, but only shared privately between the communicating parties - usually just two agents. Given the underlying secure messaging layer (routing and encryption covered later in the "Deeper Dive" sections), DIDComm protocols define standard sets of messages to accomplish a task. For example: -* The "establish connection" protocol enables two agents to establish a connection through a series of messages - an invitation, a connection request and a connection response. +* The "DID exchange" protocol enables two agents to establish a connection through a series of messages - an invitation, a connection request and a connection response. * The "issue credential" protocol enables an agent to issue a credential to another agent. * The "present proof" protocol enables an agent to request and receive a proof from another agent. @@ -12,7 +12,7 @@ Each protocol has a specification that defines the protocol's messages, one or m Code for protocols are implemented as externalized modules from the core agent code so that they can be included (or not) in an agent deployment. The protocol code must include the definition of a state object for the protocol, handlers for the protocol messages, and the events and administrative messages that are available to the controller to inject business logic into the running of the protocol. Each administrative message becomes part of the REST API exposed by the agent instance. -Developers building Aries agents for a particular use case will generally focus on building controllers. They must understand the protocols that they are going to need, including the events the controller will receive, and the protocol's administrative messages exposed via the REST API. From time to time, such Aries agent developers might need to implement their own protocols. +Developers building ACA-Py agents for a particular use case will generally focus on building controllers. They must understand the protocols that they are going to need, including the events the controller will receive, and the protocol's administrative messages exposed via the REST API. From time to time, such Aries agent developers might need to implement their own protocols. -> Back to the [Aries Developer - Getting Started Guide](./README.md). +> Back to the [ACA-Py Developer - Getting Started Guide](./README.md). > diff --git a/docs/gettingStarted/AriesRoutingExample.md b/docs/gettingStarted/DIDCommRoutingExample.md similarity index 94% rename from docs/gettingStarted/AriesRoutingExample.md rename to docs/gettingStarted/DIDCommRoutingExample.md index c3914c6cbd..8d105d82da 100644 --- a/docs/gettingStarted/AriesRoutingExample.md +++ b/docs/gettingStarted/DIDCommRoutingExample.md @@ -1,6 +1,7 @@ -# Aries Routing - an example +# DIOComm Routing - an example -In this example, we'll walk through an example of complex routing in Aries, outlining some of the possibilities that can be implemented. +In this example, we'll walk through an example of complex DIDComm routing, outlining some of the possibilities that can be implemented. Do realize that +the vast majority of the work is already done for you if you are just using ACA-Py. You have to define the setup your agents will use, and ACA-Py will take care of all the messy details described below. We'll start with the Alice and Bob example from the [Cross Domain Messaging](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0094-cross-domain-messaging) Aries RFC. diff --git a/docs/gettingStarted/DIDcommMsgs.md b/docs/gettingStarted/DIDcommMsgs.md index 05be2639cd..b0c247f50c 100644 --- a/docs/gettingStarted/DIDcommMsgs.md +++ b/docs/gettingStarted/DIDcommMsgs.md @@ -1,11 +1,11 @@ # Deeper Dive: DIDComm Messaging -DIDComm peer-to-peer messages are asynchronous messages that one agent sends to another - for example, Faber would send to Alice. In between, there may be other agents and message processing, but at the edges, Faber appears to be messaging directly with Alice using encryption based on the DIDs and DIDDocs that the two shared when establishing a connection. The messages are JSON-LD-friendly messages with a "type" that defines the namespace, protocol, protocol version and type of the message, an "id" that is GUID for the message, and additional fields as required by the message type. The namespace is currently defined to be a public DID that should be globally resolvable to a protocol specification. Currently, "core" messages use a DID that is not yet globally resolvable - Daniel Hardman has the keys associated with the DID. +DIDComm peer-to-peer messages are asynchronous messages that one agent sends to another - for example, Faber would send to Alice. In between, there may be other agents and message processing, but at the edges, Faber appears to be messaging directly with Alice using encryption based on the DIDs and DIDDocs that the two shared when establishing a connection. The messages are JSON-LD-friendly messages with a "type" that defines the namespace, protocol, protocol version and type of the message, an "id" that is GUID for the message, and additional fields as required by the message type. -Link: [Message Types](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0020-message-types/README.md) +Link: [Message Types](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0020-message-types/README.md) As protocols are executed, the data associated with the protocol is stored in the (currently named) wallet of the agent. The data primarily consists of the state object for that instance of the protocol, and any artifacts of running the protocol. For example, when establishing a connection, the metadata associated with the connection (DIDs, DID Documents and private keys) is stored in the agent's wallet. Likewise, ledger data is cached in the wallet (DIDs, schema, credential definitions, etc.) and credentials. This is taken care of by the Aries agent and the protocols configured into the agent. ## Message Decorators -In addition to protocol specific data elements in messages, messages can include "decorators", standardized message elements that define cross-cutting behavior. The most common example is the "thread" decorator, which is used to link the messages in a protocol instance. As messages go back and forth between agents to complete an instance of a protocol (e.g. issuing a credential), the [thread decorator](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0008-message-id-and-threading) data elements let the agents know to which protocol instance the message belongs. Other currently defined examples of decorators include [attachments](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0017-attachments), [localization](https://github.com/hyperledger/aries-rfcs/blob/master/features/0043-l10n/README.md), [tracing](https://github.com/hyperledger/aries-rfcs/blob/master/features/0034-message-tracing/README.md) and [timing](https://github.com/hyperledger/aries-rfcs/blob/master/features/0032-message-timing/README.md). Decorators are often processed by the core of the agent, but some are processed by the protocol message handlers. For example, the thread decorator processed to retrieve the protocol state object for that instance (thread) of the protocol before control is passed to the protocol message handler. +In addition to protocol specific data elements in messages, messages can include "decorators", standardized message elements that define cross-cutting behavior. The most common example is the "thread" decorator, which is used to link the messages in a protocol instance. As messages go back and forth between agents to complete an instance of a protocol (e.g. issuing a credential), the [thread decorator](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0008-message-id-and-threading) data elements let the agents know to which protocol instance the message belongs. Other currently defined examples of decorators include [attachments](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0017-attachments), [localization](https://github.com/hyperledger/aries-rfcs/blob/main/features/0043-l10n/README.md), [tracing](https://github.com/hyperledger/aries-rfcs/blob/main/features/0034-message-tracing/README.md) and [timing](https://github.com/hyperledger/aries-rfcs/blob/main/features/0032-message-timing/README.md). Decorators are often processed by the core of the agent, but some are processed by the protocol message handlers. For example, the thread decorator processed to retrieve the protocol state object for that instance (thread) of the protocol before control is passed to the protocol message handler. diff --git a/docs/gettingStarted/DecentralizedIdentityDemos.md b/docs/gettingStarted/DecentralizedIdentityDemos.md index c46fb398e5..269a0db8c8 100644 --- a/docs/gettingStarted/DecentralizedIdentityDemos.md +++ b/docs/gettingStarted/DecentralizedIdentityDemos.md @@ -14,10 +14,10 @@ verifiable credential experience in 30 minutes or less. Now that you have a wallet, how about being an issuer, and experience what is needed on that side of an exchange? To do that, try the [Traction AnonCreds Workshop]. Get your own (temporary -- it will be gone in a few weeks!) -Aries Cloud Agent Python-based issuer/verifier agent. Connect to the wallet on your mobile phone, issue a credential +ACA-Py-based issuer/verifier agent. Connect to the wallet on your mobile phone, issue a credential and then present it back. Lots to learn, without ever leaving your browser! -[Traction AnonCreds Workshop]: https://github.com/bcgov/traction/blob/main/docs/traction-anoncreds-workshop.md +[Traction AnonCreds Workshop]: ../demo/Aries-Workshop.md ## More demos, please diff --git a/docs/gettingStarted/IndyACA-PyDevOptions.md b/docs/gettingStarted/IndyACA-PyDevOptions.md new file mode 100644 index 0000000000..b45fa5b4e9 --- /dev/null +++ b/docs/gettingStarted/IndyACA-PyDevOptions.md @@ -0,0 +1,33 @@ +# What should I work on? Options for ACA-Py/Indy Developers + +Now that you know the basics of the ACA-Py/Indy eco-system, what do you want to work on? There are many projects at different levels of the eco-system you could choose to work on, and many ways to contribute to the community. + +This is an important summary for newcomers, as often the temptation is to start at a level far below where you plan to focus your attention. Too often devs coming into the community start at "the blockchain"; at `indy-node` (the Indy public ledger) or the `indy-sdk`. That is far below where the majority of developers will work and is not really that helpful if what you really want to do is build decentralized identity applications. + +In the following, we go through the layers from the top of the stack to the bottom. Our expectation is that the majority of developers will work at the application level, and there will be fewer contributing developers each layer down you go. This is not to dissuade anyone from contributing at the lower levels, but rather to say if you are not going to contribute at the lower levels, you don't need to everything about it. It's much like web development - you don't need to know TCP/IP to build web apps. + +## Building Decentralized Identity Applications + +If you just want to build enterprise applications on top of the decentralized identity-related Hyperledger projects, you can start with building cloud-based controller apps using any language you want, and deploying your code with an instance of the code in the [ACA-Py repository](https://github.com/openwallet-foundation/acapy). + +If you want to build a mobile agent, there are open source options available, including [Bifold Wallet](https://github.com/openwallet-foundation/bifold-wallet), which is built on [Credo-TS](https://github.com/openwallet-foundation/credo-ts). Both are OpenWallet Projects. + +As a developer building applications that use/embed ACA-Py agents, you should join the [Aries Working Group](https://wiki.hyperledger.org/display/ARIES/Aries+Working+Group)'s weekly calls and watch the [aries-rfcs](https://github.com/hyperledger/aries-rfcs) repo to see what protocols are being added and extended. In some cases, you may need to create your own protocols to be added to this repository, and if you are looking for interoperability, you should specify those protocols in an open way, involving the community. + +Note that if building apps is what you want to do, you don't need to do a deep dive into the inner workings of ACA-Py, ledgers or mobile wallets. You need to know the concepts, but it's not a requirement that you know the code base intimately. + +## Contributing to ACA-Py + +Of course as you build applications using ACA-Py, you will no doubt find deficiencies in the code and features you want added. Contributions to this repo will **always** be welcome. + +## Supporting Additional Ledgers + +ACA-Py currently supports a handful of public verifiable data registries and verifiable credentials exchange. A project goals to be "ledger"-agnostic, and to support a range of verifiable data registries. We're making it easier and easier to support other verifiable data registries, and would welcome assistance in adding new ones. + +## Other Agent Frameworks + +Although controllers for an ACA-Py instance can be written in any language, there is definitely a place for functionality equivalent (and better) to what is in this repo in other languages. Use the example provided by the ACA-Py demo, evolve that using a different language, and as you discover better ways to do things, discuss and share those improvements in the broader ACA-Py community so that this and other code bases improve. + +## Working at the Cryptographic Layer + +Finally, at the deepest level, and core to all of the projects is the cryptography underpinning ACA-Py. If you are a cryptographer, that's where you want to be - and we want you there. diff --git a/docs/gettingStarted/IndyAriesDevOptions.md b/docs/gettingStarted/IndyAriesDevOptions.md deleted file mode 100644 index 9416b6ddc4..0000000000 --- a/docs/gettingStarted/IndyAriesDevOptions.md +++ /dev/null @@ -1,45 +0,0 @@ -# What should I work on? Options for Aries/Indy Developers - -Now that you know the basics of the Indy/Aries eco-system, what do you want to work on? There are many projects at different levels of the eco-system you could choose to work on, and many ways to contribute to the community. - -This is an important summary for newcomers, as often the temptation is to start at a level far below where you plan to focus your attention. Too often devs coming into the community start at "the blockchain"; at `indy-node` (the Indy public ledger) or the `indy-sdk`. That is far below where the majority of developers will work and is not really that helpful if what you really want to do is build decentralized identity applications. - -In the following, we go through the layers from the top of the stack to the bottom. Our expectation is that the majority of developers will work at the application level, and there will be fewer contributing developers each layer down you go. This is not to dissuade anyone from contributing at the lower levels, but rather to say if you are not going to contribute at the lower levels, you don't need to everything about it. It's much like web development - you don't need to know TCP/IP to build web apps. - -## Building Decentralized Identity Applications - -If you just want to build enterprise applications on top of the decentralized identity-related Hyperledger projects, you can start with building cloud-based controller apps using any language you want, and deploying your code with an instance of the code in this repository ([aries-cloudagent-python](https://github.com/hyperledger/aries-cloudagent-python)). - -If you want to build a mobile agent, there are open source options available, including [Aries-MobileAgent-Xamarin](https://github.com/hyperledger/aries-mobileagent-xamarin) (aka "Aries MAX"), which is built on [Aries Framework .NET](https://github.com/hyperledger/aries-framework-dotnet), and [Aries Mobile Agent React Native](https://github.com/hyperledger/aries-mobile-agent-react-native), which is built on [Aries Framework JavaScript](https://github.com/hyperledger/aries-framework-javascript). - -As a developer building applications that use/embed Aries agents, you should join the [Aries Working Group](https://wiki.hyperledger.org/display/ARIES/Aries+Working+Group)'s weekly calls and watch the [aries-rfcs](https://github.com/hyperledger/aries-rfcs) repo to see what protocols are being added and extended. In some cases, you may need to create your own protocols to be added to this repository, and if you are looking for interoperability, you should specify those protocols in an open way, involving the community. - -Note that if building apps is what you want to do, you don't need to do a deep dive into the Aries SDK, the Indy SDK or the Indy Node public ledger. You need to know the concepts, but it's not a requirement that know the code base intimately. - -## Contributing to `aries-cloudagent-python` - -Of course as you build applications using `aries-cloudagent-python`, you will no doubt find deficiencies in the code and features you want added. Contributions to this repo will **always** be welcome. - -## Supporting Additional Ledgers - -`aries-cloudagent-python` currently supports only Hyperledger Indy-based public ledgers and verifiable credentials exchange. A goal of Hyperledger Aries is to be ledger-agnostic, and to support other ledgers. We're experimenting with adding support for other ledgers, and would welcome assistance in doing that. - -## Other Agent Frameworks - -Although controllers for an `aries-cloudagent-python` instance can be written in any language, there is definitely a place for functionality equivalent (and better) to what is in this repo in other languages. Use the example provided by the `aries-cloudagent-python`, evolve that using a different language, and as you discover better ways to do things, discuss and share those improvements in the broader Aries community so that this and other codebases improve. - -## Improving Aries SDK - -This code base and other Aries agent implementations currently embed the `indy-sdk`. However, much of the code in the `indy-sdk` is being migrated into a variety of Aries language specific repositories. How this migration is to be done is still being decided, but it makes sense that the agent-type things be moved to Aries repositories. A number of [language specific Aries SDK](https://github.com/hyperledger?utf8=%E2%9C%93&q=aries+sdk&type=&language=) repos have been created and are being populated. - -## Improving the Indy SDK - -Dropping down a level from Aries and into Indy, the [indy-sdk](https://github.com/hyperledger/indy-sdk) needs to continue to evolve. The code base is robust, of high quality and well thought out, but it needs to continue to add new capabilities and improve existing features. The `indy-sdk` is implemented in Rust, to produce a C-callable library that can be used by client libraries built in a variety of languages. - -## Improving Indy Node - -If you are interested in getting into the public ledger part of Indy, particularly if you are going to be a Sovrin Steward, you should take a deep look into [indy-node](https://github.com/hyperledger/indy-node). Like the `indy-sdk`, `indy-node` is robust, of high quality and is well thought out. As the network grows, use cases change and new cryptographic primitives move into the mainstream, `indy-node` capabilities will need to evolve. `indy-node` is coded in Python. - -## Working in Cryptography - -Finally, at the deepest level, and core to all of the projects is the cryptography in [Hyperledger Ursa](https://github.com/hyperledger/ursa). If you are a cryptographer, that's where you want to be - and we want you there. diff --git a/docs/gettingStarted/IndyBasics.md b/docs/gettingStarted/IndyBasics.md index b20b973733..95a7a5dacc 100644 --- a/docs/gettingStarted/IndyBasics.md +++ b/docs/gettingStarted/IndyBasics.md @@ -1,15 +1,15 @@ # Indy, Verifiable Credentials and Decentralized Identity Basics -> **NOTE:** If you are developer building apps on top of Aries and Indy, you **DO NOT** need to know the nuts and bolts of Indy to build applications. You need to know about verifiable credentials and the concepts of self-sovereign identity. But as an app developer, you don't need to do the Indy getting started pieces. Aries takes care of those details for you. The introduction linked here should be sufficient. +> **NOTE:** If you are developer building apps on top of ACA-Py and Indy, you **DO NOT** need to know the nuts and bolts of Indy to build applications. You need to know about verifiable credentials and the concepts of self-sovereign identity. But as an app developer, you don't need to do the Indy getting started pieces. ACA-Py takes care of those details for you. The introduction linked here should be sufficient. If you are new to Indy and verifiable credentials and want to learn the core concepts, this [link](https://github.com/hyperledger/education/blob/master/LFS171x/docs/introduction-to-hyperledger-indy.md) provides a solid foundation into the goals and purpose of Indy including verifiable credentials, DIDs, decentralized/self-sovereign identity, the Sovrin Foundation and more. The document is the content of the Indy chapter of the Hyperledger edX [Blockchain for Business](https://www.edx.org/course/blockchain-for-business-an-introduction-to-hyperledger-technologies) course (which you could also go through). -Feel free to do the demo that is referenced in the material, but we recommend that you **not** dig into that codebase. It's pretty old now - almost a year! We've got much more relevant examples later in this guide. +Feel free to do the demo that is referenced in the material, but we recommend that you **not** dig into that codebase. It's pretty old now - year old! We've got much more relevant examples later in this guide. -As well, **don't** use the guidance in the course to dive into the content about "Getting Started" with Indy. Come back here as this content is far more relevant to the current state of Indy and Aries. +As well, **don't** use the guidance in the course to dive into the content about "Getting Started" with Indy. Come back here as this content is far more relevant to the current state of Indy and ACA-Py. ## tl;dr Indy provides an implementation of the basic functions required to implement a network for self-sovereign identity (SSI) - a ledger, client SDKs for interacting with the ledger, DIDs, and capabilities for issuing, holding and proving verifiable credentials. -> Back to the [Aries Developer - Getting Started Guide](./README.md). +> Back to the [ACA-Py Developer - Getting Started Guide](./README.md). diff --git a/docs/gettingStarted/IssuingAnonCredsCredentials.md b/docs/gettingStarted/IssuingAnonCredsCredentials.md index 8fe7c50e6c..dd84fd61e5 100644 --- a/docs/gettingStarted/IssuingAnonCredsCredentials.md +++ b/docs/gettingStarted/IssuingAnonCredsCredentials.md @@ -2,7 +2,7 @@ Become an issuer, and define, publish and issue verifiable credentials to a mobile wallet. Run the [Traction AnonCreds Workshop]. Get your own (temporary -- it will be gone in a few weeks!) -Aries Cloud Agent Python-based issuer/verifier agent. Connect to the wallet on your mobile phone, issue a credential +ACA-Py-based issuer/verifier agent. Connect to the wallet on your mobile phone, issue a credential and then present it back. Lots to learn, without ever leaving your browser! -[Traction AnonCreds Workshop]: https://github.com/bcgov/traction/blob/main/docs/traction-anoncreds-workshop.md +[Traction AnonCreds Workshop]: ../demo/Aries-Workshop.md diff --git a/docs/gettingStarted/PresentingAnonCredsProofs.md b/docs/gettingStarted/PresentingAnonCredsProofs.md index 76beba1236..08b501776d 100644 --- a/docs/gettingStarted/PresentingAnonCredsProofs.md +++ b/docs/gettingStarted/PresentingAnonCredsProofs.md @@ -3,9 +3,9 @@ Become a verifier, and construct a presentation request, send the request to a mobile wallet, get a presentation derived from AnonCreds verifiable credentials and verify the presentation. Run the [Traction AnonCreds Workshop]. Get your own -(temporary -- it will be gone in a few weeks!) Aries Cloud Agent Python-based +(temporary -- it will be gone in a few weeks!) ACA-Py-based issuer/verifier agent. Connect to the wallet on your mobile phone, issue a credential and then present it back. Lots to learn, without ever leaving your browser! -[Traction AnonCreds Workshop]: https://github.com/bcgov/traction/blob/main/docs/traction-anoncreds-workshop.md +[Traction AnonCreds Workshop]: ../demo/Aries-Workshop.md diff --git a/docs/gettingStarted/README.md b/docs/gettingStarted/README.md index ef5859970a..b4c3a153ed 100644 --- a/docs/gettingStarted/README.md +++ b/docs/gettingStarted/README.md @@ -1,27 +1,27 @@ -# Becoming an Indy/Aries Developer +# Becoming an ACA-Py Developer -This guide is to get you from (pretty much) zero to developing code for issuing (and verifying) credentials with your own Aries agent. On the way, you'll look at Hyperledger Indy and how it works, find out about the architecture and components of an Aries agent and its underlying messaging protocols. Scan the list of topics below and jump in as soon as you hit a topic you don't know. +This guide is to get you from (pretty much) zero to developing code for issuing (and verifying) credentials with your own ACA-Py agent. On the way, you'll look at Hyperledger Indy and how it works, find out about the architecture and components of an ACA-Py agent and its underlying messaging protocols. Scan the list of topics below and jump in as soon as you hit a topic you don't know. Note that in the guidance we have here, we include not only the links to look at, but we recommend that you **not** look at certain material to which you might naturally gravitate. That's because the material is out of date and will take you down some unnecessary rabbit holes. Keep your eyes on the goal - developing with Aries to interact with other agents to (amongst other things) connect, issue, hold, present and verify verifiable credentials. * [I've heard of Indy, but I don't know the basics](IndyBasics.md) -* [I know about Indy, but what is Aries?](AriesBasics.md) +* [I know about Indy, but what is ACA-Py?](ACA-PyBasics.md) * [Demos - Business Level](DecentralizedIdentityDemos.md) -* [Aries Agents in Context: The Big Picture](AriesBigPicture.md) -* [Aries Internals - Deployment Components](AriesAgentArchitecture.md) -* [An overview of Aries messaging](AriesMessaging.md) -* [Demos - Aries Developer](AriesDeveloperDemos.md) -* [Establishing a connection between Aries Agents](AgentConnections.md) +* [ACA-Py Agents in Context: The Big Picture](ACA-PyBigPicture.md) +* [ACA-Py Internals - Deployment Components](ACA-PyAgentArchitecture.md) +* [An overview of DIDComm messaging](DIDCommMessaging.md) +* [Demos - ACA-Py Developer](ACA-PyDeveloperDemos.md) +* [Establishing a connection between ACA-Py Agents](AgentConnections.md) * [Issuing an AnonCreds credential: From Issuer to Holder/Prover](IssuingAnonCredsCredentials.md) -* [Presenting an Indy credential: From Holder/Prover to Verifier](PresentingAnonCredsProofs.md) -* [Next steps: Creating your own Aries Agent](YourOwnAriesAgent.md) -* [What should I work on? Options for Aries/Indy Developers](IndyAriesDevOptions.md) +* [Presenting an AnonCreds credential: From Holder/Prover to Verifier](PresentingAnonCredsProofs.md) +* [Next steps: Creating your own ACA-Py Agent](YourOwnACA-PyAgent.md) +* [What should I work on? Options for ACA-Py/Indy Developers](IndyACA-PyDevOptions.md) * [Deeper Dive: DIDComm Messages](DIDcommMsgs.md) * [Deeper Dive: DIDComm Message Routing and Encryption](RoutingEncryption.md) -* [Deeper Dive: Routing Example](AriesRoutingExample.md) +* [Deeper Dive: DIDComm Routing Example](DIDCommRoutingExample.md) * To Do: [Deeper Dive: Running and Connecting to an Indy Network](ConnectIndyNetwork.md) -* [Steps and APIs to support credential revocation with Aries agent](CredentialRevocation.md) -* [Deeper Dive: Aca-Py Plug-Ins](../features/PlugIns.md) +* [Steps and APIs to support credential revocation with ACA-Py agent](CredentialRevocation.md) +* [Deeper Dive: ACA-Py Plug-Ins](../features/PlugIns.md) Want to help with this guide? Please add issues or submit a pull request to improve the document. Point out things that are missing, things to improve and especially things that are wrong. diff --git a/docs/gettingStarted/RoutingEncryption.md b/docs/gettingStarted/RoutingEncryption.md index 93b8207668..94bfcfc159 100644 --- a/docs/gettingStarted/RoutingEncryption.md +++ b/docs/gettingStarted/RoutingEncryption.md @@ -32,6 +32,6 @@ Link: [Mediators and Relays](https://github.com/hyperledger/aries-rfcs/tree/mast ## Message Encryption -The DIDComm encryption handling is handling within the Aries agent, and not really something a developer building applications using an agent needs to worry about. Further, within an Aries agent, the handling of the encryption is left to libraries to handle - ultimately calling dependencies from Hyperledger Ursa. To encrypt a message, the agent code calls a `pack()` function to handle the encryption, and to decrypt a message, the agent code calls a corresponding `unpack()` function. The "wire messages" (as originally called) are described in [detail here](https://github.com/hyperledger/aries-rfcs/blob/master/features/0019-encryption-envelope/README.md), including variations for sender authenticated and anonymous encrypting. Wire messages were meant to indicate the handling of a message from one agent directly to another, versus the higher level concept of routing a message from an edge agent to a peer edge agent. +The DIDComm encryption handling is handling within the ACA-Py agent, and not really something a developer building applications using an agent needs to worry about. Further, within an ACA-Py agent, the handling of the encryption is left to various cryptographic libraries to handle. To encrypt a message, the agent code calls a `pack()` function to handle the encryption, and to decrypt a message, the agent code calls a corresponding `unpack()` function. The "wire messages" (as originally called) are described in [detail here](https://github.com/hyperledger/aries-rfcs/blob/master/features/0019-encryption-envelope/README.md), including variations for sender authenticated and anonymous encrypting. Wire messages were meant to indicate the handling of a message from one agent directly to another, versus the higher level concept of routing a message from an edge agent to a peer edge agent. Much thought has also gone into repudiable and non-repudiable messaging, as [described here](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0049-repudiation). diff --git a/docs/gettingStarted/YourOwnAriesAgent.md b/docs/gettingStarted/YourOwnACA-PyAgent.md similarity index 100% rename from docs/gettingStarted/YourOwnAriesAgent.md rename to docs/gettingStarted/YourOwnACA-PyAgent.md diff --git a/docs/index.rst b/docs/index.rst index bb997d2876..4f62157cef 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -1,53 +1,52 @@ -.. Aries Cloud Agent Python documentation master file, created by +.. ACA-Py documentation main file, created by sphinx-quickstart on Thu Jun 27 12:41:28 2019. You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. -Aries Cloud Agent Python Code Documentation +ACA-Py Code Documentation =================================================== -Hyperledger Aries Cloud Agent Python (ACA-Py) is a foundation for building decentralized -identity applications and services running in non-mobile environments. +ACA-Py is a foundation for building decentralized +trust applications and services running in non-mobile environments. -This is the Read The Docs site for the Hyperledger -`Aries Cloud Agent Python `_. +This is the Read The Docs site for the OpenWallet Foundation's +`ACA-Py `_. This site contains only the ACA-Py docstrings documentation -extracted from the Python Code. For other documentation, please consult the links -in the Readme for the `ACA-Py `_ -GitHub Repo. +extracted from the Python Code. For other documentation, please consult +the `ACA-Py `_ documentation site. -If you are getting started with verifiable credentials or Aries, +If you are getting started with verifiable credentials or ACA-Py, we recommend that you start with this `verifiable credentials and agents getting started guide -`_. +`_. Want to quick overview of the deployment model for ACA-Py? See -`this document `_. +`this document `_. To investigate the code, use search or click the package links in the left menu to drill into the modules, subpackages and submodules that make up ACA-Py. Developers that are interested in what DIDComm protocols are supported in ACA-Py -should take a look at the `protocols `_ package. +should take a look at the `protocols `_ package. These should align with the corresponding `aries-rfcs protocols `_. Decorators defined in aries-rfcs and implemented in ACA-Py can be found -`here `_. +`here `_. Some general purpose subpackages that might be of interest include -`wallet `_ and -`storage `_. For those +`wallet `_ and +`storage `_. For those agents playing different roles in a verifiable credential exchange, take a look -at the `issuer `_, -`holder `_ and -`verifier `_ packages. +at the `issuer `_, +`holder `_ and +`verifier `_ packages. Please see the `ACA-Py Contribution guidelines -`_ +`_ for how to contribute to ACA-Py, including for how to submit issues about ACA-Py. .. toctree:: :maxdepth: 3 - :caption: Aries Cloud Agent Python - Modules + :caption: ACA-Py - Modules generated/modules diff --git a/docs/testing/AgentTracing.md b/docs/testing/AgentTracing.md index 2c2dabd218..2c99e53eee 100644 --- a/docs/testing/AgentTracing.md +++ b/docs/testing/AgentTracing.md @@ -1,6 +1,6 @@ # Using Tracing in ACA-PY -The aca-py agent supports message tracing, according to the [Tracing RFC](https://github.com/hyperledger/aries-rfcs/tree/master/features/0034-message-tracing). +ACA-Py supports message tracing, according to the [Tracing RFC](https://github.com/hyperledger/aries-rfcs/tree/master/features/0034-message-tracing). Tracing can be enabled globally, for all messages/events, or it can be enabled on an exchange-by-exchange basis. @@ -85,7 +85,7 @@ When `Exchange Tracing` is `ON`, all exchanges will include tracing. ## Logging Trace Events to an ELK Stack -You can use the `ELK` stack in the [ELK Stack sub-directory](https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/elk-stack) as a target for trace events, just start the ELK stack using the docker-compose file and then in two separate bash shells, startup the demo as follows: +You can use the `ELK` stack in the [ELK Stack sub-directory](https://github.com/openwallet-foundation/acapy/blob/main/demo/elk-stack) as a target for trace events, just start the ELK stack using the docker-compose file and then in two separate bash shells, startup the demo as follows: ```bash DOCKER_NET=elknet TRACE_TARGET_URL=logstash:9700 ./run_demo faber --trace-http diff --git a/docs/testing/BDDTests.md b/docs/testing/BDDTests.md index dad1955b6c..4a3107f534 100644 --- a/docs/testing/BDDTests.md +++ b/docs/testing/BDDTests.md @@ -1,14 +1,15 @@ -# Integration Tests for Aca-py using Behave +# Integration Tests for ACA-Py using Behave -Integration tests for aca-py are implemented using Behave functional tests to drive aca-py agents based on the alice/faber demo framework. +Integration tests for ACA-Py are implemented using Behave functional tests to drive ACA-Py agents based on the alice/faber demo framework. -If you are new to the ACA-Py integration test suite, this [video](https://youtu.be/AbuPg4J8Pd4) from ACA-Py Maintainer @ianco describes +If you are new to the ACA-Py integration test suite, this [video](https://youtu.be/AbuPg4J8Pd4) from ACA-Py Maintainer [@ianco](https://github.com/ianco) describes the Integration Tests in ACA-Py, how to run them and how to add more tests. See also the video at the end of this document about running -Aries Agent Test Harness tests before you submit your pull requests. +[Aries Agent Test Harness](https://github.com/hyperledger/aries-agent-test-harness) (AATH) tests before you submit your pull requests. Note +that the relevant AATH tests are now run as part of the tests run when submitting a code PR for ACA-Py. ## Getting Started -To run the aca-py Behave tests, open a bash shell run the following: +To run the ACA-Py Behave tests, open a bash shell run the following: ```bash git clone https://github.com/bcgov/von-network @@ -21,19 +22,22 @@ cd indy-tails-server/docker ./manage build ./manage start cd ../.. -git clone https://github.com/hyperledger/aries-cloudagent-python -cd aries-cloudagent-python/demo +git clone "https://github.com/openwallet-foundation/acapy" +cd acapy/demo ./run_bdd -t ~@taa_required ``` Note that an Indy ledger and tails server are both required (these can also be specified using environment variables). -Note also that some tests require a ledger with TAA enabled, how to run these tests will be described later. +Note also that some tests require a ledger with Indy the "TAA" (Transaction +Author Agreement) concept enabled, how to run these tests will be described +later. -By default the test suite runs using a default (SQLite) wallet, to run the tests using postgres run the following: +By default the test suite runs using a default (SQLite) wallet, to run the tests +using postgres run the following: ```bash -# run the above commands, up to cd aries-cloudagent-python/demo +# run the above commands, up to cd acapy/demo docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d -p 5432:5432 postgres:10 ACAPY_ARG_FILE=postgres-indy-args.yml ./run_bdd ``` @@ -87,7 +91,7 @@ AGENT_PORT_OVERRIDE=8030 ./run_bdd -t ### Note on BBS Signatures -ACA-Py does not come installed with the `bbs` library by default therefore integation tests involving BBS signatures (tagged with @BBS) will fail unless excluded. +ACA-Py does not come installed with the `bbs` library by default therefore integration tests involving BBS signatures (tagged with @BBS) will fail unless excluded. You can exclude BBS tests from running with the tag `~@BBS`: @@ -103,9 +107,9 @@ If you want to run all tests including BBS tests you should include the `--all-e Note: The `bbs` library may not install on ARM (i.e. aarch64 or arm64) architecture therefore YMMV with testing BBS Signatures on ARM based devices. -## Aca-py Integration Tests vs Aries Agent Test Harness (AATH) +## ACA-Py Integration Tests vs Aries Agent Test Harness (AATH) -Aca-py Behave tests are based on the interoperability tests that are implemented in the [Aries Agent Test Harness (AATH)](https://github.com/hyperledger/aries-agent-test-harness). Both use [Behave (Gherkin)](https://behave.readthedocs.io/en/stable/) to execute tests against a running aca-py agent (or in the case of AATH, against any compatible Aries agent), however the aca-py integration tests focus on aca-py specific features. +ACA-Py Behave tests are based on the interoperability tests that are implemented in the [Aries Agent Test Harness (AATH)](https://github.com/hyperledger/aries-agent-test-harness). Both use [Behave (Gherkin)](https://behave.readthedocs.io/en/stable/) to execute tests against a running ACA-Py agent (or in the case of AATH, against any compatible Aries agent), however the ACA-Py integration tests focus on ACA-Py specific features. AATH: @@ -114,19 +118,21 @@ AATH: - Runs Aries agents using Docker images (agents run for the duration of the tests) - Uses a standard "backchannel" to support integration of any Aries agent -Aca-py integration tests: +As of around the publication of ACA-Py 1.0.0 (Summer 2024), the ACA-Py CI/CD Pipeline for code PRs includes running a useful subset of AATH tests. -- Main purpose is to test aca-py +ACA-Py integration tests: + +- Main purpose is to test ACA-Py - Implements tests based on Aries RFC's, but not to the level of detail as AATH (runs (mostly) happy path scenarios against multiple agent configurations) -- Tests aca-py specific configurations and features -- Starts and stops agents for each tests to test different aca-py configurations +- Tests ACA-Py specific configurations and features that go beyond Aries. +- Starts and stops agents for each tests to test different ACA-Py configurations - Uses the same Python framework as used for the interactive Alice/Faber demo ## Configuration-driven Tests -Aca-py integration tests use the same configuration approach as AATH, documented [here](https://github.com/hyperledger/aries-agent-test-harness/blob/master/CONFIGURE-CRED-TYPES.md). +ACA-Py integration tests use the same configuration approach as AATH, documented [here](https://github.com/hyperledger/aries-agent-test-harness/blob/master/CONFIGURE-CRED-TYPES.md). -In addition to support for external schemas, credential data etc, the aca-py integration tests support configuration of the aca-py agents that are used to run the test. For example: +In addition to support for external schemas, credential data etc, the ACA-Py integration tests support configuration of the ACA-Py agents that are used to run the test. For example: ```behave Scenario Outline: Present Proof where the prover does not propose a presentation of the proof and is acknowledged @@ -149,9 +155,9 @@ In the above example, the test will run twice using the parameters specified in The agent's "capabilities" are specified using the same command-line parameters that are supported for the Alice/Faber demo agents. -## Global Configuration for All Aca-py Agents Under Test +## Global Configuration for All ACA-Py Agents Under Test -You can specify parameters that are applied to all aca-py agents using the `ACAPY_ARG_FILE` environment variable, for example: +You can specify parameters that are applied to all ACA-Py agents using the `ACAPY_ARG_FILE` environment variable, for example: ```bash ACAPY_ARG_FILE=postgres-indy-args.yml ./run_bdd @@ -167,22 +173,22 @@ ACAPY_ARG_FILE=askar-indy-args.yml ./run_bdd ... will run all the tests against an askar wallet (the new shared components, which replace indy-sdk). -Any aca-py argument can be included in the yml file, and order-of-precedence applies (see [https://pypi.org/project/ConfigArgParse/](https://pypi.org/project/ConfigArgParse/)). +Any ACA-Py argument can be included in the yml file, and order-of-precedence applies (see [https://pypi.org/project/ConfigArgParse/](https://pypi.org/project/ConfigArgParse/)). ## Specifying Environment Parameters when Running Integration Tests -Aca-py integration tests support the following environment-driven configuration: +ACA-Py integration tests support the following environment-driven configuration: - `LEDGER_URL` - specify the ledger url - `TAILS_NETWORK` - specify the docker network the tails server is running on - `PUBLIC_TAILS_URL` - specify the public url of the tails server -- `ACAPY_ARG_FILE` - specify global aca-py parameters (see above) +- `ACAPY_ARG_FILE` - specify global ACA-Py parameters (see above) ## Running specific test scenarios Behave tests are tagged using the same [standard tags as used in AATH](https://github.com/hyperledger/aries-agent-test-harness#test-tags). -To run a specific set of Aca-py integration tests (or exclude specific tests): +To run a specific set of ACA-Py integration tests (or exclude specific tests): ```bash ./run_bdd -t tag1 -t ~tag2 @@ -192,4 +198,4 @@ To run a specific set of Aca-py integration tests (or exclude specific tests): ## Aries Agent Test Harness ACA-Py Tests -This [video](https://youtu.be/1dwyEBxQqWI) is a presentation by Aries Cloud Agent Python (ACA-Py) developer @ianco about using the Aries Agent Test Harness for local pre-release testing of ACA-Py. Have a big change that you want to test with other Aries Frameworks? Following this guidance to run AATH tests with your under-development branch of ACA-Py. +This [video](https://youtu.be/1dwyEBxQqWI) is a presentation by ACA-Py developer [@ianco](https://github.com/ianco) about using the Aries Agent Test Harness for local pre-release testing of ACA-Py. Have a big change that you want to test with other Aries Frameworks? Following this guidance to run AATH tests with your under-development branch of ACA-Py. diff --git a/docs/testing/IntegrationTests.md b/docs/testing/IntegrationTests.md index 338c455074..7406c33461 100644 --- a/docs/testing/IntegrationTests.md +++ b/docs/testing/IntegrationTests.md @@ -8,11 +8,11 @@ Integration testing in ACA-Py consists of 3 different levels or types. ## Interop profile (AATH) BDD tests -Interoperability is extremely important in the aries community. When implementing or changing features that are included in the [aries interop profile](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0302-aries-interop-profile/README.md) the developer should try to add tests to this test suite. +Interoperability is extremely important in the decentralized trust/SSI community. for example, when implementing or changing features that are included in the [Aries Interop Profile](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0302-aries-interop-profile/README.md) the developer should try to add tests to this test suite. These tests are contained in a separate repo [AATH](https://github.com/hyperledger/aries-agent-test-harness). They use the gherkin syntax and a http back channel. Changes to the tests need to be added and merged into this repo before they will be reflected in the automatic testing workflows. There has been a lot of work to make developing and debugging tests easier. See (AATH Dev Containers)[https://github.com/hyperledger/aries-agent-test-harness/blob/main/AATH_DEV_CONTAINERS.md#dev-containers-in-aath]. -The tests will then be ran for PR's and scheduled workflows for ACA-Py <--> ACA-Py agents. These tests are important because having them allows the AATH project to more easily test credo-ts <--> ACA-Py scenarios and ensure interoperability with mobile agents interacting with python agents. +The tests will then be ran for PR's and scheduled workflows for ACA-Py <--> ACA-Py agents. These tests are important because having them allows the AATH project to more easily test [Credo-TS](https://github.com/openwallet-foundation/credo-ts) <--> ACA-Py scenarios and ensure interoperability with mobile agents interacting with ACA-Py agents. ## ACA-Py specific BDD tests diff --git a/docs/testing/Logging.md b/docs/testing/Logging.md index bc9f7e7a54..b0104d4dd3 100644 --- a/docs/testing/Logging.md +++ b/docs/testing/Logging.md @@ -1,6 +1,6 @@ # Logging docs -ACA_Py supports multiple configurations of logging. +ACA-Py supports multiple configurations of logging. ## Log level @@ -21,9 +21,9 @@ Supports writing of log messages to a file with `wallet_id` as the tenant identi Example: ```sh -./bin/aca-py start --log-level debug --log-file acapy.log --log-config aries_cloudagent.config:default_per_tenant_logging_config.ini +./bin/aca-py start --log-level debug --log-file acapy.log --log-config acapy_agent.config:default_per_tenant_logging_config.ini -./bin/aca-py start --log-level debug --log-file --multitenant --log-config ./aries_cloudagent/config/default_per_tenant_logging_config.yml +./bin/aca-py start --log-level debug --log-file --multitenant --log-config ./acapy_agent/config/default_per_tenant_logging_config.yml ``` ## Environment Variables @@ -38,9 +38,9 @@ Example: ACAPY_LOG_LEVEL=info ACAPY_LOG_FILE=./acapy.log ACAPY_LOG_CONFIG=./acapy_log.ini ./bin/aca-py start ``` -## Acapy Config File +## ACA-Py Config File -Following parameters can be used in a configuration file like [this](https://github.com/hyperledger/aries-cloudagent-python/tree/main/demo/demo-args.yaml). +Following parameters can be used in a configuration file like [this](https://github.com/openwallet-foundation/acapy/tree/main/demo/demo-args.yaml). ```yaml log-level: WARNING @@ -56,11 +56,11 @@ Also if log-level is set to WARNING, connections and presentations will be logge The path to config file is provided via `--log-config`. -Find an example in [default_logging_config.ini](https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/config/default_logging_config.ini). +Find an example in [default_logging_config.ini](https://github.com/openwallet-foundation/acapy/tree/main/acapy_agent/config/default_logging_config.ini). You can find more detail description in the [logging documentation](https://docs.python.org/3/howto/logging.html#configuring-logging). -For per tenant logging, find an example in [default_per_tenant_logging_config.ini](https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/config/default_per_tenant_logging_config.ini), which sets up `TimedRotatingFileMultiProcessHandler` and `StreamHandler` handlers. Custom `TimedRotatingFileMultiProcessHandler` handler supports the ability to cleanup logs by time and maintain backup logs and a custom JSON formatter for logs. The arguments for it such as `file name`, `when`, `interval` and `backupCount` can be passed as `args=('acapy.log', 'd', 7, 1,)` (also shown below). Note: `backupCount` of 0 will mean all backup log files will be retained and not deleted at all. More details about these attributes can be found [here](https://docs.python.org/3/library/logging.handlers.html#timedrotatingfilehandler) +For per tenant logging, find an example in [default_per_tenant_logging_config.ini](https://github.com/openwallet-foundation/acapy/tree/main/acapy_agent/config/default_per_tenant_logging_config.ini), which sets up `TimedRotatingFileMultiProcessHandler` and `StreamHandler` handlers. Custom `TimedRotatingFileMultiProcessHandler` handler supports the ability to cleanup logs by time and maintain backup logs and a custom JSON formatter for logs. The arguments for it such as `file name`, `when`, `interval` and `backupCount` can be passed as `args=('acapy.log', 'd', 7, 1,)` (also shown below). Note: `backupCount` of 0 will mean all backup log files will be retained and not deleted at all. More details about these attributes can be found [here](https://docs.python.org/3/library/logging.handlers.html#timedrotatingfilehandler) ```ini [loggers] @@ -92,7 +92,7 @@ args=('acapy.log', 'd', 7, 1,) format=%(asctime)s %(wallet_id)s %(levelname)s %(pathname)s:%(lineno)d %(message)s ``` -For `DictConfig` (`dict` logging config file), find an example in [default_per_tenant_logging_config.yml](https://github.com/hyperledger/aries-cloudagent-python/tree/main/aries_cloudagent/config/default_per_tenant_logging_config.yml) with same attributes as `default_per_tenant_logging_config.ini` file. +For `DictConfig` (`dict` logging config file), find an example in [default_per_tenant_logging_config.yml](https://github.com/openwallet-foundation/acapy/tree/main/aries_cloudagent/config/default_per_tenant_logging_config.yml) with same attributes as `default_per_tenant_logging_config.ini` file. ```yaml version: 1 diff --git a/docs/testing/Troubleshooting.md b/docs/testing/Troubleshooting.md index cdd3321e06..5545015e5e 100644 --- a/docs/testing/Troubleshooting.md +++ b/docs/testing/Troubleshooting.md @@ -1,4 +1,4 @@ -# Troubleshooting Aries Cloud Agent Python +# Troubleshooting ACA-Py This document contains some troubleshooting information that contributors to the community think may be helpful. Most of the content here assumes the reader has @@ -47,11 +47,11 @@ We have discovered that in the ACA-Py AnonCreds implementation, it is possible to get into a state where the publishing of updates to a Revocation Registry (RevReg) is impossible. This can happen where ACA-Py starts to publish an update to the RevReg, but the write transaction to the Hyperledger Indy ledger fails -for some reason. When a credential revocation is published, aca-py (via indy-sdk +for some reason. When a credential revocation is published, ACA-Py (via indy-sdk or askar/credx) updates the revocation state in the wallet as well as on the ledger. The revocation state is dependant on whatever the previous revocation state is/was, so if the ledger and wallet are mis-matched the publish will fail. -(Andrew/s PR # 1804 (merged) should mitigate but probably won't completely +([PR #1804](https://github.com/openwallet-foundation/acapy/issues/1804) (merged) mitigates but probably doesn't completely eliminate this from happening). For example, in case we've seen, the write RevRegEntry transaction failed at the @@ -93,11 +93,11 @@ will be retained for use if needed. We originally ran into this due to the TAA acceptance getting lost when switching to multi-ledger (as described -[here](https://github.com/hyperledger/aries-cloudagent-python/blob/main/Multiledger.md#a-special-warning-for-taa-acceptance). +[here](../features/Multiledger.md#a-special-warning-for-taa-acceptance). Note that this is one reason how this "out of sync" scenario can occur, but there may be others. -We add an integration test that demonstrates/tests this issue [here](https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/features/taa-txn-author-acceptance.feature#L67). +We add an integration test that demonstrates/tests this issue [here](https://github.com/openwallet-foundation/acapy/blob/main/demo/features/taa-txn-author-acceptance.feature#L67). To run the scenario either manually or using the integration tests, you can do the following: diff --git a/docs/testing/UnitTests.md b/docs/testing/UnitTests.md index cc7d9f49f0..776611405d 100644 --- a/docs/testing/UnitTests.md +++ b/docs/testing/UnitTests.md @@ -2,8 +2,7 @@ The following covers the Unit Testing framework in ACA-Py, how to run the tests, and how to add unit tests. -This [video](https://youtu.be/yJ6LpAiVNFM) is a presentation of the material covered in this document by -developer @shaangill025. +This [video](https://youtu.be/yJ6LpAiVNFM) is a presentation of the material covered in this document. ## Running unit tests in ACA-Py @@ -20,7 +19,7 @@ Note: The `bbs` library may not install on ARM (i.e. aarch64 or arm64) architec ## Pytest -Example: aries_cloudagent/core/tests/test_event_bus.py +Example: acapy_agent/core/tests/test_event_bus.py ```python @pytest.fixture @@ -129,7 +128,7 @@ async def notify(self, profile: "Profile", event: Event): ## asynctest -From: aries_cloudagent/protocols/didexchange/v1_0/tests/test.manager.py +From: acapy_agent/protocols/didexchange/v1_0/tests/test.manager.py ```python class TestDidExchangeManager(AsyncTestCase, TestConfig): diff --git a/mkdocs.yml b/mkdocs.yml index 8e5008b093..0f8593cb94 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,6 +1,6 @@ -site_name: Hyperledger Aries ACA-Py Docs -repo_name: hyperledger/aries-cloudagent-python -repo_url: https://github.com/hyperledger/aries-cloudagent-python +site_name: ACA-Py Docs +repo_name: openwallet-foundation/acapy +repo_url: https://github.com/openwallet-foundation/acapy theme: name: material custom_dir: overrides @@ -103,32 +103,32 @@ nav: - Code Generation with the Open API: features/UsingOpenAPI.md - ACA-Py as a DIDComm Mediator: features/Mediation.md - Demos: - - Hyperledger Aries / AnonCreds Workshop: demo/Aries-Workshop.md + - ACA-Py / AnonCreds Workshop: demo/ACA-Py-Workshop.md - The Alice-Faber Demo: demo/README.md - - Open API Tutorial: demo/AriesOpenAPIDemo.md + - Open API Tutorial: demo/OpenAPIDemo.md - Alice Gets a Phone: demo/AliceGetsAPhone.md - Hyperledger Indy Endorser In Action: demo/Endorser.md - Using W3C JSON-LD Credentials: demo/AliceWantsAJsonCredential.md - DIY -- ACME Controller Workshop: demo/AcmeDemoWorkshop.md - - Aries Using Postman Demo: demo/AriesPostmanDemo.md + - ACA-Py Using Postman Demo: demo/PostmanDemo.md - Reusing a Connection Between Agents: demo/ReusingAConnection.md - Getting Started: - - Becoming an Indy/Aries Developer: gettingStarted/README.md + - Becoming an ACA-Py Developer: gettingStarted/README.md - Hyperledger Indy Basics: gettingStarted/IndyBasics.md - - Hyperledger Aries Basics: gettingStarted/AriesBasics.md + - ACA-Py Basics: gettingStarted/ACA-PyBasics.md - Decentralized Identity Demos: gettingStarted/DecentralizedIdentityDemos.md - - Aries - The Big Picture: gettingStarted/AriesBigPicture.md - - Aries Architecture: gettingStarted/AriesAgentArchitecture.md - - Aries Messaging: gettingStarted/AriesMessaging.md - - Aries Developer Demos: gettingStarted/AriesDeveloperDemos.md + - ACA-Py - The Big Picture: gettingStarted/ACA-PyBigPicture.md + - ACA-Py Architecture: gettingStarted/ACA-PyAgentArchitecture.md + - ACA-Py Messaging: gettingStarted/DIDCommMessaging.md + - ACA-Py Developer Demos: gettingStarted/ACA-PyDeveloperDemos.md - Agent Connections: gettingStarted/AgentConnections.md - Issuing AnonCreds Credentials: gettingStarted/IssuingAnonCredsCredentials.md - Presenting AnonCreds Proofs: gettingStarted/PresentingAnonCredsProofs.md - - Making Your Own ACA-Py Agent: gettingStarted/YourOwnAriesAgent.md - - Aries Developer Options: gettingStarted/IndyAriesDevOptions.md + - Making Your Own ACA-Py Agent: gettingStarted/YourOwnACA-PyAgent.md + - ACA-Py Developer Options: gettingStarted/IndyACA-PyDevOptions.md - DIDComm Messaging: gettingStarted/DIDcommMsgs.md - DIDComm Message Routing: gettingStarted/RoutingEncryption.md - - DIDComm Message Routing Example: gettingStarted/AriesRoutingExample.md + - DIDComm Message Routing Example: gettingStarted/DIDCommRoutingExample.md - TODO Connecting to an Indy Network: gettingStarted/ConnectIndyNetwork.md - AnonCreds Credential Revocation: gettingStarted/CredentialRevocation.md - Deploying: @@ -152,7 +152,7 @@ nav: - Contributing: - How to Contribute: CONTRIBUTING.md - Maintainers: MAINTAINERS.md - - Hyperledger Code of Conduct: CODE_OF_CONDUCT.md + - Code of Conduct: CODE_OF_CONDUCT.md - Security Vulnerability Reporting: SECURITY.md - Publishing an ACA-Py Release: PUBLISHING.md - Managing the ACA-Py Documentation Site: Managing-ACA-Py-Doc-Site.md diff --git a/scripts/genChangeLog.sh b/scripts/genChangeLog.sh index 0af5322bd4..75a1b004c7 100755 --- a/scripts/genChangeLog.sh +++ b/scripts/genChangeLog.sh @@ -23,11 +23,11 @@ gh pr list -S "merged:>${1}" -L 1000 --state merged --json number,title,author sed -e "s/\\\t/ /g" \ -e "s/\"//g" \ -e "s/WwW /\[\\\#/" \ - -e "s# XxX #\\](https://github.com/hyperledger/aries-cloudagent-python/pull/#" \ + -e "s# XxX #\\](https://github.com/openwallet-foundation/acapy/pull/#" \ -e "s/ YyY /) \\[/" \ -e "s# ZzZ #\\](https://github.com/#" \ -e "s/$/)/" \ -e "/app.dependabot/d" now=$(date +%Y-%m-%d) echo "- Dependabot PRs" -echo " - [Link to list of Dependabot PRs in this release](https://github.com/hyperledger/aries-cloudagent-python/pulls?q=is%3Apr+is%3Amerged+merged%3A${1}..${now}+author%3Aapp%2Fdependabot+)" +echo " - [Link to list of Dependabot PRs in this release](https://github.com/openwallet-foundation/acapy/pulls?q=is%3Apr+is%3Amerged+merged%3A${1}..${now}+author%3Aapp%2Fdependabot+)" diff --git a/scripts/generate-open-api-spec b/scripts/generate-open-api-spec index 91578a8659..7a56e95bcf 100755 --- a/scripts/generate-open-api-spec +++ b/scripts/generate-open-api-spec @@ -100,7 +100,7 @@ function buildACAPyDockerImage() { } # Start an ACA-py docker image -# A simplified version of aries-cloudagent-python/scripts/run_docker +# A simplified version of acapy/scripts/run_docker # needed to run without tty or interactive. # $1: The ACA-py docker image to use (i.e either from a repo or local) # $2: The port mapping from docker to local host in format "docker1:local1 docker2:local2"