Merge branch 'main' into ATL-7264-Present-Error-Handling

docs/docusaurus/credentials/issue.md

@@ -1,7 +1,7 @@
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-# Issue Credentials
+# Issue credentials
 
 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.
 
@@ -34,6 +34,15 @@ Before using the Issuing Credentials protocol, the following conditions must be
 2. A connection must be established between the Issuer and Holder Cloud Agents (see [Connections](../connections/connection.md))
 3. The Issuer must have created an AnonCreds Credential Definition as described [here](../credentialdefinition/create.md).
 
+</TabItem>
+<TabItem value="sdjwt" label="SDJWT">
+
+- 📌 **Note:** Currently we only support `Ed25519` curve
+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 and the curve must be `Ed25519` (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 and the curve must be `Ed25519`.
+
 </TabItem>
 </Tabs>
 
@@ -155,6 +164,53 @@ curl -X 'POST' \
         }'
 ```
 
+</TabItem>
+
+<TabItem value="sdjwt" label="SDJWT">
+
+1. `claims`: The data stored in a verifiable credential. Claims get expressed in a key-value format. The claims contain the data that the issuer attests to, such as name, address, date of birth, and so on.
+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 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 - `SDJWT` in this case.
+
+
+:::note
+The `issuingDID` and `connectionId` properties come from completing the pre-requisite steps listed above
+:::
+
+- 📌 **Note:** Claims can also include the `exp` Expiration Time attribute, which is part of JWT claims. `exp` attribute is disclosable if specified and can have a value in epoch time (in seconds), indicating when the SDJWT credential expires for more details
+<https://datatracker.ietf.org/doc/html/rfc7519#page-9>
+
+Once the request initiates, a new credential record for the issuer gets created with a unique ID. The state of this record is now `OfferPending`.
+
+```shell
+# Issuer POST request to create a new credential offer
+curl -X 'POST' \
+  'http://localhost:8080/cloud-agent/issue-credentials/credential-offers' \
+    -H 'accept: application/json' \
+    -H 'Content-Type: application/json' \
+    -H "apikey: $API_KEY" \
+    -d '{
+          "claims": {
+            "emailAddress": "[email protected]",
+            "givenName": "Alice",
+            "familyName": "Wonderland",
+            "dateOfIssuance": "2020-11-13T20:20:39+00:00",
+            "drivingLicenseID": "12345",
+            "drivingClass": 3,
+            "exp" : 1883000000
+          },
+          "credentialFormat": "SDJWT",
+          "issuingDID": "did:prism:9f847f8bbb66c112f71d08ab39930d468ccbfe1e0e1d002be53d46c431212c26",
+          "connectionId": "9d075518-f97e-4f11-9d10-d7348a7a0fda",
+          "schemaId": "http://localhost:8080/cloud-agent/schema-registry/schemas/3f86a73f-5b78-39c7-af77-0c16123fa9c2"
+        }'
+```
+
 </TabItem>
 </Tabs>
 
@@ -257,6 +313,92 @@ curl -X POST "http://localhost:8090/cloud-agent/issue-credentials/records/$holde
 ```
 
 </TabItem>
+
+<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`.
+3. `keyId` Option parameter
+   1. when keyId is not provided the SDJWT VC is not binded to Holder/Prover key
+   ```shell
+   # Holder POST request to accept the credential offer
+   curl -X POST "http://localhost:8090/cloud-agent/issue-credentials/records/$holder_record_id/accept-offer" \
+       -H 'accept: application/json' \
+       -H 'Content-Type: application/json' \
+       -H "apikey: $API_KEY" \
+       -d '{
+             "subjectId": "did:prism:subjectIdentifier"
+        }'
+   ```
+   A SD-JWT Verifiable Credential (VC) without a `cnf` key could possibly look like below
+
+   ```json
+    {
+     "_sd": [
+       "CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI",
+       "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE",
+       "PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI",
+       "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo",
+       "XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM",
+       "XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE",
+       "gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM",
+       "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4"
+     ],
+     "iss": "https://issuer.example.com",
+     "iat": 1683000000,
+     "exp": 1883000000,
+     "sub": "user_42",
+     "_sd_alg": "sha-256"
+   }
+   ```
+   2. `keyId`: This is optional field but must be specified to choose which key bounds to the verifiable credential.
+   For more information on key-binding, <https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt>.
+   Currently, we only support the EdDSA algorithm and curve Ed25519.
+   The specified keyId should be of type Ed25519.
+   The purpose of the keyId should be authentication.
+
+   ```shell
+   # Holder POST request to accept the credential offer with keyId
+   curl -X POST "http://localhost:8090/cloud-agent/issue-credentials/records/$holder_record_id/accept-offer" \
+       -H 'accept: application/json' \
+       -H 'Content-Type: application/json' \
+       -H "apikey: $API_KEY" \
+       -d '{
+             "subjectId": "did:prism:subjectIdentifier",
+             "keyId": "key-1"    
+        }'
+   ```
+   A SD-JWT Verifiable Credential (VC) that includes a `cnf` key could possibly look like below
+   ```json
+    {
+     "_sd": [
+       "CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI",
+       "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE",
+       "PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI",
+       "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo",
+       "XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM",
+       "XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE",
+       "gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM",
+       "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4"
+     ],
+     "iss": "https://issuer.example.com",
+     "iat": 1683000000,
+     "exp": 1883000000,
+     "sub": "user_42",
+     "_sd_alg": "sha-256",
+     "cnf": {
+       "jwk": {
+         "kty": "EC",
+         "crv": "P-256",
+         "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
+         "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
+       }
+     }
+   }
+   ```
+
+</TabItem>
+
 </Tabs>
 
 This request will change the state of the record to `RequestPending`.

docs/docusaurus/credentials/present-proof.md

@@ -125,6 +125,55 @@ curl -X 'POST' 'http://localhost:8070/cloud-agent/present-proof/presentations' \
         "credentialFormat": "AnonCreds" 
       }'
 ```
