Sonivijayk/fix/issue 2319 docs update to remove indy usage (#3997)

* docs: remove indy wallet usage from README.md (issue 2319)

Signed-off-by: Vijay Soni <vijaysoni@sonivijay.com>

* docs: removed indy sdk reference from Present the Proof section of AliceGetsAPhone.md (issue 2319)

Signed-off-by: Vijay Soni <vijaysoni@sonivijay.com>

* removed did:sov from AliceWantsAJsonCredential.md

Signed-off-by: Vijay Soni <vijaysoni@sonivijay.com>

* replaced did:sov example with did:peer in ReusingAConnection.md

Signed-off-by: Vijay Soni <vijaysoni@sonivijay.com>

* Removed indy sdk image reference from container docs

Signed-off-by: Vijay Soni <vijaysoni@sonivijay.com>

* Updated deploymentModel.md storage wording

Signed-off-by: Vijay Soni <vijaysoni@sonivijay.com>

* Replaced did:sov kid with did:key in SD-JWT example

Signed-off-by: Vijay Soni <vijaysoni@sonivijay.com>

* Added clarification on Askar storage support in SupportedRFCs.md

Signed-off-by: Vijay Soni <vijaysoni@sonivijay.com>

* Removed did:sov info from JsonLdCredentials.md

Signed-off-by: Vijay Soni <vijaysoni@sonivijay.com>

* Minor change to remove did:sov from Registering a DID method section

Signed-off-by: Vijay Soni <vijaysoni@sonivijay.com>

---------

Signed-off-by: Vijay Soni <vijaysoni@sonivijay.com>
Co-authored-by: Vijay Soni <vijaysoni@sonivijay.com>
Co-authored-by: jamshale <31809382+jamshale@users.noreply.github.com>

Author: 3 people

docs/demo/AliceGetsAPhone.md

@@ -357,7 +357,7 @@ The presentation (proof) request should automatically show up in the mobile agen
 
 If the mobile agent is able to successfully prepare and send the proof, you can go back to the Play with Docker terminal to see the status of the proof.
 
-The process should "just work" for the non-revocation use case. If you are using revocation, your results may vary. As of writing this, we get failures on the wallet side with some mobile wallets, and on the Faber side with others (an error in the Indy SDK). As the results improve, we'll update this. Please let us know through GitHub issues if you have any problems running this.
+The process should "just work" for the non-revocation use case. If you are using revocation, your results may vary. As of writing this, we get failures on the wallet side with some mobile wallets, and on the Faber side with others. As the results improve, we'll update this. Please let us know through GitHub issues if you have any problems running this.
 
 ## Review the Proof
 

docs/demo/AliceWantsAJsonCredential.md

@@ -41,14 +41,11 @@ Now open up two browser windows to the [Faber](http://localhost:8021/api/doc) an
 
 Using the Faber admin api, you have to create a DID with the appropriate:
 
-- DID method ("key" or "sov")
-  - if you use DID method "sov" you must use key type "ed25519"
+- DID method ("key")
 - Either one of the following key types:
   - "ed25519" (corresponding to signature types "Ed25519Signature2018" or "Ed25519Signature2020")
   - "bls12381g2" (corresponding to signature type "BbsBlsSignature2020")
 
-Note that "did:sov" must be a public DID (i.e. registered on the ledger) but "did:key" is not.
-
 For example, in Faber's swagger page call the `/wallet/did/create` endpoint with the following payload:
 
 ```json

docs/demo/README.md

@@ -460,19 +460,14 @@ You can also run the demo against a postgres database using the following:
 
 (Obviously you need to be running a postgres database - the command to start postgres is in the yml file provided above.)
 
-You can tweak the number of credentials issued using the `--count` and `--batch` parameters, and you can run against an Askar database using the `--wallet-type askar` option (or run using indy-sdk using `--wallet-type indy`).
+You can tweak the number of credentials issued using the `--count` and `--batch` parameters, and you can run against an Askar database using the `--wallet-type askar` option.
 
 An example full set of options is:
 
 ``` bash
 ./run_demo performance --arg-file demo/postgres-indy-args.yml -c 10000 -b 10 --wallet-type askar
 ```
 
-Or:
-
-``` bash
-./run_demo performance --arg-file demo/postgres-indy-args.yml -c 10000 -b 10 --wallet-type indy
-```
 
 ## Coding Challenge: Adding ACME
 

docs/demo/ReusingAConnection.md

@@ -25,7 +25,7 @@ Example invitation:
         "https://didcomm.org/didexchange/1.0"
     ],
     "services": [
-        "did:sov:4JiUsoK85pVkkB1bAPzFaP"
+        "did:peer:2.4JiUsoK85pVkkB1bAPzFaP4JiUsoK85pVkkB1bAPzFaP"
     ]
 }
 ```
@@ -65,8 +65,8 @@ agents (the inviter and the invitee) that establish connections with one another
 The [RFC 0434 Out of Band] protocol requirement enables `reuse` message by the
 invitee (the Wallet in the flow above) is that the `service` in the invitation
 **MUST** be a resolvable DID that is the same in all of the invitations. In the
-example invitation above, the DID is a `did:sov` DID that is resolvable on a public
-Hyperledger Indy network. The DID could also be a [Peer DID] of types 2 or 4,
+example invitation above, the DID is a `did:peer` DID that is resolvable without
+requiring a public ledger. The DID could also be a [Peer DID] of types 2 or 4,
 which encode the entire DIDDoc contents into the DID identifier (thus they are
 "resolvable DIDs"). What cannot be used is either the old "unqualified" DIDs
 that were commonly used in Aries prior to 2024, and [Peer DID] type 1. Both of
@@ -87,7 +87,7 @@ Example invitation:
         "https://didcomm.org/didexchange/1.0"
     ],
     "services": [
-        "did:sov:4JiUsoK85pVkkB1bAPzFaP"
+        "did:peer:2.4JiUsoK85pVkkB1bAPzFaP4JiUsoK85pVkkB1bAPzFaP"
     ]
 }
 ```

docs/deploying/ContainerImagesAndGithubActions.md

@@ -87,9 +87,9 @@ variants and between the BC Gov ACA-Py images.
   - Uses container's system python environment rather than `pyenv`
   - Askar and Indy Shared libraries are installed as dependencies of ACA-Py through pip from pre-compiled binaries included in the python wrappers
   - Built from repo contents
-- Indy Image (no longer produced but included here for clarity)
+- Indy Image (no longer produced; legacy reference only)
   - Based on slim variant of Debian
-  - Built from multi-stage build step (`indy-base` in the Dockerfile) which includes Indy dependencies; this could be replaced with an explicit `indy-python` image from the Indy SDK repo
+  - Built from multi-stage build step (`indy-base` in the Dockerfile) which includes Indy dependencies
   - Includes `libindy` but does **NOT** include the Indy CLI
   - Default user is `indy`
   - Uses container's system python environment rather than `pyenv`

docs/deploying/deploymentModel.md

@@ -29,8 +29,8 @@ Instances of the ACA-Py agents are configured with the following sub-components:
 - **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 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.
+- **Secure Storage Plugin** - Askar is used by the ACA-Py agent to implement secure storage. An ACA-Py agent can be configured to use a supported storage backend such as in-memory, SQLite, or Postgres at this time.
+- **Ledger Interface Plugin** - The ACA-Py agent 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
 

docs/features/DIDMethods.md

@@ -10,7 +10,7 @@ ACA-Py provides a `DIDMethods` registry holding all the DID methods supported fo
 
 ## Registering a DID method
 
-By default, ACA-Py supports `did:key` and `did:sov`.
+By default, ACA-Py supports `did:key`.
 Plugins can register DID additional methods to make them available to holders.
 Here's a snippet adding support for `did:web` to the registry from a plugin `setup` method.
 

docs/features/JsonLdCredentials.md

@@ -11,7 +11,6 @@ By design ACA-Py is credential format agnostic. This means you can use it for an
     - [Writing JSON-LD Contexts](#writing-json-ld-contexts)
   - [Signature Suite](#signature-suite)
   - [DID Method](#did-method)
-    - [`did:sov`](#didsov)
     - [`did:key`](#didkey)
 - [Issuing Credentials](#issuing-credentials)
 - [Retrieving Issued Credentials](#retrieving-issued-credentials)
@@ -83,13 +82,8 @@ Generally you should always use `BbsBlsSignature2020` as it allows the holder to
 
 Besides the JSON-LD context, we need a DID to use for issuing the credential. ACA-Py currently supports two did methods for issuing credentials:
 
-- `did:sov` - Can only be used for `Ed25519Signature2018` signature suite.
 - `did:key` - Can be used for both `Ed25519Signature2018` and `BbsBlsSignature2020` signature suites.
 
-#### `did:sov`
-
-When using `did:sov` you need to make sure to use a public did so other agents can resolve the did. It is also important the other agent is using the same indy ledger for resolving the did. You can get the public did using the `/wallet/did/public` endpoint. For backwards compatibility the did is returned without `did:sov` prefix. When using the did for issuance make sure this prepend this to the did. (so `DViYrCMPWfuLiY7LLs8giB` becomes `did:sov:DViYrCMPWfuLiY7LLs8giB`)
-
 #### `did:key`
 
 A `did:key` did is not anchored to a ledger, but embeds the key directly in the identifier part of the did. See the [did:key Method Specification](https://w3c-ccg.github.io/did-key-spec/) for more information.

docs/features/SelectiveDisclosureJWTs.md

@@ -148,7 +148,7 @@ Note that attributes in the `non_sd_list` (`given_name`, `family_name`, and `nat
   "headers": {
     "typ": "JWT",
     "alg": "EdDSA",
-    "kid": "did:sov:WpVJtxKVwGQdRpQP8iwJZy#key-1"
+    "kid": "did:key:z6Mkt3g9hU7F7Qz7fV5oHfC1H2Q8oM6QWwP5p9nX8tQm#key-1"
   },
   "payload": {
     "_sd": [
@@ -179,7 +179,7 @@ Note that attributes in the `non_sd_list` (`given_name`, `family_name`, and `nat
     "_sd_alg": "sha-256"
   },
   "valid": true,
-  "kid": "did:sov:WpVJtxKVwGQdRpQP8iwJZy#key-1",
+  "kid": "did:key:z6Mkt3g9hU7F7Qz7fV5oHfC1H2Q8oM6QWwP5p9nX8tQm#key-1",
   "disclosures": [
     [
       "xvDX00fjZferiNiPod51qQ",

docs/features/SupportedRFCs.md

@@ -84,7 +84,7 @@ A summary of the Aries Interop Profiles and Aries RFCs supported in ACA-Py can b
 
 | Secure Storage Types | Supported | Notes |
 | --- | :--: | -- |
-| [Askar] | :white_check_mark: | **DEPRECATED** - Askar provides equivalent/evolved secure storage and cryptography support to the removed "indy-wallet" part of the Indy SDK. When using Askar (via the `--wallet-type askar` startup parameter), credential handling functionality is by [CredX](https://github.com/hyperledger/indy-shared-rs) (AnonCreds) and [Indy VDR](https://github.com/hyperledger/indy-vdr) (Indy ledger interactions). |
+| [Askar] | :white_check_mark: | Askar provides secure storage and cryptography support, replacing the former "indy-wallet" component. When using Askar (via the `--wallet-type askar` startup parameter), credential handling functionality is by [CredX](https://github.com/hyperledger/indy-shared-rs) (AnonCreds) and [Indy VDR](https://github.com/hyperledger/indy-vdr) (Indy ledger interactions). |
 | [Askar]-AnonCreds | :white_check_mark: | Recommended - When using Askar/AnonCreds (via the `--wallet-type askar-anoncreds` startup parameter), AnonCreds credential handling functionality is by [AnonCreds RS](https://github.com/hyperledger/anoncreds-rs). All key management and ACA-Py storage is managed by Askar.|
 | [Kanon]-AnonCreds | :white_check_mark: | Recommended - When using Kanon/AnonCreds (via the `--wallet-type kanon-anoncreds` startup parameter), AnonCreds credential handling functionality is by [AnonCreds RS](https://github.com/hyperledger/anoncreds-rs). All key management is handled by Askar, and all other ACA-Py storage is managed by [Kanon] and the selected database management system. With [Kanon], data is encrypted at rest using the database management system's handling.|
 | [Indy SDK](https://github.com/hyperledger/indy-sdk/tree/main/docs/design/003-wallet-storage) | :x: | **Removed in ACA-Py Release 1.0.0rc5** |