Model/Test Designer

User whose task is to maintain the interoperability specification model and related test cases.

A SUT Operator checks the compliance of the implementation of TLS1.3 in his SUT, in regards to WHO specifications

Submitted by sthiam on Fri, 12/16/2022 - 11:46
Priority
High - Major feature, it achieves a lot of work
Status
Draft
Customer
WHO
Business owner
Souleymane THIAM
Description

In most of the architecture, the security layer makes use of TLS as an encryption protocol. In the last years, TLS 1.2 was enforced to improve the security of systems. WHO is going one step further, and expects the systems that claim support to the DDCC profile to support TLS 1.3.

The Gazelle test suite offers tools to test the compliance of systems under test against TLS up to version 1.2. In the context of the WHO specifications, the SUT operators wants to verify the implementation of TLS 1.3 in his system, acting either as client or server. It includes verifying that the system under test supports a restricted set of cipher suites.

 

 

What is/are the targeted context(s)?
Conformity Assessment
Projectathon
Who is the targeted audience?
Model/Test Designer
SUT Operator
SUT Owner
Targetted goal(s)

Improve the safety and security of systems under test by testing their compliance with the upper version of TLS.

Offer testing tools to the SUT operators in the context of conformity assessment and projectathons conducted  by WHO, for testing the DDCC specifications.

Expected benefit

Bring the testing one step further by covering more security requirements.

Gazelle test suite will be able to claim support to TLS 1.3, this protocol is more and more mandatory in interoperability specifications.

Opportunities

Renovate and improve the TLS simulators currently available in Gazelle Security Suite to allow support of TLS 1.3.

Have a look to the projects that make use of Gazelle Security Suite to test the compliance of SUTs in regards to TLS, and decide which prior version shall be kept and which one can be deprecated.

Source files
Interoperability Assessment Framework for DDCC_V3.xlsx46.8 KB

SUT Operator shall be able to verify the conformance of the FHIR Resources produced in the context of the DDCC project

Submitted by sthiam on Fri, 12/16/2022 - 11:40
Priority
High - Major feature, it achieves a lot of work
Status
Draft
Customer
WHO
Business owner
Souleymane THIAM
Description

The DDCC specifications published by WHO relies on the FHIR standard, and on IHE FHIR-based Profiles such as 

  • SVCM: Sharing Valuesets, Codes, and Maps
  • mCSD: Mobile Care Services Discovery
  • PMIR: Patient Master Identity Registry
  • MHD: Mobile access to Health Documents
  • DDCC: Digital Documentation of COVID-19 Certificates

In this context, the SUT Operators want to verify the compliance of the FHIR resources produced by their SUTs.

The SUT Operator might choose to

  • extract the message from his logs and validate it using Gazelle validation services (GUI or API)
  • validate a message captured by Gazelle Proxy
What is/are the targeted context(s)?
Conformity Assessment
Projectathon
Who is the targeted audience?
Model/Test Designer
SUT Operator
SUT Owner
Targetted goal(s)

Assess the compliance of the systems claiming support to the DDCC profile during Conformity assessment and Projectathon.

Expected benefit

SUT Operator will be able to see if their implementation are conformed with DDCC specification.

Documentation

DDCC implementation guide: https://worldhealthorganization.github.io/ddcc/

SVCM implementation guide: https://profiles.ihe.net/ITI/SVCM/index.html

MHD implementation guide: https://profiles.ihe.net/ITI/MHD/index.html

mCSD implementation guide: https://profiles.ihe.net/ITI/mCSD/index.html

PMIR implementation guide: https://profiles.ihe.net/ITI/PMIR/index.html

Source files
Interoperability Assessment Framework for DDCC_V3_1.xlsx46.8 KB

SUT Operator checks the conformance of this system in regards to the FHIR SMART App Launch implementation guide

Submitted by sthiam on Fri, 12/16/2022 - 11:39
Priority
High - Major feature, it achieves a lot of work
Status
Draft
Customer
WHO
Business owner
Souleymane THIAM
Description

The DDCC specifications relies on FHIR Smart App Launch Implementation Guide for the user authorization feature. See http://hl7.org/fhir/smart-app-launch/index.html.

In this context, the SUT Operator shall have a mean to verify that his SUT is able to

  • Support OAuth v1.0 tokens when requesting resources from a REST server
  • Support OAuth v1.0 tokens when receiving requests from a REST client
  • Support OAuth v2.0 tokens when requesting resources from a REST server
  • Support OAuth v2.0 tokens when receiving requests from a REST client
  • Limit access to resources based on the authorization token it receives;
  • Get an authorization code by sending a request to an Authorization Server compliant with the SMART App Launch pattern
  • Get an access token sending a request with a JWT assertion to an Authorization Server based on SMART App Launch pattern
  • Get an access token sending a request with a client secret to an Authorization Server based on SMART App Launch pattern
  • Get an access token sending a request with a JWT assertion to an Authorization Server based on SMART Backend Services pattern
