Skip to content
Snippets Groups Projects
Unverified Commit d7c47bd5 authored by Georgi Michev's avatar Georgi Michev
Browse files

Refactor signer tests


Improve visibility and readability of the signer scenarios.

Also add some missed tests.

Signed-off-by: default avatargeorgi.michev <georgi.michev@vereign.com>
parent 56d1316f
No related branches found
No related tags found
1 merge request!32Refactor signer tests
Pipeline #53188 passed with stage
in 4 minutes and 29 seconds
...@@ -75,6 +75,26 @@ ...@@ -75,6 +75,26 @@
} }
} }
}, },
"for_proof_incorrect_ID_symbols":{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1",
"https://www.schema.org"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "did:web:gaiax.vereign.com:tsa:policy:policy:example:returnDID:1.0:evaluation",
"issuanceDate": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": ":",
"allow": true,
"num": 123,
"array": {
"txt1": "1",
"txt2": "2"
}
}
},
"incorrect_id":{ "incorrect_id":{
"@context": [ "@context": [
"https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/v1",
......
...@@ -25,26 +25,18 @@ Feature: API - TSA - Signer credential proof - v1/credential/proof POST ...@@ -25,26 +25,18 @@ Feature: API - TSA - Signer credential proof - v1/credential/proof POST
Background: Background:
Given we are testing the TSA Signer Api Given we are testing the TSA Signer Api
Scenario: TSA - create credential proof - Positive Scenario Outline: TSA - create credential proof <labelSuffix> - Positive
When I load the REST request {Credential.json} with profile {for_proof} When I load the REST request {Credential.json} with profile {<profileOption>}
And I create credential proof via TSA Signer API And I create credential proof via TSA Signer API
Then the status code should be {200} Then the status code should be {200}
And the response is valid according to the {Signer_CredentialProof_schema.json} REST schema And the response is valid according to the {<schema>} REST schema
And the field {proof.verificationMethod} has the value {did:web:gaiax.vereign.com:tsa:policy:policy:example:returnDID:1.0:evaluation#key1} And the field {proof.verificationMethod} has the value {did:web:gaiax.vereign.com:tsa:policy:policy:example:returnDID:1.0:evaluation#key1}
Scenario: TSA - create credential proof alumni of - Positive Examples:
When I load the REST request {Credential.json} with profile {for_proof_alumni} | labelSuffix | profileOption | schema |
And I create credential proof via TSA Signer API | | for_proof | Signer_CredentialProof_schema.json |
Then the status code should be {200} | alumni of | for_proof_alumni | Signer_CredentialProof_alumni_schema.json |
And the response is valid according to the {Signer_CredentialProof_alumni_schema.json} REST schema | without ID | for_proof_without_ID | Signer_CredentialProof_without_ID_schema.json |
And the field {proof.verificationMethod} has the value {did:web:gaiax.vereign.com:tsa:policy:policy:example:returnDID:1.0:evaluation#key1}
Scenario: TSA - create credential proof without ID - Positive
When I load the REST request {Credential.json} with profile {for_proof_without_ID}
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_CredentialProof_without_ID_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 @negative
Scenario: TSA - create credential proof with empty body - Negative Scenario: TSA - create credential proof with empty body - Negative
...@@ -54,8 +46,13 @@ Feature: API - TSA - Signer credential proof - v1/credential/proof POST ...@@ -54,8 +46,13 @@ Feature: API - TSA - Signer credential proof - v1/credential/proof POST
And the field {message} contains the value {credential type of unknown structure} And the field {message} contains the value {credential type of unknown structure}
@negative @negative
Scenario: TSA - create credential proof with incorrect ID (space)- Negative Scenario Outline: TSA - create credential proof with incorrect ID (<labelSuffix>)- Negative
When I load the REST request {Credential.json} with profile {for_proof_incorrect_ID_space} When I load the REST request {Credential.json} with profile {<profileOption>}
And I create credential proof via TSA Signer API And I create credential proof via TSA Signer API
Then the status code should be {400} Then the status code should be {400}
And the field {message} has the value {invalid format of subject id} And the field {message} has the value {invalid format of subject id}
Examples:
| labelSuffix | profileOption |
| space | for_proof_incorrect_ID_space |
| symbols | for_proof_incorrect_ID_symbols |
\ No newline at end of file
...@@ -37,36 +37,16 @@ Feature: API - TSA - Signer credential verify - v1/credential/verify POST ...@@ -37,36 +37,16 @@ Feature: API - TSA - Signer credential verify - v1/credential/verify POST
And the field {valid} has the value {true} And the field {valid} has the value {true}
@negative @negative
Scenario: TSA - verify credential proof with missing proof - Negative Scenario Outline: TSA - verify credential proof with <labelSuffix> - Negative
When I load the REST request {Credential.json} with profile {missing_proof} When I load the REST request {Credential.json} with profile {<profileOption>}
And I verify credential proof via TSA Signer API And I verify credential proof via TSA Signer API
Then the status code should be {400} Then the status code should be {400}
And the field {message} contains the value {verifiable credential must have proof section} And the field {message} contains the value {<messageText>}
@negative Examples:
Scenario: TSA - verify credential proof with missing proof - Negative | labelSuffix | profileOption | messageText |
When I load the REST request {Credential.json} with profile {modified_ID} | missing proof | missing_proof | verifiable credential must have proof section |
And I verify credential proof via TSA Signer API | modified ID | modified_ID | invalid signature |
Then the status code should be {400} | modified issuanceDate field | modified_issuanceDate | invalid signature |
And the field {message} contains the value {invalid signature} | modified allow field | modified_credentialSubject_allow | invalid signature |
| modified array field | modified_credentialSubject_array | invalid signature |
@negative \ No newline at end of file
Scenario: TSA - verify credential proof with modified issuanceDate field - Negative
When I load the REST request {Credential.json} with profile {modified_issuanceDate}
And I verify 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 - verify credential proof with modified issuanceDate field - Negative
When I load the REST request {Credential.json} with profile {modified_credentialSubject_allow}
And I verify 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 - verify credential proof with modified issuanceDate field - Negative
When I load the REST request {Credential.json} with profile {modified_credentialSubject_array}
And I verify credential proof via TSA Signer API
Then the status code should be {400}
And the field {message} contains the value {invalid signature}
...@@ -25,25 +25,18 @@ Feature: API - TSA - Signer presentation proof - v1/presentation/proof POST ...@@ -25,25 +25,18 @@ Feature: API - TSA - Signer presentation proof - v1/presentation/proof POST
Background: Background:
Given we are testing the TSA Signer Api Given we are testing the TSA Signer Api
Scenario: TSA - create presentation proof - Positive Scenario Outline: TSA - create presentation proof <labelSuffix> - Positive
When I load the REST request {Presentation.json} with profile {for_proof} When I load the REST request {Presentation.json} with profile {<profileOption>}
And I create presentation proof via TSA Signer API And I create presentation proof via TSA Signer API
Then the status code should be {200} Then the status code should be {200}
And the response is valid according to the {Signer_PresentationProof_schema.json} REST schema And the response is valid according to the {<schema>} REST schema
And the field {proof.verificationMethod} has the value {did:web:gaiax.vereign.com:tsa:policy:policy:example:returnDID:1.0:evaluation#key1} And the field {proof.verificationMethod} has the value {did:web:gaiax.vereign.com:tsa:policy:policy:example:returnDID:1.0:evaluation#key1}
Scenario: TSA - create presentation proof alumni of - Positive Examples:
When I load the REST request {Presentation.json} with profile {for_proof_alumni} | labelSuffix | profileOption | schema |
And I create presentation proof via TSA Signer API | | for_proof | Signer_PresentationProof_schema.json |
Then the status code should be {200} | alumni of | for_proof_alumni | Signer_PresentationProof_schema_alumni.json |
And the response is valid according to the {Signer_PresentationProof_schema_alumni.json} REST schema | without ID | for_proof_without_ID | Signer_PresentationProof_schema.json |
Scenario: TSA - create presentation proof without ID - Positive
When I load the REST request {Presentation.json} with profile {for_proof_without_ID}
And I create presentation proof via TSA Signer API
Then the status code should be {200}
And the response is valid according to the {Signer_PresentationProof_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 @negative
Scenario: TSA - validate presentation proof with empty body - Negative Scenario: TSA - validate presentation proof with empty body - Negative
...@@ -53,15 +46,13 @@ Feature: API - TSA - Signer presentation proof - v1/presentation/proof POST ...@@ -53,15 +46,13 @@ Feature: API - TSA - Signer presentation proof - v1/presentation/proof POST
And the field {message} contains the value {verifiable presentation is not valid} And the field {message} contains the value {verifiable presentation is not valid}
@negative @negative
Scenario: TSA - create presentation proof with incorrect ID (space) - Negative Scenario Outline: TSA - create presentation proof with incorrect ID (<labelSuffix>) - Negative
When I load the REST request {Presentation.json} with profile {for_proof_incorrect_ID_space} When I load the REST request {Presentation.json} with profile {<profileOption>}
And I create presentation proof via TSA Signer API And I create presentation proof via TSA Signer API
Then the status code should be {400} Then the status code should be {400}
And the field {message} has the value {invalid format of subject id} And the field {message} has the value {invalid format of subject id}
@negative Examples:
Scenario: TSA - create presentation proof with incorrect ID (symbols) - Negative | labelSuffix | profileOption |
When I load the REST request {Presentation.json} with profile {for_proof_incorrect_ID_symbols} | space | for_proof_incorrect_ID_space |
And I create presentation proof via TSA Signer API | symbols | for_proof_incorrect_ID_symbols |
Then the status code should be {400} \ No newline at end of file
And the field {message} has the value {invalid format of subject id}
...@@ -37,50 +37,18 @@ Feature: API - TSA - Signer presentation verify - v1/presentation/verify POST ...@@ -37,50 +37,18 @@ Feature: API - TSA - Signer presentation verify - v1/presentation/verify POST
And the field {valid} has the value {true} And the field {valid} has the value {true}
@negative @negative
Scenario: TSA - verify presentation proof with missing proof - Negative Scenario Outline: TSA - verify presentation proof with <labelSuffix> - Negative
When I load the REST request {Presentation.json} with profile {missing_proof} When I load the REST request {Presentation.json} with profile {<profileOption>}
And I verify presentation proof via TSA Signer API And I verify presentation proof via TSA Signer API
And the status code should be {400} And the status code should be {400}
And the field {message} has the value {verifiable presentation must have proof section} And the field {message} contains the value {<messageText>}
@negative Examples:
Scenario: TSA - verify presentation proof with modified ID field - Negative | labelSuffix | profileOption | messageText |
When I load the REST request {Presentation.json} with profile {modified_ID} | missing proof | missing_proof | verifiable presentation must have proof section |
And I verify presentation proof via TSA Signer API | modified ID | modified_ID | invalid signature |
And the status code should be {400} | modified issuanceDate field | modified_issuanceDate | invalid signature |
And the field {message} contains the value {invalid signature} | modified first allow field | modified_credentialSubject_1_allow | invalid signature |
| modified second allow field | modified_credentialSubject_2_allow | invalid signature |
@negative | modified first credentialSubject.ID field | modified_credentialSubject_1_ID | invalid signature |
Scenario: TSA - verify presentation proof with modified issuanceDate field - Negative | modified second credentialSubject.ID field | modified_credentialSubject_2_ID | invalid signature |
When I load the REST request {Presentation.json} with profile {modified_issuanceDate} \ No newline at end of file
And I verify presentation proof via TSA Signer API
And the status code should be {400}
And the field {message} contains the value {invalid signature}
@negative
Scenario: TSA - verify presentation proof with modified first credentialSubject.allow field - Negative
When I load the REST request {Presentation.json} with profile {modified_credentialSubject_1_allow}
And I verify presentation proof via TSA Signer API
And the status code should be {400}
And the field {message} contains the value {invalid signature}
@negative
Scenario: TSA - verify presentation proof with modified second credentialSubject.allow field - Negative
When I load the REST request {Presentation.json} with profile {modified_credentialSubject_2_allow}
And I verify presentation proof via TSA Signer API
And the status code should be {400}
And the field {message} contains the value {invalid signature}
@negative
Scenario: TSA - verify presentation proof with modified first credentialSubject.ID field - Negative
When I load the REST request {Presentation.json} with profile {modified_credentialSubject_1_ID}
And I verify presentation proof via TSA Signer API
And the status code should be {400}
And the field {message} contains the value {invalid signature}
@negative
Scenario: TSA - verify presentation proof with modified second credentialSubject.ID field - Negative
When I load the REST request {Presentation.json} with profile {modified_credentialSubject_2_ID}
And I verify presentation proof via TSA Signer API
And the status code should be {400}
And the field {message} contains the value {invalid signature}
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment