1.0 Introduction

1.1 Overview

The Entity Identity Assertion Component provides the mechanisms to ensure that an entity is the person or application that claims the identity provided. An example of this Component is the validation and assertion of a consumer logging on to a Personal Health Record (PHR) system.

The meaning of the Entity Identity Assertion Component will vary depending on the perspective taken by the implementer of HITSP constructs. The scope of this Component is limited by the context of AHIC Use Cases to the servicing of requests by a service provider from a service user (which can be defined as any of the systems currently identified within HITSP Interoperability Specifications). The Component is designed to work in conjunction with the collection of an audit trail (as defined in HITSP/T15 Collect and Communicate Security Audit Trail) and with the maintenance of consistent time (as defined in HITSP/T16 Consistent Time).

The scope of this Component represented by all scenarios in which HITSP constructs interact across enterprise boundaries, as well as interactions that may occur within an enterprise, i.e., the assertion mechanism is the same whether the Use Case scenarios are within an enterprise or across enterprises. The scope of this Component is also limited to how to correctly assert the identity of a service user to a service provider.

The specific perspective chosen for this Component is to leverage the IHE Cross-Enterprise User Authentication (XUA) Supplement to the IHE-ITI-TF-2. The technological mechanism that this IHE profile relies on is Security Assertion Markup Language (SAML) assertions. This Component also provides support for evolving and ongoing work to support web services through constraining the Web Service-Security standards.

1.2 Copyright Permissions

COPYRIGHT NOTICE

2009 ANSI. This material may be copied without permission from ANSI only if and to the extent that the text is not altered in any fashion and ANSIs copyright is clearly noted.

1.3 Reference Documents

This section provides a list of key reference documents and background material.

A list of key reference documents and background material is provided in the table below. These documents can be retrieved from www.hitsp.org.

Table 1-1 Reference Documents

Reference Document

Document Description

HITSP Acronyms List

Lists and defines the acronyms used in this document

HITSP Glossary

Provides definitions for relevant terms used by HITSP documents

TN900 - Security and Privacy TN900 - Security and Privacy

TN900 is a reference document that provides the overall context for use of the HITSP Security and Privacy constructs

1.4 Conformance

This section describes the conformance criteria, which are objective statements of requirements that can be used to determine if a specific behavior, function, interface, or code set has been implemented correctly.

1.4.1 Conformance Criteria

In order to claim conformance to this construct specification, an implementation must satisfy all the requirements and mandatory statements listed in this specification, the associated HITSP Interoperability Specification, its associated construct specifications, as well as conformance criteria from the selected base and composite standards. A conformant system must also implement all of the required interfaces within the scope, subset or implementation option that is selected from the associated Interoperability Specification.

Claims of conformance may only be made for the overall HITSP Interoperability Specification or Capability with which this construct is associated.

1.4.2 Conformance Scoping, Subsetting and Options

A HITSP Interoperability Specification must be implemented in its entirety for an implementation to claim conformance to the specification. HITSP may define the permissibility for actor scoping, subsetting or implementation options by which the specification may be implemented in a limited manner. Such scoping, subsetting and options may extend to associated constructs, such as this construct. This construct must implement all requirements within the selected scope, subset or options as defined in the associated Interoperability Specification to claim conformance.