What is/are the targeted context(s)?
Conformity Assessment
Projectathon
Who is the targeted audience?
Model/Test Designer
SUT Operator
SUT Owner
Targetted goal(s)

Allow the SUT operator to verify the conformance of his SUT against the FHIR SMART App Launch specifications.

Expected benefit

SUT Operator will be able to see if their implementation conforms with DDCC specifications.

Documentation

FHIR SMART App Launch: http://hl7.org/fhir/smart-app-launch/index.html

Source files
Interoperability Assessment Framework for DDCC_V3_2.xlsx46.8 KB

SUT Operator verifies the conformance of the HTTP request against the DDCC specifications

Submitted by sthiam on Fri, 12/16/2022 - 11:28
Priority
High - Major feature, it achieves a lot of work
Status
Draft
Customer
WHO
Business owner
Souleymane THIAM
Description

The DDCC specifications published by WHO relies on the FHIR standard, and on IHE FHIR-based Profiles such as 

  • SVCM: Sharing Valuesets, Codes, and Maps
  • mCSD: Mobile Care Services Discovery
  • PMIR: Patient Master Identity Registry
  • MHD: Mobile access to Health Documents
  • DDCC: Digital Documentation of COVID-19 Certificates

In this context, the SUT Operators who develop the client side of those specifications want to verify the compliance of their system under test in regards to the specifications, in particular, whether the HTTP Header and Body of the HTTP requests are conform.

The SUT Operator might choose to

  • extract the message from his logs and validate it using Gazelle validation services (GUI or API)
  • validate a message captured by Gazelle Proxy
What is/are the targeted context(s)?
Conformity Assessment
Projectathon
Who is the targeted audience?
Model/Test Designer
SUT Operator
SUT Owner
Targetted goal(s)

Offer a validation tool for the HTTP requests produced by the SUT in the context of the DDCC specifications.

Expected benefit

SUT Operator will be able to see if their implementattion are conformed with DDCC specification

Opportunities

More and more HTTP-based profiles are being developed by our customers, thus, being able to validate the full HTTP payload, including the HTTP header is necessary to improve the coverage of the specifications by test tools.

Documentation

DDCC implementation guide: https://worldhealthorganization.github.io/ddcc/

SVCM implementation guide: https://profiles.ihe.net/ITI/SVCM/index.html

MHD implementation guide: https://profiles.ihe.net/ITI/MHD/index.html

mCSD implementation guide: https://profiles.ihe.net/ITI/mCSD/index.html

PMIR implementation guide: https://profiles.ihe.net/ITI/PMIR/index.html

As a test designer, I want to be able to verify the compliance of the body of the HTTP message

As a test designer, when I want to verify the compliance of the body of the HTTP message issued by the SUT. 

In particular, I shall be able to tell the HTTP validator that the body is either required, forbidden, or conditional.

When a body can be present, I should be able to tell the validator which content is expected.

As a test designer, I want to be able to import a validation profile into an instance of the HTTP validator

As a test designer, I need to import a validation profile within an instance of HTTP Validator to allow SUT operator to use it for validating content. In order to do that,

  • I need to be provided with the format, syntax, and rules of the document to be imported within HTTP Validator.
  • I need the HTTP Validator to provide an interface (V0.1: API, later: GUI) that allows me to add new validation profiles in the tool.

As a test designer, I want to list all the existing validation profiles registered in the instance of HTTP validator

As a test designer, I want to see the list of validation profiles that are referenced in the current instance of the tool. For each of them, I need to see the following details on a single page, to be able to select the validation profiles to update or to reference it in a test case.

  • Name
  • Version
  • Status (draft, active, deprecated)
  • Description
  • Date and time of the last changed
  • Name of the last modifier

As a test designer, I want to be able to edit a validation profile in the HTTP validator

As a test designer, I want to be able to modify the attributes of any HTTP validator, including

  • its name,
  • its version,
  • its context of use (transaction, projet),
  • its description,
  • its statut (draft/active/deprecated).

I shall be able to enter a summary of the changes I brought and why.

When I confirm the changes, the new values of the attributes shall be stored and the value of the last modifier and last changed date/time shall be updated accordingly.

As a test designer, I want to be able to create a new validation profile for checking the conformance of an HTTP message

As a test designer, I shall be able to define a set of rules to verify the conformance of an HTTP message (request or response) in regard to a given specification, this is named as a validation profile.

When I create such a new validation profile, I want to give it a name, a version, a context (transaction, projet), a description, and status (draft/active/deprecated).

When I save the newly created validation profile,

Subscribe to Model/Test Designer