This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Security Use Cases"
Jump to navigation
Jump to search
Line 11: | Line 11: | ||
will have to be authenticated when they attempt to use the application, the | will have to be authenticated when they attempt to use the application, the | ||
applications must authenticate themselves before accessing EHR information managed by other applications or remote EHR-S’. In order for authentication to be established a Chain of Trust agreement is assumed to be in place. Examples of entity authentication include: | applications must authenticate themselves before accessing EHR information managed by other applications or remote EHR-S’. In order for authentication to be established a Chain of Trust agreement is assumed to be in place. Examples of entity authentication include: | ||
+ | |||
** username/ password | ** username/ password | ||
+ | |||
** digital certificate | ** digital certificate | ||
+ | |||
** secure token | ** secure token | ||
+ | |||
** biometrics." | ** biometrics." |
Revision as of 16:45, 21 April 2009
Security Cases
Introduction
The following page is intended to allow all Security WG stakeholders to record their security use cases.
Please follow the format provided here to enter your requirements as use cases.
Authenticate users and systems
This use case is based on the IN.1.1 Entity Authentication function in EHR Functional Model - Infrastructure.
- " Both users and applications are subject to authentication. The EHR-S
must provide mechanisms for users and applications to be authenticated. Users will have to be authenticated when they attempt to use the application, the applications must authenticate themselves before accessing EHR information managed by other applications or remote EHR-S’. In order for authentication to be established a Chain of Trust agreement is assumed to be in place. Examples of entity authentication include:
- username/ password
- digital certificate
- secure token
- biometrics."