The workflow involves 2 main actors (we don't check the IDP part) :
- The Authorization Client : A client that retrieves access tokens.
- The Authorization Server : A server that issues access tokens to requesting clients.
In order to check the compliance a complete ITI-71 transaction, I need to validate :
- The Get Authorization Code request (Http GET message).
- The Get Authorization Code response (with the code).
- The Get Access Token Request (Http POST message, code included).
- The Get Access Token response (with also a Token validation).
The steps of this workflow SHALL be tested either for a Basic Token or an Extended Token.
The main objective is to offer to SUT operators a way to verify the correctness of the HTTP requests and responses issued by their systems under test, against the ITI-71 requirements. In case of failure of the SUT to demonstrate that it complies with the specifications, the SUT operator shall understand what and where the errors are.
When the HTTP message contains a body (Steps 2 to 4), the SUT operator shall be able to assess as well the conformance of its content against specifications.
Short term benefit (< 1 year):
Canadian second Projectathon's participants will be able to test IUA ITI-71 messages before and during the event. It will also permit to increase consequently the validation time for monitors.
Middle and long term benefit (>= 1 year):
Since Canada Health Infoway choose to use the unmodified IHE specifications for IUA, this Validation Profile will be used in all the other IHE platforms.
This User Need is almost the same as SUT Operator verifies the conformance of the RAD-107 request and response messages.
A common validation service should be developped.
Complete and up to date IUA specifications : https://profiles.ihe.net/ITI/IUA/index.html