docs: update the references to the Cloud Agent in the documentation a…

…nd tutorials (#995)

Signed-off-by: Yurii Shynbuiev <yurii.shynbuiev@iohk.io>

docs/docusaurus/connections/connection-flow.puml

@@ -2,8 +2,8 @@
 title Connect flow
 
 actor Invitee as invitee
-participant "Invitee PRISM Agent" as inviteeAgent
-participant "Inviter PRISM Agent" as inviterAgent
+participant "Invitee Cloud Agent" as inviteeAgent
+participant "Inviter Cloud Agent" as inviterAgent
 actor Inviter as inviter
 
 == Generate and send a connection invitation ==

docs/docusaurus/connections/connection.md

@@ -14,9 +14,9 @@ The connection protocol has two roles:
 
 ## Prerequisites
 
-1. Inviter and Invitee PRISM Agents up and running
+1. Inviter and Invitee Cloud Agents up and running
 
-## PRISM Agent endpoints overview
+## Identus Cloud Agent endpoints overview
 
 The protocol uses the following REST API endpoints:
 
@@ -27,7 +27,7 @@ The protocol uses the following REST API endpoints:
 3. [`POST /connection-invitations`](/agent-api/#tag/Connections-Management/operation/acceptConnectionInvitation): Accepts an externally received invitation
 
 :::info
-Please check the full [PRISM Agent API](/agent-api) specification for more detailed information.
+Please check the full [Cloud Agent API](/agent-api) specification for more detailed information.
 :::
 
 ## Inviter Flow
@@ -79,7 +79,7 @@ The following diagram shows the end-to-end flow for establishing a connection be
 
 ## Command line example
 
-The following example demonstrates how you could use two PRISM Agent APIs to set up a connection between them.
+The following example demonstrates how you could use two Cloud Agent APIs to set up a connection between them.
 
 ### Inviter creates an invitation
 
@@ -208,5 +208,5 @@ Example response:
 ```
 
 :::info
-Please check the full [PRISM Agent API](/agent-api) specification for more detailed information.
+Please check the full [Cloud Agent API](/agent-api) specification for more detailed information.
 :::

docs/docusaurus/credentialdefinition/create.md

@@ -1,6 +1,6 @@
 # Create the Credential Definition
 
-The PRISM platform v2.0 exposes REST API for creation, fetching, and searching the [credential definition](/docs/concepts/glossary#credential-definition) records.
+The Identus Cloud Agent exposes REST API for creation, fetching, and searching the [credential definition](/docs/concepts/glossary#credential-definition) records.
 
 The OpenAPI specification and ReDoc documentation describe the endpoint.
 
@@ -12,7 +12,7 @@ The following guide demonstrates how to create a birth certificate credential de
 
 ### 1. Define the Credential Definition for the Verifiable Credential
 
-Assume you are aiming to define a credential for birth certificates. This credential definition has specific properties and ties to a schema in the PRISM platform.
+Assume you are aiming to define a credential for birth certificates. This credential definition has specific properties and ties to a schema in the Cloud Agent.
 
 Here's a sample content of the credential definition:
 
@@ -131,7 +131,7 @@ You should receive a response containing the JSON object representing the creden
 }
 ```
 
-Remember, in the PRISM platform, the combination of author, id, and version uniquely identifies each credential definition. Thus, using the same agent DID as the author, you cannot establish another credential definition with identical id and version values.
+Remember, in the Identus Cloud Agent, the combination of author, id, and version uniquely identifies each credential definition. Thus, using the same agent DID as the author, you cannot establish another credential definition with identical id and version values.
 
 ### 4. Update the Credential Definition
 

docs/docusaurus/credentialdefinition/credential-definition.md

@@ -2,13 +2,13 @@
 
 ## Abstract
 
-This document details the structure, supported formats, and technical intricacies of Anoncred Credential Definitions within the Atala PRISM Platform.
+This document details the structure, supported formats, and technical intricacies of Anoncred Credential Definitions within the Identus Platform.
 
 ## 1. Introduction
 
 An Anoncred Credential Definition serves as a standardized format for any given Anoncred Verifiable Credential. By embedding essential attributes unique to each type of credential, it lays the groundwork for diverse categories of verifiable credentials. Integrating this definition on a public blockchain ensures its availability and verifiability for all stakeholders.
 
-The PRISM Platform endorses the Anoncred Credential Definition, conforming to the [Hyperledger AnonCreds specification](https://hyperledger.github.io/anoncreds-spec/#term:schemas).
+The Identus Platform endorses the Anoncred Credential Definition, conforming to the [Hyperledger AnonCreds specification](https://hyperledger.github.io/anoncreds-spec/#term:schemas).
 
 ## 2. Anoncred Credential Definition Attributes
 
@@ -79,7 +79,7 @@ The decentralized identifier (DID) of the entity that created the credential def
 
 ### schemaId (URI)
 
-A distinct reference to retrieve the schema from the PRISM Schema Registry.
+A distinct reference to retrieve the schema from the Schema Registry.
 
 **Example:**
 ```json
@@ -118,10 +118,10 @@ Specifies if the credential definition incorporates revocation capabilities.
 
 ## Conclusion
 
-The Anoncred Credential Definition is a versatile tool that offers a standardized approach for an array of verifiable credentials. By ensuring its correct incorporation within the Atala PRISM Platform, the issuance and validation processes of various credentials can be streamlined and made more efficient.
+The Anoncred Credential Definition is a versatile tool that offers a standardized approach for an array of verifiable credentials. By ensuring its correct incorporation within the Identus Platform, the issuance and validation processes of various credentials can be streamlined and made more efficient.
 
 ## References
 
 - [Hyperledger AnonCreds specification](https://hyperledger.github.io/anoncreds-spec/#term:schemas)
 
-**Note:** Throughout the implementation phase within the PRISM platform, it's crucial to replace placeholders (such as `{{CREDENTIAL_NAME}}`, `{{VERSION_NUMBER}}`, and others) with their real, intended values.
+**Note:** Throughout the implementation phase within the Identus Platform, it's crucial to replace placeholders (such as `{{CREDENTIAL_NAME}}`, `{{VERSION_NUMBER}}`, and others) with their real, intended values.

docs/docusaurus/credentialdefinition/delete.md

@@ -2,7 +2,7 @@
 
 Unfortunately, once published (especially in the [Verifiable Data Registry (VDR)](/docs/concepts/glossary#verifiable-data-registry), deleting the credential definition becomes unfeasible.
 
-In the PRISM Platform v2.0, credential definitions aren't published to the VDR. This functionality will be incorporated in subsequent versions of the platform. Hence, the platform currently doesn't provide a REST API for deletion.
+In the Identus Platform, credential definitions aren't published to the VDR. This functionality will be incorporated in subsequent versions of the platform. Hence, the platform currently doesn't provide a REST API for deletion.
 
 If you need to `delete` the credential definition, it's advisable to contact the database administrator or directly remove it from the Postgres instance using its `guid`.
 

docs/docusaurus/credentials/anoncreds-issue-flow.puml

@@ -2,9 +2,9 @@
 title Issue flow - AnonCreds
 
 actor Holder as holder
-participant "Holder PRISM Agent" as holderAgent
+participant "Holder Cloud Agent" as holderAgent
 participant VDR
-participant "Issuer PRISM Agent" as issuerAgent
+participant "Issuer Cloud Agent" as issuerAgent
 actor Issuer as issuer
 
 note over holderAgent, issuerAgent #aqua

docs/docusaurus/credentials/anoncreds-present-proof-flow.puml

@@ -3,8 +3,8 @@ title Present Proof flow - AnonCreds
 
 participant "Verifiable\nData Registry" as L
 actor Prover as prover
-participant "Prover PRISM Agent" as proverAgent
-participant "Verifier PRISM Agent" as verifierAgent
+participant "Prover Cloud Agent" as proverAgent
+participant "Verifier Cloud Agent" as verifierAgent
 actor Verifier as verifier
 
 note over proverAgent, verifierAgent #aqua

docs/docusaurus/credentials/issue-flow.puml

@@ -2,9 +2,9 @@
 title Issue flow
 
 actor Holder as holder
-participant "Holder PRISM Agent" as holderAgent
+participant "Holder Cloud Agent" as holderAgent
 participant VDR
-participant "Issuer PRISM Agent" as issuerAgent
+participant "Issuer Cloud Agent" as issuerAgent
 actor Issuer as issuer
 
 note over holderAgent, issuerAgent #aqua

docs/docusaurus/credentials/issue.md

@@ -3,7 +3,7 @@ import TabItem from '@theme/TabItem';
 
 # Issue Credentials
 
-In Atala PRISM, the [Issue Credentials Protocol](/docs/concepts/glossary#issue-credentials-protocol) allows you to create, retrieve, and manage issued [verifiable credentials (VCs)](/docs/concepts/glossary#verifiable-credentials) between a VC issuer and a VC holder.
+In the Identus Platform, the [Issue Credentials Protocol](/docs/concepts/glossary#issue-credentials-protocol) allows you to create, retrieve, and manage issued [verifiable credentials (VCs)](/docs/concepts/glossary#verifiable-credentials) between a VC issuer and a VC holder.
 
 ## Roles
 
@@ -12,7 +12,7 @@ In the Issue Credentials Protocol, there are two roles:
 1. The [Issuer](/docs/concepts/glossary#issuer) is responsible for creating a new credential offer, sending it to a Holder, and issuing the VC once the offer is accepted.
 2. The [Holder](/docs/concepts/glossary#holder) is responsible for accepting a credential offer from an issuer and receiving the VC.
 
-The Issuer and Holder interact with the PRISM Agent API to perform the operations defined in the protocol.
+The Issuer and Holder interact with the Identus Cloud Agent API to perform the operations defined in the protocol.
 
 
 ## Prerequisites
@@ -22,24 +22,24 @@ Before using the Issuing Credentials protocol, the following conditions must be
 <Tabs groupId="vc-formats">
 <TabItem value="jwt" label="JWT">
 
-1. Issuer and Holder PRISM Agents up and running
-2. A connection must be established between the Issuer and Holder PRISM Agents (see [Connections](../connections/connection.md))
+1. Issuer and Holder Cloud Agents up and running
+2. A connection must be established between the Issuer and Holder Cloud Agents (see [Connections](../connections/connection.md))
 3. The Issuer must have a published PRISM DID, and the [DID document](/docs/concepts/glossary#did-document) must have at least one `assertionMethod` key for issuing credentials (see [Create DID](../dids/create.md) and [Publish DID](../dids/publish.md))
 4. The Holder must have a PRISM DID, and the DID document must have at least one `authentication` key for presenting the proof.
 
 </TabItem>
 <TabItem value="anoncreds" label="AnonCreds">
 
-1. Issuer and Holder PRISM Agents up and running
-2. A connection must be established between the Issuer and Holder PRISM Agents (see [Connections](../connections/connection.md))
+1. Issuer and Holder Cloud Agents up and running
+2. A connection must be established between the Issuer and Holder Cloud Agents (see [Connections](../connections/connection.md))
 3. The Issuer must have created an AnonCreds Credential Definition as described [here](../credentialdefinition/create.md).
 
 </TabItem>
 </Tabs>
 
 ## Overview
 
-The protocol described is a VC issuance process between two Atala PRISM Agents, the Issuer and the Holder.
+The protocol described is a VC issuance process between two Identus Cloud Agents, the Issuer and the Holder.
 
 The protocol consists of the following main parts:
 
@@ -65,12 +65,12 @@ The VCs issued during this protocol could represent a diploma, a certificate of
 
 
 :::info
-Please check the full [PRISM Agent API](/agent-api) specification for more detailed information.
+Please check the full [Cloud Agent API](/agent-api) specification for more detailed information.
 :::
 
 ## Issuer interactions
 
-This section describes the Issuer role's available interactions with the PRISM Agent.
+This section describes the Issuer role's available interactions with the Cloud Agent.
 
 ### Creating a Credential Offer
 
@@ -84,7 +84,7 @@ To do this, make a `POST` request to the [`/issue-credentials/credential-offers`
 2. `issuingDID`: The DID referring to the issuer to issue this credential from
 3. `connectionId`: The unique ID of the connection between the holder and the issuer to offer this credential over.
 4. `schemaId`: An optional field that, if specified, contains a valid URL to an existing VC schema.
-   The PRISM agent must be able to dereference the specified URL (i.e. fetch the VC schema content from it), in order to validate the provided claims against it.
+   The Cloud Agent must be able to dereference the specified URL (i.e. fetch the VC schema content from it), in order to validate the provided claims against it.
    When not specified, the claims fields is not validated and can be any valid JSON object.
    Please refer to the [Create VC schema](../schemas/create.md) doc for details on how to create a VC schema.
 5. `credentialFormat`: The format of the credential that will be issued - `JWT` in this case. When not specified, the default value is `JWT`. 
@@ -203,14 +203,14 @@ stateDiagram-v2
 
 ## Holder interactions
 
-This section describes the Holder role's available interactions with the PRISM Agent.
+This section describes the Holder role's available interactions with the Cloud Agent.
 
 ### Receiving the VC Offer
 
 The Holder will receive the offer from the Issuer via DIDComm,
 and a new credential record with a unique ID gets created in the `OfferReceived` state.
 
-This process is automatic for the PRISM Agent.
+This process is automatic for the Cloud Agent.
 
 You could check if a new credential offer is available using [`/issue-credentials/records`](/#tag/Issue-Credentials-Protocol/operation/getCredentialRecords) request and check for any records available in `OfferReceived` state:
 ```shell
@@ -228,7 +228,7 @@ To accept the offer, the Holder can make a `POST` request to the [`/issue-creden
 <Tabs groupId="vc-formats">
 <TabItem value="jwt" label="JWT">
 
-1. `holder_record_id`: The unique identifier of the issue credential record known by the holder PRISM Agent.
+1. `holder_record_id`: The unique identifier of the issue credential record known by the holder's Cloud Agent.
 2. `subjectId`: This field represents the unique identifier for the subject of the verifiable credential. It is a short-form PRISM [DID](/docs/concepts/glossary#decentralized-identifier) string, such as `did:prism:subjectIdentifier`.
 
 ```shell
@@ -245,7 +245,7 @@ curl -X POST "http://localhost:8090/prism-agent/issue-credentials/records/$holde
 </TabItem>
 <TabItem value="anoncreds" labal="AnonCreds">
 
-1. `holder_record_id`: The unique identifier of the issue credential record known by the holder PRISM Agent.
+1. `holder_record_id`: The unique identifier of the issue credential record known by the holder's Cloud Agent.
 
 ```shell
 # Holder POST request to accept the credential offer
@@ -267,7 +267,7 @@ Once the Holder has approved the offer and sent a request to the Issuer, the Hol
 The state of the Holder's record will change to `RequestSent`.
 
 After the Issuer has issued the credential, the Holder will receive the credential via DIDComm, and the state of the Holder's record will change to `CredentialReceived`.
-This process is automatic for the PRISM Agent.
+This process is automatic for the Cloud Agent.
 
 The Holder can check the achieved credential using a GET request to [`/issue-credentials/records/{recordId}/`](/agent-api/#tag/Issue-Credentials-Protocol/operation/getCredentialRecord) endpoint.
 

docs/docusaurus/credentials/present-proof-flow.puml

@@ -2,8 +2,8 @@
 title Present Proof flow
 
 actor Prover as prover
-participant "Prover PRISM Agent" as proverAgent
-participant "Verifier PRISM Agent" as verifierAgent
+participant "Prover Cloud Agent" as proverAgent
+participant "Verifier Cloud Agent" as verifierAgent
 actor Verifier as verifier
 
 note over proverAgent, verifierAgent #aqua