Merge branch 'main' into ci/release-workflow

README.md

@@ -58,7 +58,7 @@ All documentation, tutorials and API references for the Identus ecosystem can be
 
 Before starting to use the Cloud Agent, it is important to understand the basic concepts of self-sovereign identity (SSI). The following resources provide a good introduction to SSI:
 
-* [Identus SSI introduction](https://hyperledger.github.io/identus-docs/docs/category/concepts)
+* [Identus SSI introduction](https://hyperledger-identus.github.io/docs/home/category/concepts)
 * [Linux Foundation Course: Getting Started with SSI](https://www.edx.org/learn/computer-programming/the-linux-foundation-getting-started-with-self-sovereign-identity)
 
 ### Architecture

cloud-agent/service/server/src/main/scala/org/hyperledger/identus/issue/controller/http/CreateIssueCredentialRecordRequest.scala

@@ -333,6 +333,7 @@ object CreateIssueCredentialRecordRequest {
           validator = Validator.enumeration(
             List(
               Some("JWT"),
+              Some("SDJWT"),
               Some("AnonCreds")
             )
           )

cloud-agent/service/server/src/main/scala/org/hyperledger/identus/issue/controller/http/IssueCredentialRecord.scala

@@ -186,6 +186,7 @@ object IssueCredentialRecord {
           validator = Validator.enumeration(
             List(
               "JWT",
+              "SDJWT",
               "AnonCreds"
             )
           )

docs/docusaurus/connections/connection.md

@@ -2,15 +2,15 @@
 
 A connection is a stateful relationship between two parties that enables secure communication.
 
-The [Connection protocol](/docs/concepts/glossary#connection-protocol) is required to establish secure connections between agents,
+The [Connection protocol](/home/concepts/glossary#connection-protocol) is required to establish secure connections between agents,
 allowing them to exchange information and interact.
 
 ## Roles
 
 The connection protocol has two roles:
 
-1. [Inviter](/docs/concepts/glossary#inviter): A subject that initiates a connection request by sending a [connection invitation](/docs/concepts/glossary#connection-invitation).
-2. [Invitee](/docs/concepts/glossary#invitee): A subject that receives a connection invitation and accepts it by sending a [connection request](/docs/concepts/glossary#connection-request).
+1. [Inviter](/home/concepts/glossary#inviter): A subject that initiates a connection request by sending a [connection invitation](/home/concepts/glossary#connection-invitation).
+2. [Invitee](/home/concepts/glossary#invitee): A subject that receives a connection invitation and accepts it by sending a [connection request](/home/concepts/glossary#connection-request).
 
 ## Prerequisites
 
@@ -55,7 +55,7 @@ ConnectionResponseSent --> [*]
 
 1. Receive the OOB invitation (`InvitationReceived` state)
 2. Accept the invitation (connection is created in `ConnectionRequestPending` state)
-3. Send the connection request via [DIDComm](/docs/concepts/glossary#didcomm) (connection achieves `ConnectionRequestSent` state)
+3. Send the connection request via [DIDComm](/home/concepts/glossary#didcomm) (connection achieves `ConnectionRequestSent` state)
 4. Receive the connection response (connection achieves `ConnectionResponseReceived` state)
 
 The following diagram represents the Invitee's Connection state transitions:

docs/docusaurus/credentialdefinition/create.md

@@ -1,6 +1,6 @@
 # Create the Credential Definition
 
-The Cloud Agent exposes REST API for creation, fetching, and searching the [credential definition](/docs/concepts/glossary#credential-definition) records.
+The Cloud Agent exposes REST API for creation, fetching, and searching the [credential definition](/home/concepts/glossary#credential-definition) records.
 
 The OpenAPI specification and ReDoc documentation describe the endpoint.
 
@@ -39,7 +39,7 @@ Here's a sample content of the credential definition:
 
 2. In your API client, initiate a new POST request to either `/credential-definition-registry/definitions` or `/credential-definition-registry/definitions/did-url`  endpoints. They both take the same payload
     1. `/credential-definition-registry/definitions` creates a credential definition that can later be resolved via HTTP URL
-    2. `/credential-definition-registry/definitions/did-url` creates a credential definition that can later be resolved via [DID URL](/docs/concepts/glossary#did-url), the DID includes a service endpoint with the location of the credential definition registry.
+    2. `/credential-definition-registry/definitions/did-url` creates a credential definition that can later be resolved via [DID URL](/home/concepts/glossary#did-url), the DID includes a service endpoint with the location of the credential definition registry.
 
 Please note: The `author` field value should align with the short form of a PRISM DID previously created by the same agent. It's okay if this DID is unpublished. You can refer to the [Create DID](../dids/create.md) documentation for more comprehensive details on crafting a PRISM DID.
 
@@ -148,7 +148,7 @@ You should receive a response containing the JSON object representing the creden
 }
 ```
 
-Or in case of DID URL, the respoinse is [Prism Envelope](/docs/concepts/glossary#prism-envelope)
+Or in case of DID URL, the respoinse is [Prism Envelope](/home/concepts/glossary#prism-envelope)
 
 ```json
 {

docs/docusaurus/credentialdefinition/delete.md

@@ -1,6 +1,6 @@
 # Delete the Credential Definition
 
-Unfortunately, once published (especially in the [Verifiable Data Registry (VDR)](/docs/concepts/glossary#verifiable-data-registry), deleting the credential definition becomes unfeasible.
+Unfortunately, once published (especially in the [Verifiable Data Registry (VDR)](/home/concepts/glossary#verifiable-data-registry), deleting the credential definition becomes unfeasible.
 
 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.
 

docs/docusaurus/credentials/connectionless/issue.md

@@ -3,14 +3,14 @@ import TabItem from '@theme/TabItem';
 
 # Issue credentials (Connectionless)
 
-In the Identus Platform, the [Issue Credentials Protocol](/docs/concepts/glossary#issue-credential-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](/home/concepts/glossary#issue-credential-protocol) allows you to create, retrieve, and manage issued [verifiable credentials (VCs)](/home/concepts/glossary#verifiable-credentials) between a VC issuer and a VC holder.
 
 ## Roles
 
 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.
+1. The [Issuer](/home/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](/home/concepts/glossary#holder) is responsible for accepting a credential offer from an issuer and receiving the VC.
 
 The Issuer and Holder interact with the Identus Cloud Agent API to perform the operations defined in the protocol.
 
@@ -23,14 +23,14 @@ Before using the "Connectionless" Issuing Credentials protocol, the following co
 <TabItem value="jwt" label="JWT">
 
 1. Issuer Cloud Agents is up and running
-2. The Issuer has 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))
+2. The Issuer has a published PRISM DID, and the [DID document](/home/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))
 3. The Holder is either another Cloud Agent or Edge Agent SDK
 
 </TabItem>
 <TabItem value="anoncreds" label="AnonCreds">
 
 1. Issuer Cloud Agents is up and running
-2. The Issuer has 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))
+2. The Issuer has a published PRISM DID, and the [DID document](/home/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))
 3. The Issuer must have created an AnonCreds Credential Definition as described [here](../../credentialdefinition/create.md).
 4. The Holder is either another Cloud Agent or Edge Agent SDK
 
@@ -39,7 +39,7 @@ Before using the "Connectionless" Issuing Credentials protocol, the following co
 
 - 📌 **Note:** Currently we only support `Ed25519` curve
 1. Issuer Cloud Agents is up and running
-2. The Issuer has 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))
+2. The Issuer has a published PRISM DID, and the [DID document](/home/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))
 3. The Holder is either another Cloud Agent or Edge Agent SDK
 4. The Holder must have a PRISM DID, and the DID document must have at least one `authentication` key for presenting the proof and the curve must be `Ed25519`.
 
@@ -52,7 +52,7 @@ The protocol described is a VC issuance process between an Issuer (Identus Cloud
 
 The protocol consists of the following main parts:
 
-1. The Issuer creates a new credential offer using the [`/issue-credentials/credential-offers/invitation`](/identus-docs/agent-api/#tag/Issue-Credentials-Protocol/operation/createCredentialOffer) endpoint, which includes information such as the schema identifier and claims. This returns a unique OOB (out-of-band) invitate code for the prospective Holder.
+1. The Issuer creates a new credential offer using the [`/issue-credentials/credential-offers/invitation`](/docs/agent-api/#tag/Issue-Credentials-Protocol/operation/createCredentialOffer) endpoint, which includes information such as the schema identifier and claims. This returns a unique OOB (out-of-band) invitate code for the prospective Holder.
 2. The Holder accepts the OOB invite (see SDK `acceptInvitation`)
 3. The Issuer responds by sending the actual Credential Offer
 4. The Holder accepts the Credential Offer
@@ -285,7 +285,7 @@ To accept the offer, the Holder can make a `POST` request to the [`/issue-creden
 <TabItem value="jwt" label="JWT">
 
 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`.
+2. `subjectId`: This field represents the unique identifier for the subject of the verifiable credential. It is a short-form PRISM [DID](/home/concepts/glossary#decentralized-identifier) string, such as `did:prism:subjectIdentifier`.
 
 ```shell
 # Holder POST request to accept the credential offer
@@ -317,7 +317,7 @@ curl -X POST "http://localhost:8090/cloud-agent/issue-credentials/records/$holde
 <TabItem value="sdjwt" label="SDJWT">
 
 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`.
+2. `subjectId`: This field represents the unique identifier for the subject of the verifiable credential. It is a short-form PRISM [DID](/home/concepts/glossary#decentralized-identifier) string, such as `did:prism:subjectIdentifier`.
 3. `keyId` Option parameter
    1. when keyId is not provided the SDJWT VC is not binded to Holder/Prover key
    ```shell

docs/docusaurus/credentials/didcomm/issue.md

@@ -3,17 +3,17 @@ import TabItem from '@theme/TabItem';
 
 # Issue credentials (DIDComm)
 
-In the Identus Platform, the [Issue Credentials Protocol](/docs/concepts/glossary#issue-credential-protocol) allows you
-to create, retrieve, and manage issued [verifiable credentials (VCs)](/docs/concepts/glossary#verifiable-credentials)
+In the Identus Platform, the [Issue Credentials Protocol](/home/concepts/glossary#issue-credential-protocol) allows you
+to create, retrieve, and manage issued [verifiable credentials (VCs)](/home/concepts/glossary#verifiable-credentials)
 between a VC issuer and a VC holder.
 
 ## Roles
 
 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
+1. The [Issuer](/home/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
+2. The [Holder](/home/concepts/glossary#holder) is responsible for accepting a credential offer from an issuer and
    receiving the VC.
 
 The Issuer and Holder interact with the Identus Cloud Agent API to perform the operations defined in the protocol.
@@ -28,7 +28,7 @@ Before using the Issuing Credentials protocol, the following conditions must be
 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
+3. The Issuer must have a published PRISM DID, and the [DID document](/home/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 Issuer must have created a VC schema as described [here](../../schemas/create.md).
@@ -52,7 +52,7 @@ Before using the Issuing Credentials protocol, the following conditions must be
 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
+3. The Issuer must have a published PRISM DID, and the [DID document](/home/concepts/glossary#did-document) must have at
    least one `assertionMethod` key for issuing credentials and the curve must be `Ed25519` (
    see [Create DID](../../dids/create.md) and [Publish DID](../../dids/publish.md))
 4. The Issuer must have created a VC schema as described [here](../../schemas/create.md).
@@ -78,7 +78,7 @@ The protocol consists of the following main parts:
    endpoint.
 3. The Issuer then uses
    the [`/issue-credentials/records/{recordId}/issue-credential`](/agent-api/#tag/Issue-Credentials-Protocol/operation/issueCredential)
-   endpoint to issue the credential, which gets sent to the Holder via [DIDComm](/docs/concepts/glossary#didcomm). The
+   endpoint to issue the credential, which gets sent to the Holder via [DIDComm](/home/concepts/glossary#didcomm). The
    Holder receives the credential, and the protocol is complete.
 
 The claims provide specific information about the individual, such as their name or qualifications.
@@ -457,7 +457,7 @@ endpoint with a JSON payload that includes the following information:
 
 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
+   short-form PRISM [DID](/home/concepts/glossary#decentralized-identifier) string, such
    as `did:prism:subjectIdentifier`.
 
 ```shell
@@ -491,7 +491,7 @@ curl -X POST "http://localhost:8090/cloud-agent/issue-credentials/records/$holde
 
 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
+   short-form PRISM [DID](/home/concepts/glossary#decentralized-identifier) string, such
    as `did:prism:subjectIdentifier`.
 3. `keyId` Option parameter
     1. when keyId is not provided the SDJWT VC is not binded to Holder/Prover key

docs/docusaurus/credentials/didcomm/present-proof.md

@@ -3,9 +3,9 @@ import TabItem from '@theme/TabItem';
 
 # Present proof (DIDComm)
 
-The [Present Proof Protocol](/docs/concepts/glossary#present-proof-protocol) allows:
-- a [Verifier](/docs/concepts/glossary#verifier) to request a verifiable credential presentation from a Holder/Prover
-- a [Holder/Prover](/docs/concepts/glossary#holder) responds by presenting a cryptographic proof to the Verifier
+The [Present Proof Protocol](/home/concepts/glossary#present-proof-protocol) allows:
+- a [Verifier](/home/concepts/glossary#verifier) to request a verifiable credential presentation from a Holder/Prover
+- a [Holder/Prover](/home/concepts/glossary#holder) responds by presenting a cryptographic proof to the Verifier
 
 The protocol provides endpoints for a Verifier to request new proof presentations from Holder/Provers and for a Holder/Prover to respond to the presentation request using a specific verifiable credential they own.
 
@@ -14,15 +14,15 @@ The protocol provides endpoints for a Verifier to request new proof presentation
 The present proof protocol has two roles:
 
 1. Verifier: A subject requesting a proof presentation by sending a request presentation message, then verifying the presentation.
-2. Holder/Prover: A [subject](/docs/concepts/glossary#subject) that receives a [proof presentation](/docs/concepts/glossary#proof-presentation) request, prepares a proof, and sends it to the verifier by sending a proof presentation message.
+2. Holder/Prover: A [subject](/home/concepts/glossary#subject) that receives a [proof presentation](/home/concepts/glossary#proof-presentation) request, prepares a proof, and sends it to the verifier by sending a proof presentation message.
 
 ## Prerequisites
 
 Before using the Proof Presentation protocol, the following conditions must be present:
 
 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).
+3. The Holder/Prover should hold a [verifiable credential (VC)](/home/concepts/glossary#verifiable-credential) received from an [Issuer](/home/concepts/glossary#issuer) see [Issue](./issue.md).
 
 ## Overview
 

docs/docusaurus/credentials/oid4vci/issue.md

@@ -1,6 +1,6 @@
 # Issue credentials (OID4VCI)
 
-[OID4VCI](/docs/concepts/glossary#oid4vci) (OpenID for Verifiable Credential Issuance) is a protocol that extends OAuth2 to issue credentials.
+[OID4VCI](/home/concepts/glossary#oid4vci) (OpenID for Verifiable Credential Issuance) is a protocol that extends OAuth2 to issue credentials.
 It involves a Credential Issuer server and an Authorization server working together,
 using the authorization and token endpoints on the Authorization Server to grant holders access to credentials on the Credential Issuer server.
 These servers may or may not be the same, depending on the implementation.