+</TabItem>
+<TabItem value="sdjwt" label="SDJWT">
+
+a. `SD-JWT` The absence of the `cnf` key claim in the SD-JWT Verifiable Credential (VC) means that the Holder/Prover is unable to create a presentation and sign the `challenge` and `domain` supplied by the verifier
+
+```bash
+curl -X 'POST' 'http://localhost:8070/cloud-agent/present-proof/presentations' \
+  -H 'accept: application/json' \
+  -H 'Content-Type: application/json' \
+ -H "apikey: $API_KEY" \
+  -d '{
+        "connectionId": "872ddfa9-4115-46c2-8a1b-22c24c7431d7",
+        "proofs":[],
+        "credentialFormat": "SDJWT",
+         "claims": {
+            "emailAddress": {},
+            "givenName": {},
+    `       "region": {},
+            "country": {}`
+         }
+      }'
+```
+
+b. `SD-JWT` The presence of the `cnf` key as a disclosable claim in the SD-JWT Verifiable Credential (VC) allows the Holder/Prover to create a presentation and sign the `challenge` and `domain` given by the verifier.
+```bash
+curl -X 'POST' 'http://localhost:8070/cloud-agent/present-proof/presentations' \
+  -H 'accept: application/json' \
+  -H 'Content-Type: application/json' \
+ -H "apikey: $API_KEY" \
+  -d '{
+        "connectionId": "872ddfa9-4115-46c2-8a1b-22c24c7431d7",
+        "proofs":[],
+        "options": {
+          "challenge": "11c91493-01b3-4c4d-ac36-b336bab5bddf",
+          "domain": "https://prism-verifier.com"
+        },
+        "credentialFormat": "SDJWT",
+         "claims": {
+            "emailAddress": {},
+            "givenName": {},
+            "region": {},
+            "country": {}
+         }
+      }'
+```
+SDJWT Specific attributes
+1. `credentialFormat`: SDJWT.
+2. `claims`: The claims to be disclosed  by Holder/Prover.
+
 </TabItem>
 </Tabs>
 
@@ -219,6 +268,38 @@ curl -X 'PATCH' 'http://localhost:8090/cloud-agent/present-proof/presentations/{
       }'
 ```
 </TabItem>
+
+<TabItem value="sdjwt" label="SDJWT">
+
+```bash
+curl -X 'PATCH' 'http://localhost:8090/cloud-agent/present-proof/presentations/{PRESENTATION_ID}' \
+  -H 'Content-Type: application/json' \
+  -H "apikey: $API_KEY" \
+  -d '{
+        "action": "request-accept",
+        "proofId": ["{CRED_RECORD_ID}"]
+        "claims": {
+          "emailAddress": {},
+          "givenName": {},
+          "address": {
+            "region": {},
+            "country": {}
+          }
+        },
+        "credentialFormat": "SDJWT"
+      }'
+```
+
+The Holder/Prover will have to provide the following information:
+1. `presentationId`: The unique identifier of the presentation record to accept.
+2. `proofId`: The unique identifier of the verifiable credential record to use as proof.
+3. `credentialFormat`: SDJWT.
+4. `claims`: The Verifier requests specific claims to disclose. The path of these claims must match exactly with those in the SD-JWT Verifiable Credential (VC).
+- 📌 **Note:**  When a SD-JWT Verifiable Credential (VC) has nested claims such as region and country within an address object, as shown in the example above, it falls under the Holder's responsibility to supply the correct nested JSON structure for the claims attribute(s) that is being disclosed.
+- 📌 **Note:** The holder or prover of the claims is only required to disclose the attribute names and the correct JSON path. The actual values are not necessary. A special JSON placeholder `{}`, can be used instead.
+
+</TabItem>
+
 </Tabs>
 
 The Holder/Prover will have to provide the following information:

docs/docusaurus/credentials/revocation.md

@@ -1,4 +1,8 @@
-# JWT credential revocation
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Credential revocation
+
 
 Identus implements the revocation mechanism of JWT credentials according to [Verifiable Credentials Status List v2021](https://www.w3.org/TR/2023/WD-vc-status-list-20230427/). This open standard enables Identus to verify the revocation status of any credential that implements the revocation mechanism using the same specification.
 
@@ -15,10 +19,12 @@ Every credential will contain the property `credentialStatus`, which will look l
     "statusListCredential": "http://localhost:8080/cloud-agent/cloud-agent/credential-status/27526236-3836-4061-9867-f69314e258b4"
   },
 ```
