Skip to content
Snippets Groups Projects
Commit 51a1c01e authored by Rosen Georgiev's avatar Rosen Georgiev
Browse files

Merge branch '10-transfere-the-preliminary-scenarios-from-eclipse-repo' into 'main'

Resolve "Transfere the preliminary scenarios from Eclipse repo"

Closes #10

See merge request !46
parents 7b9d0df4 69392c83
No related branches found
No related tags found
1 merge request!46Resolve "Transfere the preliminary scenarios from Eclipse repo"
Pipeline #68059 passed
#2023 Vereign AG [https://www.vereign.com]
@rest @all @tsa @signer @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006 @wip
Feature: API - TSA - Signer create credential - v1/credential POST
As user
I want to be able to create credential from plain JSON
So the credential can be verified
Background:
Given we are testing the TSA Signer Api
Scenario: TSA - create credential from plain JSON - Positive
When I load the REST request {Credential.json} with profile {plain_JSON}
And I create credential from plain JSON via TSA Signer API
Then the status code should be {200}
And the response is valid according to the {Signer_plain_JSON_credential_schema.json} REST schema
And the field {proof.verificationMethod} has the value {did:web:vault.vereign.com:tsa:policy:policy:example:returnDID:1.0:evaluation#key1}
Scenario: TSA - create credential from plain JSON with two credential subjects - Positive
When I load the REST request {Credential.json} with profile {plain_JSON_with_two_subjects}
And I create credential from plain JSON via TSA Signer API
Then the status code should be {200}
And the response is valid according to the {Signer_plain_JSON_credential_schema.json} REST schema
And the field {proof.verificationMethod} has the value {did:web:vault.vereign.com:tsa:policy:policy:example:returnDID:1.0:evaluation#key1}
@negative
Scenario: TSA - create credential from blank JSON - Negative
When I load the REST request {Credential.json} with profile {blank_JSON}
And I create credential from plain JSON via TSA Signer API
Then the status code should be {400}
And the field {message} contains the value {"namespace" is missing from body}
And the field {message} contains the value {"key" is missing from body}
And the field {message} contains the value {"credential" is missing from body}
@negative
Scenario: TSA - create credential with missing body - Negative
When I load the REST request {Credential.json} with profile {missing_JSON}
And I create credential from plain JSON via TSA Signer API
Then the status code should be {400}
And the field {message} contains the value {"namespace" is missing from body}
And the field {message} contains the value {"key" is missing from body}
And the field {message} contains the value {"credential" is missing from body}
@negative
Scenario: TSA - create credential from JSON with missing closing bracket - Negative
When I load the REST request {Credential.json} with profile {closing_bracket_JSON}
And I create credential from plain JSON via TSA Signer API
Then the status code should be {400}
And the field {message} contains the value {"namespace" is missing from body}
And the field {message} contains the value {"key" is missing from body}
And the field {message} contains the value {"credential" is missing from body}
\ No newline at end of file
......@@ -22,6 +22,50 @@ 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 @wip
Scenario: TSA - create two consecutive proofs - Positive
When I load the REST request {Credential.json} with profile {for_proof}
And I create credential proof via TSA Signer API
Then the status code should be {200}
When I load the response from the previous call
And I create credential proof via TSA Signer API
Then the status code should be {200}
And the response is valid according to the {Signer_two_credentialProofs_schema.json} REST schema
And the field {proof.verificationMethod} has the value {did:web:gaiax.vereign.com:tsa:policy:policy:example:returnDID:1.0:evaluation#key1}
@negative @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006 @wip
Scenario: TSA - create two consecutive proofs with modified issuance date - Negative
When I load the REST request {Credential.json} with profile {for_proof}
And I create credential proof via TSA Signer API
Then the status code should be {200}
When I load the response from the previous call
And I change the issuance date
And I create credential proof via TSA Signer API
Then the status code should be {400}
And the field {message} contains the value {invalid signature}
@negative @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006 @wip
Scenario: TSA - create two consecutive proofs with modified credential subject ID - Negative
When I load the REST request {Credential.json} with profile {for_proof}
And I create credential proof via TSA Signer API
Then the status code should be {200}
When I load the response from the previous call
And I change the credential subject ID
And I create credential proof via TSA Signer API
Then the status code should be {400}
And the field {message} contains the value {invalid signature}
@negative @phase2 @IDM.TSA.E1.00005 @IDM.TSA.E1.00006 @wip
Scenario: TSA - create two consecutive proofs with modified credential subject allow - Negative
When I load the REST request {Credential.json} with profile {for_proof}
And I create credential proof via TSA Signer API
Then the status code should be {200}
When I load the response from the previous call
And I change the credential subject allow
And I create credential proof via TSA Signer API
Then the status code should be {400}
And the field {message} contains the value {invalid signature}
@negative
Scenario: TSA - create credential proof with empty body - Negative
When I set the following request body {{}}
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment