From 60a297d0924aad7834dd3992cb82323e6fe337e1 Mon Sep 17 00:00:00 2001 From: Yurii Shynbuiev Date: Mon, 29 Apr 2024 18:03:17 +0700 Subject: [PATCH 01/11] ci: fix release-clients.yml Signed-off-by: Yurii Shynbuiev --- .github/workflows/release-clients.yml | 10 +++++----- cloud-agent/client/typescript/package.json | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/.github/workflows/release-clients.yml b/.github/workflows/release-clients.yml index c023cb432d..0f607a5368 100644 --- a/.github/workflows/release-clients.yml +++ b/.github/workflows/release-clients.yml @@ -17,9 +17,9 @@ jobs: runs-on: ubuntu-latest env: VERSION_TAG: ${{inputs.releaseTag || github.ref_name}} - GITHUB_ACTOR: ${{secrets.GITHUB_ACTOR}} + GITHUB_ACTOR: "hyperledger-bot" GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} - NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} + NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }} steps: - name: Checkout @@ -30,7 +30,7 @@ jobs: with: node-version: "lts/*" registry-url: https://npm.pkg.github.com/ - scope: "@hyperledger-labs" + scope: "@hyperledger" - name: Setup Python uses: actions/setup-python@v4 @@ -44,8 +44,8 @@ jobs: uses: docker/login-action@v2 with: registry: ghcr.io - username: hyperledger-bot - password: ${{ secrets.GITHUB_TOKEN }} + username: ${{ env.GITHUB_ACTOR }} + password: ${{ env.GITHUB_TOKEN }} - name: Setup yq - portable yaml processor uses: mikefarah/yq@v4.34.2 diff --git a/cloud-agent/client/typescript/package.json b/cloud-agent/client/typescript/package.json index 2be58fef56..048f500d9e 100644 --- a/cloud-agent/client/typescript/package.json +++ b/cloud-agent/client/typescript/package.json @@ -1,11 +1,11 @@ { - "name": "@hyperledger-labs/open-enterprise-agent-ts-client", + "name": "@hyperledger/identus-cloud-agent-ts-client", "version": "0.0.1", "description": "TypeScript OpenAPI client for Open Enterprise Agent", "author": "allain.magyar@iohk.io", "repository": { "type": "git", - "url": "https://github.com/hyperledger-labs/open-enterprise-agent/" + "url": "https://github.com/hyperledger/identus-cloud-agent/" }, "keywords": [ "fetch", From c97a76f5a8d0d6a3702ebf5146dde28ac35c189e Mon Sep 17 00:00:00 2001 From: Yurii Shynbuiev Date: Mon, 29 Apr 2024 18:30:37 +0700 Subject: [PATCH 02/11] ci: fix the name of the Kotlin client Signed-off-by: Yurii Shynbuiev --- cloud-agent/client/kotlin/settings.gradle | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cloud-agent/client/kotlin/settings.gradle b/cloud-agent/client/kotlin/settings.gradle index 2e9109edb8..b5dc286913 100644 --- a/cloud-agent/client/kotlin/settings.gradle +++ b/cloud-agent/client/kotlin/settings.gradle @@ -1,2 +1,2 @@ -rootProject.name = 'identus--kotlin-client' \ No newline at end of file +rootProject.name = 'cloud-agent-client-kotlin' \ No newline at end of file From 0a75309bc936deabaf4379f5a6ed321e6c7a23d6 Mon Sep 17 00:00:00 2001 From: Yurii Shynbuiev Date: Mon, 29 Apr 2024 18:36:14 +0700 Subject: [PATCH 03/11] ci: fix the name of the TS client Signed-off-by: Yurii Shynbuiev --- cloud-agent/client/typescript/package.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cloud-agent/client/typescript/package.json b/cloud-agent/client/typescript/package.json index 048f500d9e..530dd6fc09 100644 --- a/cloud-agent/client/typescript/package.json +++ b/cloud-agent/client/typescript/package.json @@ -1,7 +1,7 @@ { - "name": "@hyperledger/identus-cloud-agent-ts-client", + "name": "@hyperledger/cloud-agent-client-ts", "version": "0.0.1", - "description": "TypeScript OpenAPI client for Open Enterprise Agent", + "description": "TypeScript OpenAPI client for Identus Cloud Agent", "author": "allain.magyar@iohk.io", "repository": { "type": "git", From aebecb61837f2e11b63a984894bf76d9b775be3b Mon Sep 17 00:00:00 2001 From: Yurii Shynbuiev Date: Tue, 30 Apr 2024 13:53:45 +0700 Subject: [PATCH 04/11] docs: update the references to the Cloud Agent in the documentation Signed-off-by: Yurii Shynbuiev --- .../connections/connection-flow.puml | 4 +- docs/docusaurus/connections/connection.md | 10 ++--- .../docusaurus/credentialdefinition/create.md | 6 +-- .../credential-definition.md | 10 ++--- .../docusaurus/credentialdefinition/delete.md | 2 +- .../credentials/anoncreds-issue-flow.puml | 4 +- .../anoncreds-present-proof-flow.puml | 4 +- docs/docusaurus/credentials/issue-flow.puml | 4 +- docs/docusaurus/credentials/issue.md | 30 ++++++------- .../credentials/present-proof-flow.puml | 4 +- docs/docusaurus/credentials/present-proof.md | 22 +++++----- docs/docusaurus/dids/create.md | 26 +++++------ docs/docusaurus/dids/deactivate.md | 14 +++--- docs/docusaurus/dids/publish.md | 24 +++++----- docs/docusaurus/dids/update.md | 18 ++++---- docs/docusaurus/index.md | 7 ++- .../docusaurus/multitenancy/access-control.md | 14 +++--- .../multitenancy/account-management.md | 20 ++++----- .../multitenancy/admin-authz-ext-iam.md | 10 ++--- .../multitenancy/tenant-migration.md | 20 ++++----- .../multitenancy/tenant-onboarding-ext-iam.md | 22 +++++----- .../tenant-onboarding-self-service.md | 16 +++---- .../multitenancy/tenant-onboarding.md | 32 +++++++------- docs/docusaurus/schemas/create.md | 4 +- docs/docusaurus/schemas/credential-schema.md | 10 ++--- docs/docusaurus/schemas/delete.md | 2 +- docs/docusaurus/schemas/update.md | 2 +- docs/docusaurus/secrets/operation.md | 6 +-- docs/docusaurus/secrets/secret-storage.md | 32 +++++++------- docs/docusaurus/secrets/seed-generation.md | 12 ++--- docs/docusaurus/secrets/sequence-diagrams.md | 6 +-- docs/docusaurus/webhooks/webhook.md | 44 +++++++++---------- 32 files changed, 220 insertions(+), 221 deletions(-) diff --git a/docs/docusaurus/connections/connection-flow.puml b/docs/docusaurus/connections/connection-flow.puml index cca9ce0131..1a47a54f80 100644 --- a/docs/docusaurus/connections/connection-flow.puml +++ b/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 == diff --git a/docs/docusaurus/connections/connection.md b/docs/docusaurus/connections/connection.md index 8c18104aef..8c4b5c0b91 100644 --- a/docs/docusaurus/connections/connection.md +++ b/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. ::: diff --git a/docs/docusaurus/credentialdefinition/create.md b/docs/docusaurus/credentialdefinition/create.md index 2e766a6aa9..6e9cd01667 100644 --- a/docs/docusaurus/credentialdefinition/create.md +++ b/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 diff --git a/docs/docusaurus/credentialdefinition/credential-definition.md b/docs/docusaurus/credentialdefinition/credential-definition.md index add79d43de..4429a8a07d 100644 --- a/docs/docusaurus/credentialdefinition/credential-definition.md +++ b/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. diff --git a/docs/docusaurus/credentialdefinition/delete.md b/docs/docusaurus/credentialdefinition/delete.md index 4b6ef0637a..94ce25dd83 100644 --- a/docs/docusaurus/credentialdefinition/delete.md +++ b/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`. diff --git a/docs/docusaurus/credentials/anoncreds-issue-flow.puml b/docs/docusaurus/credentials/anoncreds-issue-flow.puml index a1282c4bd0..3cb39ecca0 100644 --- a/docs/docusaurus/credentials/anoncreds-issue-flow.puml +++ b/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 diff --git a/docs/docusaurus/credentials/anoncreds-present-proof-flow.puml b/docs/docusaurus/credentials/anoncreds-present-proof-flow.puml index c13ea201b7..2d7a39a07d 100644 --- a/docs/docusaurus/credentials/anoncreds-present-proof-flow.puml +++ b/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 diff --git a/docs/docusaurus/credentials/issue-flow.puml b/docs/docusaurus/credentials/issue-flow.puml index 5f6332f43b..6643b3dade 100644 --- a/docs/docusaurus/credentials/issue-flow.puml +++ b/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 diff --git a/docs/docusaurus/credentials/issue.md b/docs/docusaurus/credentials/issue.md index d776a5843f..6ce39431d8 100644 --- a/docs/docusaurus/credentials/issue.md +++ b/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,16 +22,16 @@ Before using the Issuing Credentials protocol, the following conditions must be -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. -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). @@ -39,7 +39,7 @@ Before using the Issuing Credentials protocol, the following conditions must be ## 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 -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 -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. diff --git a/docs/docusaurus/credentials/present-proof-flow.puml b/docs/docusaurus/credentials/present-proof-flow.puml index 49b8c3e070..63be0e482f 100644 --- a/docs/docusaurus/credentials/present-proof-flow.puml +++ b/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 diff --git a/docs/docusaurus/credentials/present-proof.md b/docs/docusaurus/credentials/present-proof.md index 9469c57af1..47be894982 100644 --- a/docs/docusaurus/credentials/present-proof.md +++ b/docs/docusaurus/credentials/present-proof.md @@ -20,13 +20,13 @@ The present proof protocol has two roles: Before using the Proof Presentation protocol, the following conditions must be present: -1. Holder/Prover and Verifier PRISM Agents must be up and running -2. A connection must be established between the Holder/Prover and Verifier PRISM Agents (see [Connections](../connections/connection.md)) +1. Holder/Prover and Verifier Cloud Agents must be up and running +2. A connection must be established between the Holder/Prover and Verifier Cloud Agents (see [Connections](../connections/connection.md)) 3. The Holder/Prover should hold a [verifiable credential (VC)](/docs/concepts/glossary#verifiable-credential) received from an [Issuer](/docs/concepts/glossary#issuer) see [Issue](./issue.md). ## Overview -This protocol supports the presentation of verifiable claims between two Atala PRISM Agents, the Holder/Prover and the Verifier. +This protocol supports the presentation of verifiable claims between two Cloud Agents, the Holder/Prover and the Verifier. The protocol consists of the following main parts: @@ -45,12 +45,12 @@ The protocol consists of the following main parts: | [`/present-proof/presentations/{id}`](/agent-api/#tag/Present-Proof/operation/updatePresentation) | PATCH | Updates an existing presentation proof record to, e.g., accept the request on the Holder/Prover side or accept the presentation on the Verifier side. | Verifier, Holder/Prover | :::info -For more detailed information, please, check the full [PRISM Agent API](/agent-api). +For more detailed information, please, check the full [Cloud Agent API](/agent-api). ::: ## Verifier interactions -This section describes the interactions available to the Verifier with the PRISM Agent. +This section describes the interactions available to the Verifier with the Cloud Agent. ### Creating and sending a Presentation Request @@ -128,7 +128,7 @@ curl -X 'POST' 'http://localhost:8070/prism-agent/present-proof/presentations' \ -Upon execution, a new presentation request record gets created with an initial state of `RequestPending`. The Verifier PRISM Agent will send the presentation request message to the PRISM Agent of the Holder/Prover through the specified DIDComm connection. The record state then is updated to `RequestSent`. +Upon execution, a new presentation request record gets created with an initial state of `RequestPending`. The Verifier Cloud Agent will send the presentation request message to the Cloud Agent of the Holder/Prover through the specified DIDComm connection. The record state then is updated to `RequestSent`. The Verifier can retrieve the list of presentation records by making a `GET` request to the [`/present-proof/presentations`](/agent-api/#tag/Present-Proof/operation/getAllPresentation) endpoint: ```bash @@ -138,7 +138,7 @@ curl -X 'GET' 'http://localhost:8070/prism-agent/present-proof/presentations' \ ``` ### Accept presentation proof received from the Holder/prover -Once the Holder/Prover has received a proof presentation request, he can accept it using an appropriate verifiable credential. The PRISM Agent of the Verifier will receive that proof and verify it. Upon successful verification, the presentation record state gets updated to `PresentationVerified`. +Once the Holder/Prover has received a proof presentation request, he can accept it using an appropriate verifiable credential. The Cloud Agent of the Verifier will receive that proof and verify it. Upon successful verification, the presentation record state gets updated to `PresentationVerified`. The Verifier can then explicitly accept the specific verified proof presentation to change the record state to `PresentationAccepted` by making a `PATCH` request to the [`/present-proof/presentations/{id}`](/agent-api/#tag/Present-Proof/operation/updatePresentation) endpoint: @@ -164,10 +164,10 @@ stateDiagram-v2 ``` ## Holder/Prover -This section describes the interactions available to the Holder/Prover with his PRISM Agent. +This section describes the interactions available to the Holder/Prover with his Cloud Agent. ### Reviewing and accepting a received presentation request -The Holder/Prover can retrieve the list of presentation requests received by its PRISM Agent from different Verifiers making a `GET` request to the [`/present-proof/presentations`](/agent-api/#tag/Present-Proof/operation/getAllPresentation) endpoint: +The Holder/Prover can retrieve the list of presentation requests received by its Cloud Agent from different Verifiers making a `GET` request to the [`/present-proof/presentations`](/agent-api/#tag/Present-Proof/operation/getAllPresentation) endpoint: ```bash curl -X 'GET' 'http://localhost:8090/prism-agent/present-proof/presentations' \ @@ -175,7 +175,7 @@ curl -X 'GET' 'http://localhost:8090/prism-agent/present-proof/presentations' \ -H "apikey: $API_KEY" ``` -The Holder/Prover can then accept a specific request, generate the proof, and send it to the Verifier PRISM Agent by making a `PATCH` request to the [`/present-proof/presentations/{id}`](/agent-api/#tag/Present-Proof/operation/updatePresentation) endpoint: +The Holder/Prover can then accept a specific request, generate the proof, and send it to the Verifier Cloud Agent by making a `PATCH` request to the [`/present-proof/presentations/{id}`](/agent-api/#tag/Present-Proof/operation/updatePresentation) endpoint: @@ -225,7 +225,7 @@ The Holder/Prover will have to provide the following information: 1. `presentationId`: The unique identifier of the presentation record to accept. 2. `anoncredPresentationRequest`: A list of credential unique identifier with the attribute and predicate the credential is answering for. -The record state is updated to `PresentationPending` and processed by the Holder/Prover PRISM Agent. The agent will automatically generate the proof presentation, change the state to `PresentationGenerated`, and will eventually send it to the Verifier Agent, and change the state to `PresentationSent`. +The record state is updated to `PresentationPending` and processed by the Holder/Prover Cloud Agent. The agent will automatically generate the proof presentation, change the state to `PresentationGenerated`, and will eventually send it to the Verifier Agent, and change the state to `PresentationSent`. ```mermaid --- diff --git a/docs/docusaurus/dids/create.md b/docs/docusaurus/dids/create.md index 8d0d5a99ed..b8e616d288 100644 --- a/docs/docusaurus/dids/create.md +++ b/docs/docusaurus/dids/create.md @@ -14,47 +14,47 @@ Once the create-operation gets constructed, deriving a DID from this operation i ## Prerequisites -1. DID Controller PRISM Agent up and running +1. DID Controller Cloud Agent up and running ## Overview -For this example, a PRISM DID gets created and stored inside PRISM Agent along with the private keys. It is not automatically published. +For this example, a PRISM DID gets created and stored inside the Cloud Agent along with the private keys. It is not automatically published. The Agent will keep track of private keys used for the create-operation and the content of the operation itself. -PRISM Agent provides two endpoint groups to facilitate PRISM DID usage. +The Cloud Agent provides two endpoint groups to facilitate PRISM DID usage. - `/dids/*` facilitate of low-level interactions between DID operations and the blockchain. The DID controllers will handle key management independently and use these endpoints for blockchain interaction. - `/did-registrar/*` -Facilitates a higher-level interaction with PRISM DID, where the PRISM Agent handles key management concerns. +Facilitates a higher-level interaction with PRISM DID, where the Cloud Agent handles key management concerns. ## Endpoints The example uses the following endpoints -| Endpoint | Description | Role | -|----------------------------------------------------------------------------------------|-----------------------------------------------------|----------------| -| [`GET /did-registrar/dids`](/agent-api/#tag/DID-Registrar/operation/listManagedDid) | List all DIDs stored in PRISM Agent | DID Controller | -| [`POST /did-registrar/dids`](/agent-api/#tag/DID-Registrar/operation/createManagedDid) | Create a new PRISM DID to be managed by PRISM Agent | DID Controller | -| [`GET /dids/{didRef}`](/agent-api/#tag/DID/operation/getDid) | Resolve a DID to DID document representation | DID Controller | +| Endpoint | Description | Role | +|----------------------------------------------------------------------------------------|---------------------------------------------------------|----------------| +| [`GET /did-registrar/dids`](/agent-api/#tag/DID-Registrar/operation/listManagedDid) | List all DIDs stored in the Cloud Agent | DID Controller | +| [`POST /did-registrar/dids`](/agent-api/#tag/DID-Registrar/operation/createManagedDid) | Create a new PRISM DID to be managed by the Cloud Agent | DID Controller | +| [`GET /dids/{didRef}`](/agent-api/#tag/DID/operation/getDid) | Resolve a DID to DID document representation | DID Controller | ## DID Controller interactions -### 1. Check existing DID on the PRISM Agent +### 1. Check existing DID on the Cloud Agent ```bash curl --location --request GET 'http://localhost:8080/prism-agent/did-registrar/dids' \ --header "apikey: $API_KEY" \ --header 'Accept: application/json' ``` -The result should show an empty list, as no DIDs exist on this PRISM Agent instance. +The result should show an empty list, as no DIDs exist on this Cloud Agent instance. -### 2. Create a PRISM Agent managed DID using DID registrar endpoint +### 2. Create the Cloud Agent managed DID using DID registrar endpoint The DID controller can create a new DID by sending a [DID document](/docs/concepts/glossary#did-document) template to the Agent. -Since key pairs are generated and managed by PRISM Agent, DID controller only has to specify the key `id` and its purpose (e.g., `authentication`, `assertionMethod`, etc.). +Since key pairs are generated and managed by the Cloud Agent, DID controller only has to specify the key `id` and its purpose (e.g., `authentication`, `assertionMethod`, etc.). The current PRISM DID method supports a key with a single purpose, but it is extendible to support a key with multiple purposes in the future. ```bash diff --git a/docs/docusaurus/dids/deactivate.md b/docs/docusaurus/dids/deactivate.md index 8061be82ea..9fb1ac4918 100644 --- a/docs/docusaurus/dids/deactivate.md +++ b/docs/docusaurus/dids/deactivate.md @@ -13,8 +13,8 @@ The PRISM DID method only allows published DID to be deactivated. ## Prerequisites -1. DID Controller PRISM Agent up and running -2. DID Controller has a DID created on PRISM Agent (see [Create DID](./create.md)) +1. DID Controller Cloud Agent up and running +2. DID Controller has a DID created on the Cloud Agent (see [Create DID](./create.md)) 3. DID Controller has a DID published to the blockchain (see [Publish DID](./publish.md)) ## Overview @@ -25,9 +25,9 @@ The same concept also holds for PRISM DID deactivation in that the fork can occu Please refer to the `SECURE_DEPTH` parameter in [PRISM method - protocol parameters](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md#versioning-and-protocol-parameters) for the number of confirmation blocks. At the time of writing, this number is 112 blocks. -DID deactivation is easily performed with the PRISM Agent. -Under the hood, PRISM Agent uses the `MASTER` keys to sign the intended operation and automatically post the operation to the blockchain. -This example shows the DID deactivation and steps to observe the changes to the DID using PRISM Agent. +DID deactivation is easily performed with the Cloud Agent. +Under the hood, the Cloud Agent uses the `MASTER` keys to sign the intended operation and automatically post the operation to the blockchain. +This example shows the DID deactivation and steps to observe the changes to the DID using the Cloud Agent. ## Endpoints @@ -42,7 +42,7 @@ The example uses the following endpoints ### 1. Check the current state of the DID document -Given the DID Controller has a DID on PRISM Agent and that DID is published, he can resolve the DID document using short-form DID. +Given the DID Controller has a DID managed by the Cloud Agent and that DID is published, he can resolve the DID document using short-form DID. ```bash curl --location --request GET 'http://localhost:8080/prism-agent/dids/{didRef}' \ @@ -76,7 +76,7 @@ curl --location --request POST 'http://localhost:8080/prism-agent/did-registrar/ --header 'Accept: application/json' ``` -Under the hood, PRISM Agent constructs the DID deactivate-operation from the last confirmed operation observed on the blockchain. +Under the hood, the Cloud Agent constructs the DID deactivate-operation from the last confirmed operation observed on the blockchain. The DID Controller should receive a response about the scheduled operation, waiting for confirmation on the blockchain. If this deactivate-operation gets confirmed on the blockchain and not discarded as a fork, the DID becomes deactivated. diff --git a/docs/docusaurus/dids/publish.md b/docs/docusaurus/dids/publish.md index bc4fb1cefe..b233cbc19a 100644 --- a/docs/docusaurus/dids/publish.md +++ b/docs/docusaurus/dids/publish.md @@ -20,13 +20,13 @@ The resolution of short-form DID is achievable by DID publication, which is a pr ## Prerequisites -1. DID Controller PRISM Agent up and running -2. DID Controller has a DID created on PRISM Agent (see [Create DID](./create.md)) +1. DID Controller Cloud Agent up and running +2. DID Controller has a DID created by the Cloud Agent (see [Create DID](./create.md)) ## Overview -Publishing a DID requires the DID create-operation and the DID `MASTER` key pairs, which PRISM Agent already created under the hood. -When the DID Controller requests a publication of their DID, PRISM Agent uses the DID `MASTER` key to sign the operation and submit the signed operation to the blockchain. +Publishing a DID requires the DID create-operation and the DID `MASTER` key pairs, which the Cloud Agent already created under the hood. +When the DID Controller requests a publication of their DID, the Cloud Agent uses the DID `MASTER` key to sign the operation and submit the signed operation to the blockchain. After the operation submission to the blockchain, a specific number of confirmation blocks must get created before the DID operation is processed and published. (see [PRISM DID method - Processing of DID operation](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md#processing-of-operations)) @@ -34,11 +34,11 @@ After the operation submission to the blockchain, a specific number of confirmat The example uses the following endpoints -| Endpoint | Description | Role | -|---------------------------------------------------------------------------------------------------------------|---------------------------------------------------------|----------------| -| [`GET /did-registrar/dids/{didRef}`](/agent-api/#tag/DID-Registrar/operation/getManagedDid) | Get the DID stored in PRISM Agent | DID Controller | -| [`POST /did-registrar/dids/{didRef}/publications`](/agent-api/#tag/DID-Registrar/operation/publishManagedDid) | Publish the DID stored in PRISM Agent to the blockchain | DID Controller | -| [`GET /dids/{didRef}`](/agent-api/#tag/DID/operation/getDid) | Resolve a DID to DID document representation | DID Controller | +| Endpoint | Description | Role | +|---------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------|----------------| +| [`GET /did-registrar/dids/{didRef}`](/agent-api/#tag/DID-Registrar/operation/getManagedDid) | Get the DID stored in the Cloud Agent | DID Controller | +| [`POST /did-registrar/dids/{didRef}/publications`](/agent-api/#tag/DID-Registrar/operation/publishManagedDid) | Publish the DID stored in the Cloud Agent to the blockchain | DID Controller | +| [`GET /dids/{didRef}`](/agent-api/#tag/DID/operation/getDid) | Resolve a DID to DID document representation | DID Controller | ## DID Controller interactions @@ -73,7 +73,7 @@ curl --location --request POST 'http://localhost:8080/prism-agent/did-registrar/ --header 'Accept: application/json' ``` -PRISM Agent will retrieve a DID `MASTER` key and sign the operation before submitting it to the blockchain. +The Cloud Agent will retrieve a DID `MASTER` key and sign the operation before submitting it to the blockchain. The process is asynchronous, and it takes time until the operation is confirmed. The DID Controller receives a scheduled operation as a response. @@ -89,7 +89,7 @@ The DID Controller receives a scheduled operation as a response. The response contains the `scheduledOperation` property, which describes a scheduled operation. The submitted DID operations are batched together along with other operations to reduce the transaction cost when interacting with the blockchain. -PRISM Agent will eventually expose an endpoint to check the status of a scheduled operation. +The Cloud Agent will eventually expose an endpoint to check the status of a scheduled operation. Checking the publishing status is possible by following Step 3. ### 3. Wait until the DID operation is confirmed @@ -117,7 +117,7 @@ Example response with status `PUBLISHED` } ``` -> **Note:** The `status` here is the internal status of the DID on the PRISM Agent (`PUBLISHED`, `CREATED`, `PUBLICAION_PENDING`). It does not indicate the lifecycle of the DID observed on the blockchain (e.g., deactivated, etc.). The [DID resolution](/docs/concepts/glossary#did-resolution) metadata is for that purpose. +> **Note:** The `status` here is the internal status of the DID on the Cloud Agent (`PUBLISHED`, `CREATED`, `PUBLICAION_PENDING`). It does not indicate the lifecycle of the DID observed on the blockchain (e.g., deactivated, etc.). The [DID resolution](/docs/concepts/glossary#did-resolution) metadata is for that purpose. ### 4. Resolve a short-form DID diff --git a/docs/docusaurus/dids/update.md b/docs/docusaurus/dids/update.md index 89d676b46a..22fb55c7fd 100644 --- a/docs/docusaurus/dids/update.md +++ b/docs/docusaurus/dids/update.md @@ -23,28 +23,28 @@ It has an important implication on how the operation lineage is determined. ## Prerequisites -1. DID Controller PRISM agent up and running -2. DID Controller has a DID created on PRISM agent (see [Create DID](./create.md)) +1. DID Controller Cloud Agent is up and running +2. DID Controller has a DID created by the Cloud Agent (see [Create DID](./create.md)) 3. DID Controller has a DID published to the blockchain (see [Publish DID](./publish.md)) ## Overview -PRISM agent allows the DID Controller to update the DID easily. This update mechanism is implementation specific and links the DID update-operation from the last confirmed operation observed on the blockchain. +The Cloud Agent allows the DID Controller to update the DID easily. This update mechanism is implementation specific and links the DID update-operation from the last confirmed operation observed on the blockchain. When updating a DID, there is a waiting period for the update to be confirmed on the blockchain. If the DID Controller updates the DID before the previous update is confirmed, it can create a situation where the sequence of updates splits into two separate paths, -which is not allowed according to the protocol. This happens because the PRISM agent connects +which is not allowed according to the protocol. This happens because the Cloud Agent connects the update operation to the latest confirmed update. Once the pending update operation is confirmed, any other pending operation that does not link to the latest confirmed operation will be discarded. The subsequent updates continuing from that operation will also be discarded. -However, the PRISM agent has a safeguard in place to prevent this issue by rejecting +However, the Cloud Agent has a safeguard in place to prevent this issue by rejecting multiple updates submitted on the same DID while previous updates are still being processed. Please refer to the `SECURE_DEPTH` parameter in [PRISM method - protocol parameters](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md#versioning-and-protocol-parameters) for the number of confirmation blocks. At the time of writing, this number is 112 blocks. -This example shows the DID update capability on PRISM agent and the steps to verify that the update has been confirmed and applied. +This example shows the DID update capability on the Cloud Agent and the steps to verify that the update has been confirmed and applied. ## Endpoints @@ -59,7 +59,7 @@ The example uses the following endpoints ### 1. Check the current state of the DID document -Given the DID Controller has a DID on PRISM agent and that DID is published, he can resolve the DID document using short-form DID. +Given the DID Controller has a DID on the Cloud Agent and that DID is published, he can resolve the DID document using short-form DID. ```bash curl --location --request GET 'http://localhost:8080/prism-agent/dids/{didRef}' \ @@ -126,7 +126,7 @@ curl --location --request POST 'http://localhost:8080/prism-agent/did-registrar/ ] }' ``` -Under the hood, PRISM agent constructs the DID update-operation from the last confirmed operation observed on the blockchain. +Under the hood, the Cloud Agent constructs the DID update-operation from the last confirmed operation observed on the blockchain. The DID Controller should receive a response about the scheduled operation, waiting for confirmation on the blockchain. @@ -179,4 +179,4 @@ A new key, called `key-2`, gets observed, and `key-1`, now removed, has disappea ## Future work The example only shows the case of a successful update. -In case of failure, PRISM agent will provide the capability to retrieve the low-level operation status and failure detail in the future. +In case of failure, the Cloud Agent will provide the capability to retrieve the low-level operation status and failure detail in the future. diff --git a/docs/docusaurus/index.md b/docs/docusaurus/index.md index d9f8037f79..45301dd870 100644 --- a/docs/docusaurus/index.md +++ b/docs/docusaurus/index.md @@ -1,20 +1,19 @@ # Tutorials -Welcome to the Atala PRISM Tutorials! +Welcome to the Identus Platform Tutorials! -These tutorials will help you get started with using Atala PRISM. +These tutorials will help you get started with using Identus Platform. The tutorials will guide you through setting up a connection, working with [Decentralized Identifiers (DIDs)](/docs/concepts/glossary#decentralized-identifer), and using [verifiable credentials](/docs/concepts/glossary#verifiable-credentials). Whether you are new to [self-sovereign identity (SSI)](/docs/concepts/glossary#self-sovereign-identity) or have prior experience, these tutorials will provide the necessary information and skills to build and use SSI-based applications. - Throughout all code examples in tutorials, the following conventions are in use: * Issuer Keycloak is hosted at `http://localhost:9980/` * Issuer Agent is hosted at `http://localhost:8080/prism-agent/` * Holder Agent is hosted at `http://localhost:8090/prism-agent/` * Verifier Agent is hosted at `http://localhost:8100/prism-agent/` -:::info To use the PRISM Cloud Agents, you must include an `apiKey` header in your requests. You can configure the key, and in some instances, it will be provided to you, so make sure to create an environment variable with the proper value. +:::info To use the Identus Cloud Agents, you must include an `apiKey` header in your requests. You can configure the key, and in some instances, it will be provided to you, so make sure to create an environment variable with the proper value. ```shell export API_KEY= ``` diff --git a/docs/docusaurus/multitenancy/access-control.md b/docs/docusaurus/multitenancy/access-control.md index 79e679d52b..433bf1ab0a 100644 --- a/docs/docusaurus/multitenancy/access-control.md +++ b/docs/docusaurus/multitenancy/access-control.md @@ -8,7 +8,7 @@ ## Introduction -Current document describes the levels of access control in the PRISM platform configured in the Vault service +Current document describes the levels of access control in the Identus Platform configured in the Vault service The Vault service uses policies to control the access to the secrets, configuration, and other resources. The policies are applied to the entities and groups of entities. @@ -31,7 +31,7 @@ Managed by DevOps and SRE teams. ### Management Account -Management Account is special account that allows to manage the PRISM platform. +Management Account is special account that allows to manage the Cloud Agent. The account with the limited access to configure the Vault service with the following permissions: - manage the Wallet accounts @@ -42,7 +42,7 @@ Management Account can be used in the configuration scripts or by the SRE team. ### Agent Account -Agent Account is created for the PRISM Agent to authenticate itself to the Vault service. +Agent Account is created for the Cloud Agent to authenticate itself to the Vault service. AppRole authentication method is used for this account. The account with the limited access to configure the Vault service with the following permissions: @@ -53,7 +53,7 @@ The account with the limited access to configure the Vault service with the foll ### Wallet Account The Wallet Account is created for and used by the Wallet. -The Wallet Account is has access to the secrets of the Wallet and the PRISM Agent must guarantee the data isolation at the Wallet level. +The Wallet Account is has access to the secrets of the Wallet and the Cloud Agent must guarantee the data isolation at the Wallet level. This account has the following permissions: - list, read, write, delete the secrets associated with the Wallet - use the REST API associated with the Wallet @@ -73,14 +73,14 @@ The following practices are applied to implement the PoLP: **NOTE**: there are other PoLP practices that are not covered in this document. These practices will be ignored for local development and testing purposes. In order to implement the PoLP, the following access control rules are defined: -- PRISM Agent account has access to the Wallet account that belong to the Agent only -- PRISM Agent account transparently issues the token to the Wallet account based on configured authentication method +- the Cloud Agent account has access to the Wallet account that belong to the Agent only +- the Cloud Agent account transparently issues the token to the Wallet account based on configured authentication method ### Token Issuing, Renewal, Expiration and Revocation These policies are applied to all tokens except the SUDO account (root token). -All tokens issued by the PRISM platform have the following properties: +All tokens issued by the Identus Platform have the following properties: - expiration time - maximum time to live (TTL) - renewable flag diff --git a/docs/docusaurus/multitenancy/account-management.md b/docs/docusaurus/multitenancy/account-management.md index ebcce9139e..b44d4ba683 100644 --- a/docs/docusaurus/multitenancy/account-management.md +++ b/docs/docusaurus/multitenancy/account-management.md @@ -8,36 +8,36 @@ ## Introduction -This document describes the account management in the PRISM platform, types of accounts, and their usage, account authentication, and logical isolation of accounts. +This document describes the account management in the Identus Platform, types of accounts, and their usage, account authentication, and logical isolation of accounts. ## Technical Overview Account management is a set of operations that allow users to manage their accounts. Account is required for both single and multi-tenant configurations. -In the PRISM platform, the account owns the corresponding Wallet managed by the Agent. +In the Identus Platform, the account owns the corresponding Wallet managed by the Cloud Agent. The account is identified by the tenant ID and represented by the Entity in the Vault service. ### Account Types -The PRISM platform supports the following types of accounts: -- PRISM Agent Account - application account used by the PRISM Agent to authenticate itself to the Vault service +The Identus Platform supports the following types of accounts: +- Cloud Agent Account - application account used by the Cloud Agent to authenticate itself to the Vault service - Wallet Account - application or user account used to access the Wallet assets over the REST API or WEB UI ### Account Creation -The PRISM Agent Account is created by before the start of the PRISM Agent using the Vault cli, REST API or WEB UI. +The Cloud Agent Account is created by before the start of the Cloud Agent using the Vault cli, REST API or WEB UI. The Wallet account can be created on the go by the Agent or using the Vault cli, REST API or WEB UI. -### PRISM Agent Account +### Cloud Agent Account -The Agent account required to authenticate the instance of the Agent. +The Cloud Agent account required to authenticate the instance of the Cloud Agent. The account is responsible for creating the Wallet accounts and issuing the tokens to the Wallet instance. -The Agent account doesn't have the access to the Wallet secrets. -PRISM Agent uses [AppRole](https://www.vaultproject.io/docs/auth/approle) authentication method to authenticate itself to the Vault service. +The Cloud Agent account doesn't have the access to the Wallet secrets. +The Cloud Agent uses [AppRole](https://www.vaultproject.io/docs/auth/approle) authentication method to authenticate itself to the Vault service. ### Wallet Account -The Wallet account is required to authenticate the entity to the PRISM platform and give it the access to Wallet. +The Wallet account is required to authenticate the entity to the Identus Platform and give it the access to Wallet. The Wallet account can be authenticated by the following methods: - JWT/OIDC token - user/password diff --git a/docs/docusaurus/multitenancy/admin-authz-ext-iam.md b/docs/docusaurus/multitenancy/admin-authz-ext-iam.md index 8e318fc313..28ab7e4025 100644 --- a/docs/docusaurus/multitenancy/admin-authz-ext-iam.md +++ b/docs/docusaurus/multitenancy/admin-authz-ext-iam.md @@ -20,8 +20,8 @@ The same person may also represent these roles. 1. A realm called `my-realm` is created 2. A client called `prism-agent` under `my-realm` with __authorization__ feature is created. (See [create client instruction](https://www.keycloak.org/docs/latest/authorization_services/index.html#_resource_server_create_client)) 3. Make sure the `prism-agent` client has __direct access grants__ enabled to simplify the login -3. PRISM Agent up and running -4. PRISM Agent is configured with the following environment variables: +3. The Cloud Agent is up and running +4. The Cloud Agent is configured with the following environment variables: 1. `KEYCLOAK_ENABLED=true` 2. `KEYCLOAK_URL=http://localhost:9980` (replace with appropriate value) 3. `KEYCLOAK_REALM=my-realm` @@ -42,9 +42,9 @@ Despite UMA permissions configured for the user, the agent strictly maintains a ## Endpoints ### Agent endpoints -| Endpoint | Description | Role | -|--------------------------------------------|--------------------------------------|---------------| -| `GET /wallets` | List the wallets on PRISM Agent | Administrator | +| Endpoint | Description | Role | +|--------------------------------------------|-------------------------------------|---------------| +| `GET /wallets` | List the wallets on the Cloud Agent | Administrator | ### Keycloak endpoints | Endpoint | Description | Role | diff --git a/docs/docusaurus/multitenancy/tenant-migration.md b/docs/docusaurus/multitenancy/tenant-migration.md index 72b02049ce..d779148555 100644 --- a/docs/docusaurus/multitenancy/tenant-migration.md +++ b/docs/docusaurus/multitenancy/tenant-migration.md @@ -1,6 +1,6 @@ # Migration from `apikey` to `JWT` authentication -PRISM Agent authentication supports multiple authentication methods simultaneously, which means the user can seamlessly use any available credentials including `apikey` or `JWT` to access the wallet. +The Cloud Agent authentication supports multiple authentication methods simultaneously, which means the user can seamlessly use any available credentials including `apikey` or `JWT` to access the wallet. The agent's [UMA](/docs/concepts/glossary#uma) permission resource also exposes the self-service permission endpoint, allowing users to manage the permissions for their wallets. It allows users to transition from `apikey` to `JWT` authentication without admin intervention. @@ -14,8 +14,8 @@ In the migration process from `apikey` to `JWT`, there is only one role: 1. Keycloak up and running 2. Keycloak is configured the same as in [Tenant Onboarding Self-Service](./tenant-onboarding-self-service.md) -3. PRISM Agent up and running -4. PRISM Agent is configured the same as in [Tenant Onboarding Self-Service](./tenant-onboarding-self-service.md) +3. The Cloud Agent up and running +4. The Cloud Agent is configured the same as in [Tenant Onboarding Self-Service](./tenant-onboarding-self-service.md) 5. The user has access to the wallet using `apikey`. (See [Tenant Onboarding](./tenant-onboarding.md)) 6. The user has an account registered on Keycloak @@ -28,12 +28,12 @@ To migrate to `JWT` authentication, users can create a new UMA permission for th ## Endpoints ### Agent endpoints -| Endpoint | Description | Role | -|--------------------------------------------|--------------------------------------|--------| -| `GET /wallets` | List the wallets on PRISM Agent | Tenant | -| `POST /wallets` | Create a new wallet on PRISM Agent | Tenant | -| `POST /wallets/{walletId}/uma-permissions` | Create a uma-permission for a wallet | Tenant | -| `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | +| Endpoint | Description | Role | +|--------------------------------------------|----------------------------------------|--------| +| `GET /wallets` | List the wallets on the Cloud Agent | Tenant | +| `POST /wallets` | Create a new wallet on the Cloud Agent | Tenant | +| `POST /wallets/{walletId}/uma-permissions` | Create a uma-permission for a wallet | Tenant | +| `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | ### Keycloak endpoints | Endpoint | Description | Role | @@ -140,7 +140,7 @@ Make sure to use the correct `subject` for the user and the correct `walletId` f The response should return the status `200 OK` in case of successful permission creation. -### 5. Perform a simple action to verify access to PRISM Agent +### 5. Perform a simple action to verify access to the Cloud Agent After successful UMA permission creation, the user should be able to use the `JWT` token to authenticate the wallet. List the wallet using a new `Authorization` header. The listed wallets should contain the wallet with the same ID in step 1. diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md index c3294691bc..52493a26e8 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-ext-iam.md @@ -4,7 +4,7 @@ In the [Tenant Onboarding](./tenant-onboarding.md) tutorial, we explored the bas Although it is usable and straightforward, more featureful tools are available for handling identity and access management. The agent can seamlessly connect with [Keycloak](/docs/concepts/glossary#keycloak-service) as an external IAM system, allowing the application built on top to utilize the capabilities that come with Keycloak. -The PRISM Agent leverages standard protocols like [OIDC](/docs/concepts/glossary#oidc) and [UMA](/docs/concepts/glossary#uma) for authentication and access management. +The Cloud Agent leverages standard protocols like [OIDC](/docs/concepts/glossary#oidc) and [UMA](/docs/concepts/glossary#uma) for authentication and access management. The user's identity gets established through the ID token, and wallet permissions are searchable using the [RPT (requesting party token)](/docs/concepts/glossary#rpt). ## Roles @@ -21,8 +21,8 @@ In tenant management with external IAM, there are 2 roles: 1. A realm called `my-realm` is created 2. A client called `prism-agent` under `my-realm` with __authorization__ feature is created. (See [create client instruction](https://www.keycloak.org/docs/latest/authorization_services/index.html#_resource_server_create_client)) 3. Make sure the `prism-agent` client has __direct access grants__ enabled to simplify the login process for this tutorial -3. PRISM Agent up and running -4. PRISM Agent is configured with the following environment variables: +3. the Cloud Agent up and running +4. the Cloud Agent is configured with the following environment variables: 1. `ADMIN_TOKEN=my-admin-token` 2. `DEFAULT_WALLET_ENABLED=false` 3. `KEYCLOAK_ENABLED=true` @@ -53,12 +53,12 @@ The tenant can access the multi-tenant agent by providing the RPT in the `Author ## Endpoints ### Agent endpoints -| Endpoint | Description | Role | -|--------------------------------------------|--------------------------------------|---------------| -| `GET /wallets` | List the wallets on PRISM Agent | Administrator | -| `POST /wallets` | Create a new wallet on PRISM Agent | Administrator | -| `POST /wallets/{walletId}/uma-permissions` | Create a uma-permission for a wallet | Administrator | -| `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | +| Endpoint | Description | Role | +|--------------------------------------------|----------------------------------------|---------------| +| `GET /wallets` | List the wallets on the Cloud Agent | Administrator | +| `POST /wallets` | Create a new wallet on the Cloud Agent | Administrator | +| `POST /wallets/{walletId}/uma-permissions` | Create a uma-permission for a wallet | Administrator | +| `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | ### Keycloak endpoints | Endpoint | Description | Role | @@ -70,7 +70,7 @@ The tenant can access the multi-tenant agent by providing the RPT in the `Author ### 1. Check the existing wallets -When running PRISM Agent using the configurations above, the Agent should start with an empty state. +When running Cloud Agent using the configurations above, the Cloud Agent should start with an empty state. Listing wallets on it should return empty results. ```bash @@ -291,7 +291,7 @@ Example RPT payload (some fields omitted for readability) } ``` -### 3. Perform a simple action to verify access to PRISM Agent +### 3. Perform a simple action to verify access to the Cloud Agent To prove that the tenant can access the wallet using RPT, try listing the DIDs in the wallet using RPT in the `Authorization` header. diff --git a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md index 9738d0035f..d23cce57ad 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding-self-service.md @@ -25,8 +25,8 @@ In self-service tenant management with external IAM, there is only one role: 2. A client called `prism-agent` under `my-realm` with __authorization__ feature is created. (See [create client instruction](https://www.keycloak.org/docs/latest/authorization_services/index.html#_resource_server_create_client)) 3. Make sure the `prism-agent` client has __direct access grants__ enabled to simplify the login process for this tutorial. 4. Make sure to [allow user self-registration](https://www.keycloak.org/docs/latest/server_admin/index.html#con-user-registration_server_administration_guide). -3. PRISM Agent up and running -4. PRISM Agent is configured with the following environment variables: +3. The Cloud Agent up and running +4. The Cloud Agent is configured with the following environment variables: 1. `ADMIN_TOKEN=my-admin-token` 2. `DEFAULT_WALLET_ENABLED=false` 3. `KEYCLOAK_ENABLED=true` @@ -45,11 +45,11 @@ When the agent uses this token for the wallet creation, the agent recognizes it ## Endpoints ### Agent endpoints -| Endpoint | Description | Role | -|---------------------------|------------------------------------|--------| -| `GET /wallets` | List the wallets on PRISM Agent | Tenant | -| `POST /wallets` | Create a new wallet on PRISM Agent | Tenant | -| `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | +| Endpoint | Description | Role | +|---------------------------|----------------------------------------|--------| +| `GET /wallets` | List the wallets on the Cloud Agent | Tenant | +| `POST /wallets` | Create a new wallet on the Cloud Agent | Tenant | +| `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | ### Keycloak endpoints | Endpoint | Description | Role | @@ -153,7 +153,7 @@ Response Example: In this step, the agent creates both wallet resource and UMA permission on Keycloak, assigning the new wallet to the user who created it. -### 5. Perform a simple action to verify access to PRISM Agent +### 5. Perform a simple action to verify access to the Cloud Agent Without further operation, the wallet should be available for the tenant. To prove that the tenant can access the wallet, list the DIDs using RPT in the `Authorization` header. diff --git a/docs/docusaurus/multitenancy/tenant-onboarding.md b/docs/docusaurus/multitenancy/tenant-onboarding.md index 0c085cdf43..19219cfa71 100644 --- a/docs/docusaurus/multitenancy/tenant-onboarding.md +++ b/docs/docusaurus/multitenancy/tenant-onboarding.md @@ -3,7 +3,7 @@ In a multi-tenant setup, it's crucial to understand the various roles within the system. There are two key roles in tenant management: administrators and tenants. Administrators are in charge of managing wallets and tenants, -while tenants are users who engage in standard SSI interactions with the PRISM Agent. +while tenants are users who engage in standard SSI interactions with the Cloud Agent. ## Roles @@ -14,12 +14,12 @@ In tenant management, there are 2 roles: ## Prerequisites -1. PRISM Agent up and running -2. PRISM Agent is configured with the following environment variables: - 1. `ADMIN_TOKEN=my-admin-token` - 2. `API_KEY_ENABLED=true` - 3. `API_KEY_AUTO_PROVISIONING=false` - 4. `DEFAULT_WALLET_ENABLED=false` +1. The Cloud Agent up and running +2. The Cloud Agent is configured with the following environment variables: + 1. `ADMIN_TOKEN=my-admin-token` + 2. `API_KEY_ENABLED=true` + 3. `API_KEY_AUTO_PROVISIONING=false` + 4. `DEFAULT_WALLET_ENABLED=false` ## Overview @@ -27,15 +27,15 @@ This is a guide on how to onboard a new tenant from scratch. This tutorial will demonstrate the creation of a new entity representing the tenant, the provisioning of a wallet, and enabling an authentication method for this tenant. Subsequently, the tenant will gain the capability to engage in SSI activities within an -isolated wallet environment using the PRISM Agent. +isolated wallet environment using the Cloud Agent. ## Endpoints | Endpoint | Description | Role | |-----------------------------------|--------------------------------------------|---------------| -| `GET /wallets` | List the wallets on PRISM Agent | Administrator | -| `POST /wallets` | Create a new wallet on PRISM Agent | Administrator | -| `POST /iam/entities` | Create a new entity on PRISM Agent | Administrator | +| `GET /wallets` | List the wallets on the Cloud Agent | Administrator | +| `POST /wallets` | Create a new wallet on the Cloud Agent | Administrator | +| `POST /iam/entities` | Create a new entity on the Cloud Agent | Administrator | | `POST /iam/apikey-authentication` | Create a new authentication for the entity | Administrator | | `GET /did-registrar/dids` | List the DIDs inside the wallet | Tenant | @@ -43,7 +43,7 @@ isolated wallet environment using the PRISM Agent. ### 1. Check the existing wallets -When running PRISM Agent using the configurations above, the Agent should start with an empty state. +When running the Cloud Agent using the configurations above, the Agent should start with an empty state. Listing wallets on it should return empty results. ```bash @@ -70,7 +70,6 @@ The wallet can be created using a `POST /wallets` endpoint. This wallet is going to act as a container for the tenant's assets (DIDs, VCs, Connections, etc.). The wallet seed may be provided during the wallet creation or omitted to let the Agent generate one randomly. - ```bash curl -X 'POST' \ 'http://localhost:8080/prism-agent/wallets' \ @@ -131,7 +130,8 @@ Response Example: With the new tenant now equipped with both a wallet and an entity, the final step involves setting up the entity's authentication method. -Once this step is completed, the administrator should provide the tenant with an `apikey`, granting them access to utilize the Agent. +Once this step is completed, the administrator should provide the tenant with an `apikey`, granting them access to +utilize the Agent. ```bash curl -X 'POST' \ @@ -151,9 +151,9 @@ HTTP code 201 returns in the case of the successful request execution. ## Tenant interactions -With the `apikey` provisioned by the administrator, the tenant is able to authenticate and use PRISM Agent. +With the `apikey` provisioned by the administrator, the tenant is able to authenticate and use the Cloud Agent. -### 1. Perform a simple action to verify access to PRISM Agent +### 1. Perform a simple action to verify access to the Cloud Agent To prove that the tenant can be authenticated as the created entity and use the wallet, try listing the DIDs in the wallet using `apikey` header. diff --git a/docs/docusaurus/schemas/create.md b/docs/docusaurus/schemas/create.md index b845479782..ef5e0d7ca1 100644 --- a/docs/docusaurus/schemas/create.md +++ b/docs/docusaurus/schemas/create.md @@ -1,6 +1,6 @@ # Create the credential schema -The PRISM platform v2.0 exposes REST API for creation, fetching, and searching the [credential schema](/docs/concepts/glossary#credential-schema) records. +The Identus Platform exposes REST API for creation, fetching, and searching the [credential schema](/docs/concepts/glossary#credential-schema) records. The OpenAPI specification and ReDoc documentation describe the endpoint. @@ -323,7 +323,7 @@ The response should contain the JSON object representing the schema you just cre } ``` -The PRISM Agent instance's triple `author`, `id`, and `version` are unique. +The Cloud Agent instance's triple `author`, `id`, and `version` are unique. So, having a single [DID](/docs/concepts/glossary#decentralized-identifier) reference that the author uses, creating the credential schema with the same `id` and `version` is impossible. diff --git a/docs/docusaurus/schemas/credential-schema.md b/docs/docusaurus/schemas/credential-schema.md index a45196c4f5..c992b1afd0 100644 --- a/docs/docusaurus/schemas/credential-schema.md +++ b/docs/docusaurus/schemas/credential-schema.md @@ -3,7 +3,7 @@ ## Abstract This document describes the purpose, supported formats, and technical details of the Credential Schema implementation in -the Atala PRISM Platform. +the Identus Platform. ## 1. Introduction @@ -13,7 +13,7 @@ of authorship. By putting schema definitions on a public blockchain, they are available for all verifiers to examine to determine the semantic interoperability of the Credential. -The PRISM Platform supports the following specifications of the credential schemas: +The Identus Platform supports the following specifications of the credential schemas: - [Verifiable Credentials JSON Schema 2022](https://w3c-ccg.github.io/vc-json-schemas/) - [AnonCreds Schema](https://hyperledger.github.io/anoncreds-spec/#term:schemas) @@ -30,7 +30,7 @@ The author can use credential schema to issue the following types of verifiable - Anoncred Verifiable Credential - all types above but encoded as JWT -Limitations and constraints of the PRISM Platform v2.0: +Limitations and constraints of the Identus Platform: - The Issuer does not sign the Credential Schema - The Issuer does not publish the Credential Schema to the VDR (the Cardano blockchain) @@ -131,7 +131,7 @@ format. The version field must be the schema evolution and describe the impact of the changes. For the breaking changes, the `major` version must get increased. -In the current implementation, the PRISM Platform doesn't validate whether the new version is backward compatible. +In the current implementation, the Identus Platform doesn't validate whether the new version is backward compatible. This logic may get implemented later, so the Issuer is responsible for correctly setting the credential schema's next version. @@ -232,7 +232,7 @@ A valid [ANONCRED-SCHEMA](https://hyperledger.github.io/anoncreds-spec/#term:sch ### tags (String[]) It is a set of tokens that allow one to look up and filter the credential schema records. -This field is not a part of the W3C specification. Its usage by the PRISM platform for filtering the records. +This field is not a part of the W3C specification. Its usage by the Identus Platform for filtering the records. **Example:** ```json diff --git a/docs/docusaurus/schemas/delete.md b/docs/docusaurus/schemas/delete.md index ada248fe10..b56d7743c8 100644 --- a/docs/docusaurus/schemas/delete.md +++ b/docs/docusaurus/schemas/delete.md @@ -2,7 +2,7 @@ Unfortunately, after publishing (especially in the [Verifiable Data Registry (VDR)](/docs/concepts/glossary#verifiable-data-registry), deleting the credential schema is impossible. -PRISM Platform v2.0 doesn't publish the credential schema in the VDR. This capability will get implemented in the later version of the platform. That's why the platform does not expose the REST API for deletion. +The Identus Platform doesn't publish the credential schema in the VDR. This capability will get implemented in the later version of the platform. That's why the platform does not expose the REST API for deletion. If you need to `delete` the credential schema, you can ask the database administrator or delete it from the Postgres instance by `guid`. diff --git a/docs/docusaurus/schemas/update.md b/docs/docusaurus/schemas/update.md index 80df09a024..abd60ed9b7 100644 --- a/docs/docusaurus/schemas/update.md +++ b/docs/docusaurus/schemas/update.md @@ -1,6 +1,6 @@ # Update the credential schema -The PRISM platform v2.0 exposes REST API for creation, fetching, and searching the credential schema records. +The Identus Platform exposes REST API for creation, fetching, and searching the credential schema records. The OpenAPI specification and ReDoc documentation describe the endpoint. diff --git a/docs/docusaurus/secrets/operation.md b/docs/docusaurus/secrets/operation.md index e4dde0879c..b780a8a97c 100644 --- a/docs/docusaurus/secrets/operation.md +++ b/docs/docusaurus/secrets/operation.md @@ -2,7 +2,7 @@ ## Introduction -PRISM agent offers a DID (Decentralized Identifier) management solution +The Cloud Agent offers a DID (Decentralized Identifier) management solution which involves creating, storing and using key materials. To generate a DID key material, the software relies on a seed, following the BIP32 / BIP39 standards. The system operators have the option to either provide their own seed or @@ -10,12 +10,12 @@ allow the software to generate one automatically. However, in a production envir it is crucial for the system operators to explicitly supply the seed to the agent. This ensures full control over the DID key material and guarantees secure management of user identities. -PRISM agent uses the following environment variables for secret management. +The Cloud Agent uses the following environment variables for secret management. | Name | Description | Default | |--------------------------|-----------------------------------------------------------------|-------------------------| | `SECRET_STORAGE_BACKEND` | The storage backend that will be used for the secret storage | `vault` | -| `VAULT_ADDR` | The address which PRISM Agent can reach the Vault | `http://localhost:8200` | +| `VAULT_ADDR` | The address which the Cloud Agent can reach the Vault | `http://localhost:8200` | | `VAULT_TOKEN` | The token for accessing HashiCorp Vault | - | | `VAULT_APPROLE_ROLE_ID` | The `role_id` for HashiCorp Vault authentication with AppRole | - | | `VAULT_APPROLE_SECRET_ID`| The `secret_id` for HashiCorp Vault authentication with AppRole | - | diff --git a/docs/docusaurus/secrets/secret-storage.md b/docs/docusaurus/secrets/secret-storage.md index 10e4d95fed..04ac684e3c 100644 --- a/docs/docusaurus/secrets/secret-storage.md +++ b/docs/docusaurus/secrets/secret-storage.md @@ -10,48 +10,48 @@ ## Introduction Secrets are sensitive data that should be stored securely. -There are following types of the secrets in the PRISM Platform: +There are following types of the secrets in the Identus Platform: - seed: a secret used to derive cryptographic keys - private key: a secret used to sign data - any other entities that contain sensitive data (for instance, `credential-definition` and the `link-secret` used by the AnonCreds) **NOTE**: public keys are not considered as secrets and can be stored in the same of other storage depending on the needs -The PRISM Platform provides a secure storage for secrets. +The Identus Platform provides a secure storage for secrets. Hashicorp Vault is used as a secret storage service and provides a REST API, Web UI and command client to interact with the service. -**NOTE:** The PRISM Platform uses a single Vault instance for all tenants per environment. Logical data separation is achieved by using Vault namespaces and policies applied to the tenant. +**NOTE:** The Identus Platform uses a single Vault instance for all tenants per environment. Logical data separation is achieved by using Vault namespaces and policies applied to the tenant. ## Terminology ### Vault Vault is a secrets management service developed by HashiCorp. -It can be used as the default secret storage for the PRISM Platform as well as for authentication and account management. +It can be used as the default secret storage for the Identus Platform as well as for authentication and account management. -**NOTE**: The PRISM platform must not be dependent on the Vault service and must be able to use other services for the same purposes +**NOTE**: The Identus Platform must not be dependent on the Vault service and must be able to use other services for the same purposes ### Agent -PRISM Agent is a service that provides an APIs to interact with the PRISM Platform and use the SSI capabilities. +The Cloud Agent is a service that provides an APIs to interact with the Identus Platform and use the SSI capabilities. ### Wallet Logical component of the Agent that holds secrets and provides the logical or physical isolation of the data. ## Technical Overview -### PRISM Agent Logical Isolation -Each instance of the PRISM agent needs to have access to the secrets but must be isolated from other agents at the same environment. +### The Cloud Agent Logical Isolation +Each instance of the Cloud Agent needs to have access to the secrets but must be isolated from other agents at the same environment. For horizontal scalability the group of agents can be configured to share the same namespace, so they can access the same secrets, but they still need to use different Vault account to authenticate themselves to the Vault service. -### PRISM Agent Authentication -Each instance of the PRISM agent needs to authenticate itself to the Vault service. +### The Cloud Agent Authentication +Each instance of the Cloud Agent needs to authenticate itself to the Vault service. The Vault service uses a token-based authentication mechanism. -The PRISM agent uses a Vault [AppRole](https://developer.hashicorp.com/vault/docs/auth/approle) authentication method to authenticate itself to the Vault service. +The Cloud Agent uses a Vault [AppRole](https://developer.hashicorp.com/vault/docs/auth/approle) authentication method to authenticate itself to the Vault service. The token issued to the agent has the expiration time set in the application configuration. After the token expires, the agent needs to re-authenticate itself to the Vault service. ### Wallet Authentication Each instance of the Wallet needs to authenticate itself to the Vault service. -The PRISM agent issues the authentication token to the Wallet based on the tenant ID. +The Cloud Agent issues the authentication token to the Wallet based on the tenant ID. ### Secrets Engine Configuration The Vault service uses a secrets engine to store secrets. @@ -64,9 +64,9 @@ KV2 secrets engine is used to store secrets in the Vault service and provides th - secrets are logically separated by tenants ### Single and Multi-Tenant Configuration -The PRISM Platform supports single and multi-tenant configurations. -In the single-tenant configuration, the PRISM Agent uses a single Wallet and a single Vault account to authenticate itself to the Vault service. -In the multi-tenant configuration, the PRISM Agent manages multiple Wallets, each Wallet is associated with a single tenant. +The Identus Platform supports single and multi-tenant configurations. +In the single-tenant configuration, the Cloud Agent uses a single Wallet and a single Vault account to authenticate itself to the Vault service. +In the multi-tenant configuration, the Cloud Agent manages multiple Wallets, each Wallet is associated with a single tenant. Multi-tenant configuration is used to achieve logical data separation between tenants, so each Wallet can access only its own secrets. The Wallet is identified by the tenant ID and represented by the account in the Vault service. @@ -85,7 +85,7 @@ sequenceDiagram ### Key Derivation -The PRISM Platform uses HD key derivation to derive cryptographic keys from the seed. +The Identus Platform uses HD key derivation to derive cryptographic keys from the seed. The Wallet is initialized with the seed and uses it to derive cryptographic keys for managed DIDs. Key derivation path is conventional and is defined as follows: ``` diff --git a/docs/docusaurus/secrets/seed-generation.md b/docs/docusaurus/secrets/seed-generation.md index 6f3b3bdb1f..5d9e805819 100644 --- a/docs/docusaurus/secrets/seed-generation.md +++ b/docs/docusaurus/secrets/seed-generation.md @@ -1,23 +1,23 @@ -# Creating a PRISM agent wallet seed +# Creating the Cloud Agent wallet seed ## Introduction -PRISM agent utilizes a hierarchical-deterministic key derivation algorithm for managing PRISM DIDs, +The Cloud Agent utilizes a hierarchical-deterministic key derivation algorithm for managing PRISM DIDs, which follows the BIP32 standard. In order to generate the required keys, BIP32 uses a master binary seed serving as the root of the derivation tree, and all other keys are derived from this seed. -Given that the PRISM agent employs BIP32, it expects a 64-byte binary seed as input. +Given that the Cloud Agent employs BIP32, it expects a 64-byte binary seed as input. Various methods exist for generating a byte sequence, each serving different purposes. -PRISM agent does not have any opinion on how the seed should be generated as long as a valid hex string is provided. +The Cloud Agent does not have any opinion on how the seed should be generated as long as a valid hex string is provided. However, it is strongly recommended to use high entropy for generating the master seed. -PRISM agent allows customizing the default wallet seed by using the environment variable `DEFAULT_WALLET_SEED`. +The Cloud Agent allows customizing the default wallet seed by using the environment variable `DEFAULT_WALLET_SEED`. Other wallet seeds can also be configured when creating a wallet using REST API. The variable must contain a 64-byte value encoded in hexadecimal format. ### 1. Static seed -PRISM agent expects any valid 64-byte input for a wallet seed. +The Cloud Agent expects any valid 64-byte input for a wallet seed. Any static 128-character hexadecimal string can be used to simplify the testing. For example diff --git a/docs/docusaurus/secrets/sequence-diagrams.md b/docs/docusaurus/secrets/sequence-diagrams.md index 55524f6e9b..a23c2babb2 100644 --- a/docs/docusaurus/secrets/sequence-diagrams.md +++ b/docs/docusaurus/secrets/sequence-diagrams.md @@ -8,7 +8,7 @@ ## Introduction -The current document describes the sequence diagrams of the PRISM platform components: APISIX, Agent, Wallet, Vault, Tenant. +The current document describes the sequence diagrams of the Identus Platform components: APISIX, Cloud Agent, Wallet, Vault, Tenant. The diagrams are stated from the simplest scenarios to the more complex ones to enforce the security and privacy of the data. ## Sequence Diagrams @@ -84,12 +84,12 @@ sequenceDiagram This diagram describes the flow for the secret management for the single tenant with the Wallet. -Goal: Tenant uses JWT token to authenticate to the PRISM platform. +Goal: Tenant uses JWT token to authenticate to the Identus Platform. Context: - The Agent is authenticated to the Vault using the AppRole authentication method. - Tenant uses the access token to access the REST API via APISIX (probably this might be removed, we need to decide what to do with the `api-token`) -- Tenant represented by any REST API client, Web or Mobile application authenticated to the PRISM platform using JWT token. +- Tenant represented by any REST API client, Web or Mobile application authenticated to the Identus Platform using JWT token. - Tenant uses the Wallet to communicate with the Vault diff --git a/docs/docusaurus/webhooks/webhook.md b/docs/docusaurus/webhooks/webhook.md index 359d6aba84..25069f484d 100644 --- a/docs/docusaurus/webhooks/webhook.md +++ b/docs/docusaurus/webhooks/webhook.md @@ -2,8 +2,8 @@ ## Introduction -Welcome to the tutorial on webhook notifications in PRISM Agent. In this tutorial, we will explore how webhook -notifications can enhance your experience with PRISM Agent by providing real-time updates on events. By leveraging +Welcome to the tutorial on webhook notifications in the Cloud Agent. In this tutorial, we will explore how webhook +notifications can enhance your experience with the Cloud Agent by providing real-time updates on events. By leveraging webhook notifications, you can stay informed about important changes happening within the agent. ## Understanding Webhook Notifications @@ -15,9 +15,9 @@ endpoints (webhook URLs) when events occur. They establish a direct communicatio receive instant updates and respond in a timely manner, promoting efficient integration between event-driven systems. -### Purpose of Webhook Notifications in PRISM Agent +### Purpose of Webhook Notifications in the Cloud Agent -Webhook notifications in PRISM Agent serve as a vital feature, enabling you to receive timely updates on various events +Webhook notifications in the CLoud Agent serve as a vital feature, enabling you to receive timely updates on various events occurring within the agent. Webhooks allow you to receive HTTP requests containing event details at a specified endpoint (webhook URL). These events are specifically related to the execution of the [Connect](/tutorials/connections/connection), [Issue](/tutorials/credentials/issue), @@ -25,7 +25,7 @@ and [Presentation](/tutorials/credentials/present-proof) flows. Webhook notifica state change during the execution of these protocols. -By leveraging webhooks, you can integrate PRISM Agent seamlessly into your applications and systems. You can track and +By leveraging webhooks, you can integrate the Cloud Agent seamlessly into your applications and systems. You can track and monitor the progress of the main flows, receiving timely updates about changes and events. ## Configuring the Webhook Feature @@ -33,12 +33,12 @@ monitor the progress of the main flows, receiving timely updates about changes a ### Enabling the Webhook Feature There are two kinds of webhook notifications: global webhooks and wallet webhooks. -Global webhooks capture all events that happen on the PRISM Agent across all wallets, +Global webhooks capture all events that happen on the Cloud Agent across all wallets, whereas wallet webhooks only capture events that are specific to assets within a particular wallet. #### Enable global webhook using environment variables -PRISM Agent uses the following environment variables to manage global webhook notifications: +The Cloud Agent uses the following environment variables to manage global webhook notifications: | Name | Description | Default | |--------------------------|--------------------------------------------------------------------------|---------| @@ -47,13 +47,13 @@ PRISM Agent uses the following environment variables to manage global webhook no #### Enable wallet webhook for default wallet using environment variables -In a multi-tenant scenario, the PRISM Agent can optionally create a default wallet to simplify the development and deployment process. +In a multi-tenant scenario, the Cloud Agent can optionally create a default wallet to simplify the development and deployment process. The webhook configuration for this default wallet can be defined using environment variables. After the default wallet is created, its webhook settings are stored in the system and are no longer influenced by these environment variables. | Name | Description | Default | |----------------------------------|--------------------------------------------------------------------------|---------| -| `DEFAULT_WALLET_ENABLED` | Automatically create default on PRISM Agent startup | true | +| `DEFAULT_WALLET_ENABLED` | Automatically create default on the Cloud Agent startup | true | | `DEFAULT_WALLET_WEBHOOK_URL` | The webhook endpoint URL where the notifications will be sent | null | | `DEFAULT_WALLET_WEBHOOK_API_KEY` | The optional API key (bearer token) to use as the `Authorization` header | null | @@ -89,11 +89,11 @@ Response Example: It is essential to secure the webhook endpoint to protect the integrity and confidentiality of the event data. Consider the following best practices when securing your webhook endpoint: -- Use HTTPS to encrypt communication between PRISM Agent and the webhook endpoint. +- Use HTTPS to encrypt communication between the Cloud Agent and the webhook endpoint. - Implement authentication mechanisms (e.g., API keys, tokens) to verify the authenticity of incoming requests. - Validate and sanitize incoming webhook requests to mitigate potential security risks. -One of the authorization mechanism for PRISM Agent's webhook notifications is the bearer token. If +One of the authorization mechanism for the Cloud Agent's webhook notifications is the bearer token. If configured, the token will be included in the `Authorization` header of the HTTP request sent by the agent to the webhook endpoint. You can configure this bearer token by setting the value of the `GLOBAL_WEBHOOK_API_KEY` or `DEFAULT_WALLET_WEBHOOK_API_KEY` environment variable. @@ -105,7 +105,7 @@ This option offers increased flexibility when custom or multiple headers are nee ### Event Format -Webhook notifications from PRISM Agent are sent as JSON payloads in the HTTP requests. +Webhook notifications from the Cloud Agent are sent as JSON payloads in the HTTP requests. The event format is consistent across all events. Each event follows a common structure, while the 'data' field within the event payload contains information specific to the type of event. Here is an example of the JSON payload @@ -155,7 +155,7 @@ generated): ### Common Event Types -PRISM Agent sends webhook notifications for events related to protocol state changes in +The Cloud Agent sends webhook notifications for events related to protocol state changes in the [Connect](/tutorials/connections/connection), [Issue](/tutorials/credentials/issue), [Presentation](/tutorials/credentials/present-proof) flows, and also [DID publication](/tutorials/dids/publish) state changes. These events allow you to track the progress and updates within these flows in real-time. @@ -198,21 +198,21 @@ State change notifications that you can expect to receive through webhook notifi ### Handling Incoming Webhook Requests -To handle incoming webhook notifications from PRISM Agent in your application, follow these general steps: +To handle incoming webhook notifications from the Cloud Agent in your application, follow these general steps: 1. Receive the HTTP request at your specified webhook endpoint. 2. Parse the JSON payload of the request to extract the event details. 3. Process the event data according to your application's requirements. 4. Send a response back to acknowledge the successful receipt of the webhook notification. For a successful reception, the response status code should be `>= 200` and `< 300`. Any other response status code will lead to a new attempt - from the PRISM Agent. + from the Cloud Agent. ### Error Handling and Retry Mechanisms -When working with webhook notifications in PRISM Agent, it is important to consider error handling and retry mechanisms. -In case of failed webhook notifications or errors, PRISM Agent employs an automatic retry mechanism to ensure delivery. +When working with webhook notifications in the Cloud Agent, it is important to consider error handling and retry mechanisms. +In case of failed webhook notifications or errors, the Cloud Agent employs an automatic retry mechanism to ensure delivery. The agent will attempt to send the webhook notification up to three times, with a five-second interval between each -attempt. Please note that the number of retries and the interval duration are currently not configurable in PRISM Agent. +attempt. Please note that the number of retries and the interval duration are currently not configurable in the Cloud Agent. By default, this retry mechanism provides a reasonable level of reliability for delivering webhook notifications, allowing for temporary network issues or intermittent failures. @@ -312,12 +312,12 @@ if __name__ == '__main__': ## Conclusion -Congratulations! You've learned about webhook notifications in PRISM Agent. By leveraging this feature, you can receive -real-time updates on events happening within the agent, enabling you to integrate PRISM Agent seamlessly into your +Congratulations! You've learned about webhook notifications in the Cloud Agent. By leveraging this feature, you can receive +real-time updates on events happening within the agent, enabling you to integrate the Cloud Agent seamlessly into your applications. Remember to secure your webhook endpoint and handle webhook notifications effectively to maximize the benefits of this feature. -Start integrating webhook notifications into your PRISM Agent workflow and unlock the power of real-time event updates! +Start integrating webhook notifications into your Cloud Agent workflow and unlock the power of real-time event updates! -If you have any further questions or need assistance, don't hesitate to reach out to the PRISM Agent support team or +If you have any further questions or need assistance, don't hesitate to reach out to the Identus support team or refer to the official documentation for more details. \ No newline at end of file From cae2b2c48435f928f1aa0f049a7e54608c6cb109 Mon Sep 17 00:00:00 2001 From: Yurii Shynbuiev Date: Wed, 1 May 2024 19:39:22 +0700 Subject: [PATCH 05/11] ci: add OAS breaking change detection Signed-off-by: Yurii Shynbuiev --- .github/workflows/oasdiff.yml | 67 +++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 .github/workflows/oasdiff.yml diff --git a/.github/workflows/oasdiff.yml b/.github/workflows/oasdiff.yml new file mode 100644 index 0000000000..f6dfd84a17 --- /dev/null +++ b/.github/workflows/oasdiff.yml @@ -0,0 +1,67 @@ +--- +name: "Cloud Agent OAS Breaking changes" +run-name: "Cloud Agent OAS Diff between revision ${{ inputs.revision_tag }} and base ${{ inputs.base_tag }}" + +on: + pull_request: + branches: + - main + + workflow_dispatch: + inputs: + revision_tag: + required: true + type: string + description: "Revision tag to check the breaking changes in the OAS" + base_tag: + required: false + type: string + description: "Base tag to to check the breaking changes in the OAS" + default: "main" + +# https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/prism-agent-v1.29.0/prism-agent/service/api/http/prism-agent-openapi-spec.yaml +# https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/main/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml + +jobs: + oasdiff-breaking: + name: "Open API specification breaking changes detection" + runs-on: ubuntu-latest + steps: + - name: Resolve the base OpenAPI spec URL + run: | + BASE_TAG="${{ github.event.inputs.base_tag }}" + if [[ BASE_TAG == cloud-agent-v* ]]; then + echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV + elif [[ BASE_TAG == prism-agent-v* ]]; then + echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/prism-agent/service/api/http/prism-agent-openapi-spec.yaml" >> $GITHUB_ENV + elif [[ BASE_TAG == main ]]; then + echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV + fi + + - name: Resolve the revision OpenAPI spec URL + run: | + REV_TAG="${{ github.event.inputs.revision_tag }}" + if [[ REV_TAG == cloud-agent-v* ]]; then + echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV + elif [[ REV_TAG == prism-agent-v* ]]; then + echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/prism-agent/service/api/http/prism-agent-openapi-spec.yaml" >> $GITHUB_ENV + elif [[ REV_TAG == main ]]; then + echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV + fi + + - name: Check URLS + run: | + echo "Base url: ${{ env.BASE_URL }}" + echo "Revision url: ${{ env.REV_URL}}" + + - name: Running OpenAPI Spec diff action + uses: oasdiff/oasdiff-action/breaking@main + with: + fail-on-diff: false + base: ${{ env.BASE_URL }} + revision: ${{ env.REV_URL }} + + + + + From a66c6047f8649f8501bdd140dbe6f7122daea505 Mon Sep 17 00:00:00 2001 From: Yurii Shynbuiev Date: Wed, 1 May 2024 19:48:04 +0700 Subject: [PATCH 06/11] ci: fix gh action Signed-off-by: Yurii Shynbuiev --- .github/workflows/oasdiff.yml | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/.github/workflows/oasdiff.yml b/.github/workflows/oasdiff.yml index f6dfd84a17..0a1bd1cc83 100644 --- a/.github/workflows/oasdiff.yml +++ b/.github/workflows/oasdiff.yml @@ -2,11 +2,14 @@ name: "Cloud Agent OAS Breaking changes" run-name: "Cloud Agent OAS Diff between revision ${{ inputs.revision_tag }} and base ${{ inputs.base_tag }}" -on: - pull_request: - branches: - - main +defaults: + run: + shell: bash +on: +# pull_request: +# branches: +# - main workflow_dispatch: inputs: revision_tag: From 115327e5010b146393d2f1c0a7ba090e6c952471 Mon Sep 17 00:00:00 2001 From: Yurii Shynbuiev Date: Wed, 1 May 2024 19:56:42 +0700 Subject: [PATCH 07/11] ci: debug the gh action Signed-off-by: Yurii Shynbuiev --- .github/workflows/oasdiff.yml | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/.github/workflows/oasdiff.yml b/.github/workflows/oasdiff.yml index 0a1bd1cc83..8557377eeb 100644 --- a/.github/workflows/oasdiff.yml +++ b/.github/workflows/oasdiff.yml @@ -1,6 +1,6 @@ --- name: "Cloud Agent OAS Breaking changes" -run-name: "Cloud Agent OAS Diff between revision ${{ inputs.revision_tag }} and base ${{ inputs.base_tag }}" +run-name: "Cloud Agent OAS Diff between revision ${{ github.event.inputs.revision_tag }} and base ${{ github.event.inputs.base_tag }}" defaults: run: @@ -10,6 +10,7 @@ on: # pull_request: # branches: # - main + workflow_dispatch: inputs: revision_tag: @@ -33,22 +34,22 @@ jobs: - name: Resolve the base OpenAPI spec URL run: | BASE_TAG="${{ github.event.inputs.base_tag }}" - if [[ BASE_TAG == cloud-agent-v* ]]; then + if [[ $BASE_TAG == cloud-agent-v* ]]; then echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [[ BASE_TAG == prism-agent-v* ]]; then + elif [[ $BASE_TAG == prism-agent-v* ]]; then echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/prism-agent/service/api/http/prism-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [[ BASE_TAG == main ]]; then + elif [[ $BASE_TAG == main ]]; then echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV fi - name: Resolve the revision OpenAPI spec URL run: | REV_TAG="${{ github.event.inputs.revision_tag }}" - if [[ REV_TAG == cloud-agent-v* ]]; then + if [[ $REV_TAG == cloud-agent-v* ]]; then echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [[ REV_TAG == prism-agent-v* ]]; then + elif [[ $REV_TAG == prism-agent-v* ]]; then echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/prism-agent/service/api/http/prism-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [[ REV_TAG == main ]]; then + elif [[ $REV_TAG == main ]]; then echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV fi From 324d0a0f6744da59017b72ab5090c0e520077fdf Mon Sep 17 00:00:00 2001 From: Yurii Shynbuiev Date: Wed, 1 May 2024 20:14:49 +0700 Subject: [PATCH 08/11] ci: fix oasdiff.yml Signed-off-by: Yurii Shynbuiev --- .github/workflows/oasdiff.yml | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/.github/workflows/oasdiff.yml b/.github/workflows/oasdiff.yml index 8557377eeb..443aad08c0 100644 --- a/.github/workflows/oasdiff.yml +++ b/.github/workflows/oasdiff.yml @@ -7,9 +7,9 @@ defaults: shell: bash on: -# pull_request: -# branches: -# - main + pull_request: + branches: + - main workflow_dispatch: inputs: @@ -34,23 +34,28 @@ jobs: - name: Resolve the base OpenAPI spec URL run: | BASE_TAG="${{ github.event.inputs.base_tag }}" - if [[ $BASE_TAG == cloud-agent-v* ]]; then + if [ $BASE_TAG == 'cloud-agent-v*' ]; then echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [[ $BASE_TAG == prism-agent-v* ]]; then + elif [ $BASE_TAG == 'prism-agent-v*' ]; then echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/prism-agent/service/api/http/prism-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [[ $BASE_TAG == main ]]; then + elif [ $BASE_TAG == 'main' ]; then echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV + elif [ ${{ github.event_name }} == 'pull_request' ]; then + echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/main/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV fi - name: Resolve the revision OpenAPI spec URL run: | REV_TAG="${{ github.event.inputs.revision_tag }}" - if [[ $REV_TAG == cloud-agent-v* ]]; then + if [ $REV_TAG == 'cloud-agent-v*' ]; then echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [[ $REV_TAG == prism-agent-v* ]]; then + elif [ $REV_TAG == 'prism-agent-v*' ]; then echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/prism-agent/service/api/http/prism-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [[ $REV_TAG == main ]]; then + elif [ $REV_TAG == 'main' ]; then echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV + elif [ ${{ github.event_name }} == 'pull_request' ]; then + BRANCH_NAME: ${{ github.head_ref || github.ref_name }} + echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BRANCH_NAME/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV fi - name: Check URLS From b16066da210949838256c41ccf33a523f0b15b2e Mon Sep 17 00:00:00 2001 From: Yurii Shynbuiev Date: Wed, 1 May 2024 20:21:20 +0700 Subject: [PATCH 09/11] ci: fix oasdiff.yml 2 Signed-off-by: Yurii Shynbuiev --- .github/workflows/oasdiff.yml | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/.github/workflows/oasdiff.yml b/.github/workflows/oasdiff.yml index 443aad08c0..03f99f3e6a 100644 --- a/.github/workflows/oasdiff.yml +++ b/.github/workflows/oasdiff.yml @@ -34,26 +34,28 @@ jobs: - name: Resolve the base OpenAPI spec URL run: | BASE_TAG="${{ github.event.inputs.base_tag }}" - if [ $BASE_TAG == 'cloud-agent-v*' ]; then + echo "Base tag: $BASE_TAG" + if [[ $BASE_TAG == 'cloud-agent-v*' ]]; then echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [ $BASE_TAG == 'prism-agent-v*' ]; then + elif [[ $BASE_TAG == 'prism-agent-v*' ]]; then echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/prism-agent/service/api/http/prism-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [ $BASE_TAG == 'main' ]; then + elif [[ $BASE_TAG == 'main' ]]; then echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BASE_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [ ${{ github.event_name }} == 'pull_request' ]; then + elif [[ ${{ github.event_name }} == 'pull_request' ]]; then echo "BASE_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/main/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV fi - name: Resolve the revision OpenAPI spec URL run: | REV_TAG="${{ github.event.inputs.revision_tag }}" - if [ $REV_TAG == 'cloud-agent-v*' ]; then + echo "Revision tag: $REV_TAG" + if [[ $REV_TAG == 'cloud-agent-v*' ]]; then echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [ $REV_TAG == 'prism-agent-v*' ]; then + elif [[ $REV_TAG == 'prism-agent-v*' ]]; then echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/prism-agent/service/api/http/prism-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [ $REV_TAG == 'main' ]; then + elif [[ $REV_TAG == 'main' ]]; then echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV - elif [ ${{ github.event_name }} == 'pull_request' ]; then + elif [[ ${{ github.event_name }} == 'pull_request' ]]; then BRANCH_NAME: ${{ github.head_ref || github.ref_name }} echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BRANCH_NAME/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV fi From 661e8a2aa09ce5ece836b9d223bd58719074dbd5 Mon Sep 17 00:00:00 2001 From: Yurii Shynbuiev Date: Wed, 1 May 2024 20:25:08 +0700 Subject: [PATCH 10/11] ci: fix oasdiff.yml 3 Signed-off-by: Yurii Shynbuiev --- .github/workflows/oasdiff.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/oasdiff.yml b/.github/workflows/oasdiff.yml index 03f99f3e6a..2cbd53ea84 100644 --- a/.github/workflows/oasdiff.yml +++ b/.github/workflows/oasdiff.yml @@ -56,14 +56,14 @@ jobs: elif [[ $REV_TAG == 'main' ]]; then echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$REV_TAG/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV elif [[ ${{ github.event_name }} == 'pull_request' ]]; then - BRANCH_NAME: ${{ github.head_ref || github.ref_name }} + BRANCH_NAME=${{ github.head_ref || github.ref_name }} echo "REV_URL=https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/$BRANCH_NAME/cloud-agent/service/api/http/cloud-agent-openapi-spec.yaml" >> $GITHUB_ENV fi - name: Check URLS run: | echo "Base url: ${{ env.BASE_URL }}" - echo "Revision url: ${{ env.REV_URL}}" + echo "Revision url: ${{ env.REV_URL }}" - name: Running OpenAPI Spec diff action uses: oasdiff/oasdiff-action/breaking@main From b23eae451ee12a015ace387357f4054ae9e28b4f Mon Sep 17 00:00:00 2001 From: Yurii Shynbuiev Date: Wed, 1 May 2024 20:29:38 +0700 Subject: [PATCH 11/11] ci: cleanup Signed-off-by: Yurii Shynbuiev --- .github/workflows/oasdiff.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/oasdiff.yml b/.github/workflows/oasdiff.yml index 2cbd53ea84..463d95f898 100644 --- a/.github/workflows/oasdiff.yml +++ b/.github/workflows/oasdiff.yml @@ -1,6 +1,6 @@ --- -name: "Cloud Agent OAS Breaking changes" -run-name: "Cloud Agent OAS Diff between revision ${{ github.event.inputs.revision_tag }} and base ${{ github.event.inputs.base_tag }}" +name: "OAS Breaking Changes" + defaults: run: @@ -20,7 +20,7 @@ on: base_tag: required: false type: string - description: "Base tag to to check the breaking changes in the OAS" + description: "Base tag to check the breaking changes in the OAS" default: "main" # https://raw.githubusercontent.com/hyperledger/identus-cloud-agent/prism-agent-v1.29.0/prism-agent/service/api/http/prism-agent-openapi-spec.yaml