Merge pull request #124 from swcurran/0.11.2

0.11.2

Author: swcurran

docs/README.md

@@ -18,7 +18,7 @@ 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/0.11.1).
+Agent-Python ReadTheDocs site](https://aries-cloud-agent-python.readthedocs.io/en/0.11.2).
 As with this site, the ReadTheDocs documentation is version specific.
 
 Got questions?

docs/contributing/PUBLISHING.md

@@ -22,8 +22,8 @@ Once ready to do a release, create a local branch that includes the following up
   - Use a command like the following, adjusting the tag parameters as
     appropriate. `docker run -it --rm -v "$(pwd)":/usr/local/src/your-app
     githubchangeloggenerator/github-changelog-generator --user hyperledger
-    --project aries-cloudagent-python --output 0.11.1.md --since-tag 0.11.0
-    --future-release 0.11.1rc2 --release-branch main --token <your-token>`
+    --project aries-cloudagent-python --output 0.11.2.md --since-tag 0.11.0
+    --future-release 0.11.2 --release-branch main --token <your-token>`
   - In the generated file, use only the PR list -- we don't include the list of
     closed issues in the Change Log.
 
@@ -101,8 +101,8 @@ Once you have the list of PRs:
 
 5. Update the version number listed in
    [pyproject.toml](pyproject.toml) and, prefixed with
-   a "v" in [open-api/openapi.json](https://github.com/hyperledger/open-api/tree/0.11.1/openapi.json) and
-   [open-api/swagger.json](https://github.com/hyperledger/open-api/tree/0.11.1/swagger.json) (e.g. "0.7.2" in the
+   a "v" in [open-api/openapi.json](https://github.com/hyperledger/open-api/tree/0.11.2/openapi.json) and
+   [open-api/swagger.json](https://github.com/hyperledger/open-api/tree/0.11.2/swagger.json) (e.g. "0.7.2" in the
    version.py file and "v0.7.2" in the openapi.json file). The incremented
    version number should adhere to the [Semantic Versioning
    Specification](https://semver.org/#semantic-versioning-specification-semver)
@@ -144,9 +144,9 @@ Once you have the list of PRs:
    Additional information about the container image publication process can be
    found in the document [Container Images and Github Actions]().
 
-[publish.yml]: https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.1/.github/workflows/publish.yml
-[publish-indy.yml]: https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.1/.github/workflows/publish-indy.yml
-[Container Images and Github Actions]: https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.1/ContainerImagesAndGithubActions.md
+[publish.yml]: https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.2/.github/workflows/publish.yml
+[publish-indy.yml]: https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.2/.github/workflows/publish-indy.yml
+[Container Images and Github Actions]: https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.2/ContainerImagesAndGithubActions.md
 
 11. Update the ACA-Py Read The Docs site by building the new "latest" (main
     branch) and activating and building the new release. Appropriate permissions

docs/demo/Endorser.md

@@ -8,7 +8,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/0.11.1/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.
+- Following the [Building and Starting](https://github.com/bcgov/von-network/blob/0.11.2/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.
 
 Start up Faber as Author (note the tails file size override, to allow testing of the revocation registry roll-over):

docs/demo/README.md

@@ -59,12 +59,12 @@ Jump to the [Follow the Script](#follow-the-script) section below for further in
 
 ### Running in Docker
 
-Running the demo in docker requires having a `von-network` (a Hyperledger Indy public ledger sandbox) instance running in docker locally. See the [VON Network Tutorial](https://github.com/bcgov/von-network/blob/0.11.1/docs/UsingVONNetwork.md) for guidance
+Running the demo in docker requires having a `von-network` (a Hyperledger Indy public ledger sandbox) instance running in docker locally. See the [VON Network Tutorial](https://github.com/bcgov/von-network/blob/0.11.2/docs/UsingVONNetwork.md) for guidance
 on starting and stopping your own local Hyperledger Indy instance.
 
 Open three `bash` shells. For Windows users, `git-bash` is highly recommended. bash is the default shell in Linux and Mac terminal sessions.
 
-In the first terminal window, start `von-network` by following the [Building and Starting](https://github.com/bcgov/von-network/blob/0.11.1/docs/UsingVONNetwork.md#building-and-starting) instructions.
+In the first terminal window, start `von-network` by following the [Building and Starting](https://github.com/bcgov/von-network/blob/0.11.2/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:
 
@@ -98,7 +98,7 @@ While that process will include the installation of the Indy python prerequisite
 
 #### Start a local Indy ledger
 
-Start a local `von-network` Hyperledger Indy network running in Docker by following the VON Network [Building and Starting](https://github.com/bcgov/von-network/blob/0.11.1/docs/UsingVONNetwork.md#building-and-starting) instructions.
+Start a local `von-network` Hyperledger Indy network running in Docker by following the VON Network [Building and Starting](https://github.com/bcgov/von-network/blob/0.11.2/docs/UsingVONNetwork.md#building-and-starting) instructions.
 
 We strongly recommend you use Docker for the local Indy network until you really, really need to know the details of running an Indy Node instance on a bare machine.
 
@@ -376,9 +376,9 @@ 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/https://github.com/hyperledger/aries-cloudagent-python/tree/0.11.1/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/blob/master/demo/https://github.com/hyperledger/aries-cloudagent-python/tree/0.11.1/demo/runners/support/agent.py#L378))
-- "Sub-wallet" API calls are handled [here](https://github.com/hyperledger/aries-cloudagent-python/blob/244194e68330835e5e2e53cc6c2993899d2437fb/demo/https://github.com/hyperledger/aries-cloudagent-python/tree/0.11.1/demo/runners/support/agent.py#L632)
+- "Base wallet" API calls are handled [here](https://github.com/hyperledger/aries-cloudagent-python/blob/244194e68330835e5e2e53cc6c2993899d2437fb/demo/https://github.com/hyperledger/aries-cloudagent-python/tree/0.11.2/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/blob/master/demo/https://github.com/hyperledger/aries-cloudagent-python/tree/0.11.2/demo/runners/support/agent.py#L378))
+- "Sub-wallet" API calls are handled [here](https://github.com/hyperledger/aries-cloudagent-python/blob/244194e68330835e5e2e53cc6c2993899d2437fb/demo/https://github.com/hyperledger/aries-cloudagent-python/tree/0.11.2/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).
 
@@ -400,15 +400,15 @@ This works exactly as the *vanilla* multi-tenancy, except that all connections a
 
 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/0.11.1/demo/runners/alice.py) and [faber.py](https://github.com/hyperledger/aries-cloudagent-python/tree/0.11.1/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/0.11.1/demo/runners/support/agent.py).
+The controllers for this demo can be found in the [alice.py](https://github.com/hyperledger/aries-cloudagent-python/tree/0.11.2/demo/runners/alice.py) and [faber.py](https://github.com/hyperledger/aries-cloudagent-python/tree/0.11.2/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/0.11.2/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 connectiing, 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/0.11.1/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/hyperledger/aries-cloudagent-python/tree/0.11.2/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:
 
@@ -449,7 +449,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/0.11.1/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/hyperledger/aries-cloudagent-python/tree/0.11.2/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".

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/0.11.1/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/hyperledger/aries-cloudagent-python/tree/0.11.2/demo/demo-args.yaml), without explicit wallet-storage, a sqlite database file is used.
 
 ```yaml
 # demo-args.yaml

docs/deploying/RedisPlugins.md

@@ -191,14 +191,14 @@ 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/0.11.1/README.md) [`redis_cache`]
+# [aries-acapy-cache-redis](https://github.com/Indicio-tech/aries-acapy-cache-redis/blob/0.11.2/README.md) [`redis_cache`]
 
 <!-- Adopted from aries-acapy-cache-redis/README.md -->
 ACA-Py uses a modular cache layer to story key-value pairs of data. The purpose
 of this plugin is to allow ACA-Py to use Redis as the storage medium for it's
 caching needs.
 
