| CH-IUA | CH-IUA-001 | to be reviewed | Testable |
0
|
0
| | The Token Introspection option of the IUA profile SHALL not be used. | 8 | Section 2.3.1.4 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-002 | to be reviewed | Testable |
0
|
0
| | The IUA Authorization Server SHALL enforce authentication of the user by redirecting the mHealth App to the User Authentication Provider (Identity Provider) as described in Section 3.2.8. | 8 | Section 2.3.1.7 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-003 | to be reviewed | Testable |
0
|
0
| | [ITI-103] At launch time the app may connect to the Authorization Server to retrieve the configuration data. | 12 | Section 3.1.1 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-004 | to be reviewed | Testable |
0
|
0
| | [ITI-103] The Authorization Server responds with the configuration data and the Authorization Server endpoint the app shall direct the User Agent to. | 12 | Section 3.1.1 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-005 | to be reviewed | Testable |
0
|
0
| | [ITI-103] The Authorization Client or Resource Server performs a HTTP GET request to the Authorization Server Well-Known URI. | 12 | Section 3.1.6.1.1 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-006 | to be reviewed | Testable |
0
|
0
| | [ITI-103] The request SHALL neither use parameter nor body data. | 12 | Section 3.1.6.1.1 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-007 | to be reviewed | Testable |
0
|
0
| | [ITI-103] The Authorization Server SHALL response with a HTTP response conveying a JSON formatted object as HTTP body element. | 12 | Section 3.1.6.1.2 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-008 | to be reviewed | Testable |
0
|
0
| | [ITI-103] The JSON object SHALL convey "authorization_endpoint", "token_endpoint", "grant_types_supported", "capabilities", "issuer" and "jwks_uri". | 13 | Table 3 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-009 | to be reviewed | Testable |
0
|
0
| | [ITI-103] The JSON object CAN convey "oken_endpoint_auth_methods", "registration_endpoint", "scopes_supported", "response_types_supported", "management_endpoint", "revocation_endpoint" and "access_token_format". | 13 | Table 3 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-010 | to be reviewed | Testable |
0
|
0
| | [ITI-103] The Authorization Client or Resource Server MAY read the URL of the IUA Authorization Server and redirect the User Agent to the Authorization Server. | 13 | Section 3.1.7 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-011 | to be reviewed | Testable |
0
|
0
| | [ITI-71] A mHealth App in the SMART Standalone Launch sequence SHALL perform the transaction first to get basic access to the Swiss EPR. | 14 | Section 3.2.1 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-012 | to be reviewed | Testable |
0
|
0
| | [ITI-71] The IUA Authorization Server SHALL present a User Interface for the user to authenticate and provide user consent, or by validating against data stored at app registration time. | 14 | Section 3.2.1 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-013 | to be reviewed | Testable |
0
|
0
| | [ITI-71] Once the mHealth App is authorized, it may launch other embedded mHealth Apps (or views) using the SMART EHR Launch Sequence. | 15 | Section 3.2.2 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-014 | to be reviewed | Testable |
0
|
0
| | [ITI-71] If the mHealth App uses SMART EHR Launch Sequence, the embedded app inherits the basic access authorization from the launching app and may retrieve extended access token for EPR endpoints protected by the EPR role and attribute based authorization | 16 | Section 3.2.3 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-015 | to be reviewed | Testable |
0
|
0
| | [ITI-71] HTTP conversation parameters SHALL be in accordance with Table 4 "Description of the HTTP conversation of the transaction". | 16 | Table 4 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-016 | to be reviewed | Testable |
0
|
0
| | [ITI-71] HTTP request parameters SHALL be in accordance with Table 5 "Overview of the requests scope parameter". | 17 | Table 5 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-017 | to be reviewed | Testable |
0
|
0
| | [ITI-71] The scope parameter of the request MAY claim launch, "purpose_of_use=token", "subject_role=token", "person_id=value" attributes | 17 | Section 3.2.6.1 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-018 | to be reviewed | Testable |
0
|
0
| | [ITI-71] If launch attribute is present,the scope SHALL be used by all apps (or views) launched from a mHealth App which was authorized before. | 17 | Section 3.2.6.1 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-019 | to be reviewed | Testable |
0
|
0
| | [ITI-71] If "purpose_of_use=token" attribute is present, the token SHALL convey the coded value of the current transactions purpose of use. | 17 | Section 3.2.6.1 | 6/27/22 3:54:39 PM by vhofman |
|
| CH-IUA | CH-IUA-020 | to be reviewed | Testable |
0
|
0
| | [ITI-71] If "purpose_of_use=token" attribute is present, allowed values are NORM (normal access) and EMER (emergency access) from code system 2.16.756.5.30.1.127.3.10.5 of the CH:EPR value set. e.g. purpose_of_use=urn:oid:2.16.756.5.30.1.127.3.10.5|NORM | 17 | Section 3.2.6.1 | 6/27/22 3:54:39 PM by vhofman |
|