-
 * `type` will always be `StatusList2021Entry`
 * `statusListCredential` is a publicly accessible URL that resolves a status list credential that looks like this:
 
+<Tabs groupId="vc-formats">
+<TabItem value="jwt" label="JWT">
+
 ```json
 {
   "proof" : {...},
@@ -41,6 +47,12 @@ Every credential will contain the property `credentialStatus`, which will look l
 }
 
 ```
+
+</TabItem>
+
+</Tabs>
+
+
 * `statusListIndex` is an index in a bit string at which the credential's revocation status can be verified.
 
 The status list credential contains  `encodedList`, a base64-encoded bit string that contains the credential's revocation status.
@@ -58,6 +70,9 @@ To verify the revocation status of the credential, one must follow these steps:
 
 Status list credential integrity can be verified using the embedded proof.
 
+<Tabs groupId="vc-formats">
+<TabItem value="jwt" label="JWT">
+
 We currently support 2 types of proofs:
 * `DataIntegrityProof` via crypto suite `eddsa-jcs-2022`. The exact steps on how to create a verify this proof are in the [Data Integrity EdDSA Cryptosuites v1.0](https://www.w3.org/TR/vc-di-eddsa/#eddsa-jcs-2022)
   * Used for Ed25519 EC curves, meaning if the proof was created using Ed25519 private key
@@ -127,6 +142,13 @@ We currently support 2 types of proofs:
 
 ```
 
+</TabItem>
+
+</Tabs>
+
+
+
+
 ## Revocation
 
 Only issuers of a credential can revoke a credential.

tests/integration-tests/src/test/kotlin/IntegrationTestsRunner.kt

@@ -6,6 +6,7 @@ import org.junit.runner.RunWith
     features = ["src/test/resources/features"],
     snippets = CucumberOptions.SnippetType.CAMELCASE,
     plugin = ["pretty"],
+    tags = "not @flaky",
 )
 @RunWith(CucumberWithSerenity::class)
 class IntegrationTestsRunner

tests/integration-tests/src/test/resources/features/proofs/present_proof.feature

@@ -1,26 +1,28 @@
 @proof @jwt
 Feature: Present Proof Protocol
 
-Scenario: Holder presents credential proof to verifier
-  Given Verifier and Holder have an existing connection
-  And Holder has an issued credential from Issuer
-  When Verifier sends a request for proof presentation to Holder
-  And Holder receives the request
-  And Holder makes the presentation of the proof to Verifier
-  Then Verifier has the proof verified
+  @flaky
+  Scenario: Holder presents credential proof to verifier
+    Given Verifier and Holder have an existing connection
+    And Holder has an issued credential from Issuer
+    When Verifier sends a request for proof presentation to Holder
+    And Holder receives the request
+    And Holder makes the presentation of the proof to Verifier
+    Then Verifier has the proof verified
 
-Scenario: Verifier rejects holder proof
-  Given Verifier and Holder have an existing connection
-  And Holder has an issued credential from Issuer
-  When Verifier sends a request for proof presentation to Holder
-  And Holder receives the request
-  And Holder rejects the proof
-  Then Holder sees the proof is rejected
+  Scenario: Verifier rejects holder proof
+    Given Verifier and Holder have an existing connection
+    And Holder has an issued credential from Issuer
+    When Verifier sends a request for proof presentation to Holder
+    And Holder receives the request
+    And Holder rejects the proof
+    Then Holder sees the proof is rejected
 
-Scenario: Holder presents proof to verifier which is the issuer itself
-  Given Issuer and Holder have an existing connection
-  And Holder has an issued credential from Issuer
-  When Issuer sends a request for proof presentation to Holder
-  And Holder receives the request
-  And Holder makes the presentation of the proof to Issuer
-  Then Issuer has the proof verified
+  @flaky
+  Scenario: Holder presents proof to verifier which is the issuer itself
+    Given Issuer and Holder have an existing connection
+    And Holder has an issued credential from Issuer
+    When Issuer sends a request for proof presentation to Holder
+    And Holder receives the request
+    And Holder makes the presentation of the proof to Issuer
+    Then Issuer has the proof verified