-More details can be found [here](https://github.com/Indicio-tech/aries-acapy-cache-redis/blob/0.11.1/README.md).
+More details can be found [here](https://github.com/Indicio-tech/aries-acapy-cache-redis/blob/0.11.2/README.md).
 
 ### <b>Plugin configuration</b> [`yaml`]
 ```
@@ -221,15 +221,15 @@ redis_cache:
 
 #### <b>With Docker</b>
 - Running the plugin with docker is simple and straight-forward. There is an
-example [docker-compose.yml](https://github.com/Indicio-tech/aries-acapy-cache-redis/blob/0.11.1/docker-compose.yml) file in the root of the
+example [docker-compose.yml](https://github.com/Indicio-tech/aries-acapy-cache-redis/blob/0.11.2/docker-compose.yml) file in the root of the
 project that launches both ACA-Py and an accompanying Redis instance. Running
 it is as simple as:
 
     ```sh
     $ docker-compose up --build -d
     ```
 
-- To launch ACA-Py with an accompanying redis cluster of 6 nodes [3 primaries and 3 replicas], please refer to example [docker-compose.cluster.yml](https://github.com/Indicio-tech/aries-acapy-cache-redis/blob/0.11.1/docker-compose.cluster.yml) and run the following:
+- To launch ACA-Py with an accompanying redis cluster of 6 nodes [3 primaries and 3 replicas], please refer to example [docker-compose.cluster.yml](https://github.com/Indicio-tech/aries-acapy-cache-redis/blob/0.11.2/docker-compose.cluster.yml) and run the following:
 
     Note: Cluster requires external docker network with specified subnet
 

docs/deploying/UpgradingACA-Py.md

@@ -124,6 +124,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/0.11.1/CHANGELOG.md
-[version.py]: https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.1/aries_cloudagent/version.py
-[Upgrade Definition YML file]: https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.1/aries_cloudagent/commands/default_version_upgrade_config.yml
+[CHANGELOG.md]: https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.2/CHANGELOG.md
+[version.py]: https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.2/aries_cloudagent/version.py
+[Upgrade Definition YML file]: https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.2/aries_cloudagent/commands/default_version_upgrade_config.yml

docs/features/AnoncredsProofValidation.md

@@ -2,7 +2,7 @@
 
 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/0.11.1/aries_cloudagent/indy/verifier.py#L24), and consists of:
+The list of possible verification messages can be found [here](https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.2/aries_cloudagent/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::<description of the failed validation>
 ```
 
-These validations are all performed within the [Indy verifier class](https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.1/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/hyperledger/aries-cloudagent-python/blob/0.11.2/aries_cloudagent/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:
 

docs/features/DevReadMe.md

@@ -104,7 +104,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/0.11.1/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/hyperledger/aries-cloudagent-python/tree/0.11.2/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.
 
@@ -227,7 +227,7 @@ Please also refer to the [contributing guidelines](../../contributing/CONTRIBUTI
 
 ## Publishing Releases
 
-The [publishing](https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.1/PUBLISHING.md) document provides information on tagging a release and publishing the release artifacts to PyPi.
+The [publishing](https://github.com/hyperledger/aries-cloudagent-python/blob/0.11.2/PUBLISHING.md) document provides information on tagging a release and publishing the release artifacts to PyPi.
 
 ## Dynamic Injection of Services