...

The first version (1.0) of the Testbed will cover the following PEPPOL AS2 and AS4 profile use cases:

1. System under test (SP AP) is receiving
   1. Positive tests
      1. TB AP sends a valid document to service provider (SP) AP using a valid certificate (should pass) (of reasonable size)
         
         1. Document type ID/process ID/no SMP lookup (URL must be provided by test user in the Test Controller, forwarded to Backbone APs)
            1. Tast for the Testbed Controller: it must be possible to identify which Backbone AP sent out which file - correlate Backbone AP and sent out file;
         2. Verification; SP AP send file back to Testbed AP (see 2. a. i.) (maybe a problem because AP software changes are required!)
            
         3. Handle different Content-Transfer-Encodings (binary, base64, 7bit etc.) - for the payload (AS2 specific)
         4. Support SHA-1 and SHA-256 as MIC algorithms (AS2 specific)
         5. Try to verify if all the AS2 MDN HTTP headers are according to the specs (if proxying is possible) (AS2 specific)
      2. TB AP sends a valid large (50 MB+) document to SP AP (should pass)
         1. Verification; SP AP sends file back in 2.a.ii
         2. Same verification steps as described above should be applied
      3. The SP AP implementation (not the instance under test!) needs to be on the list of CEF eDelivery compliant implementations (https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+AS4+conformant+solutions) (AS4 specific)
   2. Negative tests
      1. TB AP sends an invalid document (valid SBDH without a payload) to SP AP (should fail with negative MDN)
      2. TB AP sends an invalid document (No SBDH, no payload at all) to SP AP (should fail with negative MDN)
      3. TB AP sends an invalid document (No SBDH, valid payload only) to SP AP (should fail with negative MDN)
      4. TB AP sends an invalid document (Invalid SBDH, XML syntax error) to SP AP (should fail with negative MDN)
      5. TB AP sends an invalid document (Invalid SBDH, missing mandatory field) to SP AP (should fail with negative MDN)
      6. TB AP sends an invalid document (SBDH endpoint ID differs from the Payload endpoint ID/or document type mismatch) to SP AP (out of scope for V1)
      7. TB AP sends a valid document to SP AP using an invalid certificate (expired PEPPOL AP certificate) (should fail)
      8. TB AP sends a valid document to SP AP using an invalid certificate (revoked PEPPOL AP certificate) (should fail) - may cause problems  in practise; Error level warning only?
         
      9. TB AP sends a valid document to SP AP using an invalid certificate (with a non-PEPPOL certificate) (should fail)
      10. TB AP sends a valid document to SP AP using an invalid certificate (with a PEPPOL SMP certificate) (should fail)
      11. TB AP sends a valid document to SP AP using an old TLS version (e.g. TLS 1.1) (should be rejected by SSL handshake)
2. System under test is sending
   1. Positive tests
      1. SP AP sends a valid document to TB AP using a valid certificate
         1. Sending more than one different document type might be an issue for testing with real-life-test systems (out of scope for V1)
         2. Handle different Content-Transfer-Encodings (binary, base64, 7bit etc.) - for the MDN (AS2 specific)
         3. Verify if that all the AS2 HTTP headers have correct values (according to the AS2 specs and the PEPPOL proprofile) (AS2 specific)
      2. SP AP sends a valid large (50 MB+) document using a valid certificate
         1. Consider reasonable read timeout values
   2. Negative tests
      1. SP AP is sending a document type that is not supported by the TB AP (e.g. OrderResponse) (should fail with negative MDN/Receipt) (for a later version of the Testbedout of scope for V1)
         1. Verification: verify that the negative MDN was received
      2. Out of scope version 1: list of negative self-tests, that cannot be verified by the Testbed

The first version (1.0) of the Testbed will  also cover the following use cases (utilising an AS4 implementation):

1. Testbed (TB) AP (XX AS4) sends a valid document to service provider (SP) AP using a valid certificate (should pass)
2. TB AP sends an empty document to SP AP (should fail)
3. TB AP sends a large (50 MB+) document to SP AP (should pass)
4. TB AP sends a valid document to SP AP using an invalid certificate (should fail)
5. Step 1 to 4are repeated for alternate AP implementations (TB will support this functionality out of the box but won't be enabled in version 1.0 since no other AP implementations will be integrated)
6. SP AP sends a valid document to TB AP using a valid certificate
7. SP AP is requested to send valid documents to TB AP (for available alternate AP implementations)
8. SP AP requested to send to TB AP that uses an expired certificate in SMP response (transaction should never be initiated)
9. SP AP requested to send to TB AP that uses a revoked certificate in SMP response (transaction should never be initiated)

In a long term scenario the centralized Testbed should be used for:

...

Requirements for the Testbed software

• What about GITB
• REST API needs to be defined

Next meeting: June 27th, 13:00 to 15:00 CEST

Attachments