Merge branch '24-update-git-ignore-file' into 'main'

Remove explicit key parameters

See merge request !64

.gitignore

@@ -74,3 +74,4 @@ build/tmp/
 reports/
 
 devRun.sh
+.gitlab-ci.yml

src/test/resources/features/tsa/policy/policy/{respository}/{group}/{name}/{version}/key/GET.feature

@@ -17,8 +17,8 @@ Feature: API - TSA - policy - {repository}/{group}/{name}/{version}/key GET
     And the field {crv} contains the value {P-256}
     And the field {kid} contains the value {key1}
     And the field {kty} contains the value {EC}
-    And the field {x} contains the value {AgBT2YKnE4JFm4zNng9fSQ4wEE4mdSdW-MrqQoSquyA}
-    And the field {y} contains the value {wewXbULR-jiHnpDIHMxLepfHdDVbEs6nFO2Yq5mXg5I}
+    And the field {x} is present and not empty
+    And the field {y} is present and not empty
 
   @negative
   Scenario: TSA - Export signing key information for policy with no export config information - Negative

src/test/resources/features/tsa/signer/v1/credential/proof/POST.feature

@@ -22,7 +22,7 @@ Feature: API - TSA - Signer credential proof - v1/credential/proof POST
       | alumni of   | for_proof_alumni     | Signer_CredentialProof_alumni_schema.json     |
       | without ID  | for_proof_without_ID | Signer_CredentialProof_without_ID_schema.json |
 
-  @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006
+  @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006 @IDM.TSA.E1.00019
   Scenario: TSA - create two consecutive proofs - Positive
     When I load the REST request {Credential.json} with profile {for_proof_with_02_proof}
     And I create credential proof via TSA Signer API
@@ -31,21 +31,21 @@ Feature: API - TSA - Signer credential proof - v1/credential/proof POST
     And the field {proof[1].verificationMethod} contains the value {did:web:vault.vereign.com:tsa:policy:policy:policies:example:returnDID:1.0:evaluation#key1}
     And the field {proof[2].verificationMethod} contains the value {did:web:vault.vereign.com:tsa:policy:policy:policies:example:returnDID:1.0:evaluation#key1}
 
-  @negative @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006
+  @negative @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006 @IDM.TSA.E1.00019
   Scenario: TSA - create two consecutive proofs with modified issuance date - Negative
     When I load the REST request {Credential.json} with profile {for_proof_with_modified_second_proof_date}
     And I create credential proof via TSA Signer API
     Then the status code should be {403}
     And the field {message} contains the value {invalid signature}
 
-  @negative @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006
+  @negative @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006 @IDM.TSA.E1.00019
   Scenario: TSA - create two consecutive proofs with modified credential subject ID - Negative
     When I load the REST request {Credential.json} with profile {for_proof_with_modified_second_proof_cred_subject}
     And I create credential proof via TSA Signer API
     Then the status code should be {403}
     And the field {message} contains the value {invalid signature}
 
-  @negative @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006
+  @negative @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006 @IDM.TSA.E1.00019
   Scenario: TSA - create two consecutive proofs with modified credential subject allow - Negative
     When I load the REST request {Credential.json} with profile {for_proof_with_modified_second_proof_cred_subject_allow}
     And I create credential proof via TSA Signer API