Health Level Seven Standard

spongehousesΑσφάλεια

3 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

97 εμφανίσεις

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

1

Health Level Seven Standard

1


2


3


4

Context Management (“CCOW”) Specification

5

Component Technology Mapping: Web

6

Version CM
-
1.3

7


8


9


10


11

DOCUMENT ID:

HL7CCOW_2_5_01

REVISION ID:

February 25, 2000

FILE NAME:

hl7_ccow_web_cm_1_3.doc

SUPERCEDES:

HL7CCOW_6_5_00


12


13


14


15


16


17

Copyright 2001 Health Level Seven

18

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

2


1


2


3

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

3

Table of Contents

1

1

INTRODUCTION
................................
................................
................................
................................
................................
11

2

1.1

D
EFINITION OF
W
EB
A
PPLICATION

................................
................................
................................
...............................

12

3

1.2

C
OMPATABILITY

................................
................................
................................
................................
................................

12

4

1.3

D
EFINITI
ON OF
C
LINICAL
D
ESKTOP

................................
................................
................................
...............................

12

5

1.4

W
EB
T
ECHNOLOGY
C
HALLENGES

................................
................................
................................
................................
...

13

6

2

TECHNOLOGY MAPPING
................................
................................
................................
................................
...............
15

7

2.1

T
ECHNOLOGY
M
APPING
O
VERVIEW

................................
................................
................................
...............................

16

8

2.2

C
OMPONENT
M
ODE
L
M
APPING

................................
................................
................................
................................
......

17

9

2.3

C
ONTEXT
M
ANAGER

................................
................................
................................
................................
.........................

17

10

2.4

C
ONTEXT
P
ARTICIPANT

................................
................................
................................
................................
...................

18

11

2.4.1

Implementation Considerations

................................
................................
................................
...................
18

12

2.4.2

ContextParticipant Interface

................................
................................
................................
........................
19

13

2.5

W
EB
C
ONTEXT
M
ANAGEMENT
S
YSTEM
................................
................................
................................
.......................

19

14

2.6

W
EB
S
YSTEM
C
OMPONENT
D
ISTRIBUTION
O
PTIONS
................................
................................
................................
.

21

15

3

CONTEXT MANAGEMENT R
EGISTRY
................................
................................
................................
........................
23

16

3.1

S
ECURITY
C
ONCERNS
................................
................................
................................
................................
.........................

23

17

3.2

C
ONTEXT
M
ANAGEMENT
R
EGISTRY
R
ESPONSIBILITIES

................................
................................
............................

24

18

3.2.1

Locating the Context Management Registry

................................
................................
.............................
24

19

3.2.2

Locate Method

................................
................................
................................
................................
.................
25

20

3.2.3

How the Registry Locates a Component

................................
................................
................................
.....
25

21

3.2.4

Locating the Context Manager

................................
................................
................................
....................
25

22

3.2.5

Special Support for Applications Run In Citrix or Windows Terminal Server Remote Sesssions

...
26

23

3.3

U
SING THE
C
ONTEXT
M
ANAGER
URL
................................
................................
................................
............................

26

24

3.4

L
OCATING
A
UTHENTICATION
R
EPOSITORIES

................................
................................
................................
..............

27

25

3.5

C
ONTEXT
M
ANAGER
R
ESPONSIBILITIES
................................
................................
................................
........................

27

26

4

CONTEXT PARTICIPANT
IMPL
EMENTATION RESPONSIB
ILITIES
................................
................................
.
29

27

4.1

C
ONTEXT
C
HANGE
N
OTIFICATIONS

................................
................................
................................
...............................

29

28

4.1.1

Notification Protocol

................................
................................
................................
................................
.....
29

29

4.1.2

Avoiding Race Conditions

................................
................................
................................
............................
31

30

4.1.
3

Listener and Notifier Applets

................................
................................
................................
........................
31

31

4.2

B
ROWSER
-
R
ESIDENT
C
ONTEXT
P
ARTICIPANTS

................................
................................
................................
...........

31

32

4.3

C
ACHED
W
EB
P
AGES

................................
................................
................................
................................
..........................

32

33

4.4

C
ONTEXT
C
HANGE
U
SER
D
IALOGS
................................
................................
................................
................................
..

32

34

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

4

4.5

W
HEN TO
L
EAVE THE
C
OMMON
C
ONTEXT

................................
................................
................................
..................

32

1

5

SECURITY
................................
................................
................................
................................
................................
............
35

2

5.1

T
IER
1

S
ECURITY
:

CMA

I
NTERFACES

................................
................................
................................
.............................

35

3

5.1.1

Secure Binding Properties

................................
................................
................................
............................
35

4

5.1.2

Creating Digital Signatures

................................
................................
................................
.........................
36

5

5.1.3

Signature Format

................................
................................
................................
................................
............
36

6

5.1.4

Public Key Format

................................
................................
................................
................................
..........
36

7

5.1.5

Hash Value Format

................................
................................
................................
................................
.........
37

8

5.2

T
IER
2

S
ECURITY
:

S
EC
URE
S
OCKETS
L
AYER

................................
................................
................................
.................

37

9

5.2.1

Certificate Creation
................................
................................
................................
................................
........
37

10

5.2.2

Certificate Authentication
................................
................................
................................
.............................
38

11

5.3

A
DDITIONAL
S
ECURITY
C
ONSIDERATIONS
................................
................................
................................
...................

38

12

6

REPRE
SENTING CMA METHODS
AS HTTP MESSAGES

................................
................................
......................
39

13

6.1

C
OMPONENT
R
EFERENCE

................................
................................
................................
................................
.................

39

14

6.2

MIME

H
EADER
................................
................................
................................
................................
................................
....

39

15

6.3

N
AMED
A
RGUMENTS

................................
................................
................................
................................
.........................

40

16

6.3.1

Interface Name

................................
................................
................................
................................
.................
40

17

6.3.2

Method Name

................................
................................
................................
................................
...................
40

18

6.3.3

Input Parameters

................................
................................
................................
................................
.............
40

19

6.4

HTTP

C
HARACTER
E
NCODING
C
ONVENTIONS

................................
................................
................................
..............

41

20

6.5

O
UTPUT
P
ARAMETERS

................................
................................
................................
................................
......................

42

21

6.6

E
XCEPTIONS
................................
................................
................................
................................
................................
.........

42

22

7

ERROR HANDLING

................................
................................
................................
................................
..........................
45

23

8

CHARACTER SET

................................
................................
................................
................................
.............................
49

24

9

INTERFACE LISTING

................................
................................
................................
................................
.......................
51

25

9.1

T
ECHNOLOGY
-
S
PECIFIC
I
NTERFACES

................................
................................
................................
.............................

51

26

9.1.1

InterfaceInformation

................................
................................
................................
................................
.......
51

27

9.1.2

ListenerRegistrar
................................
................................
................................
................................
.............
52

28

9.1.3

ContextManagementRegistry

................................
................................
................................
.......................
54

29

9.2

CMA

I
NTERFACES

................................
................................
................................
................................
..............................

58

30

9.2.
1

AuthenticationRepository

................................
................................
................................
.............................
58

31

9.2.2

ContextAgent

................................
................................
................................
................................
...................
62

32

9.2.3

ContextData

................................
................................
................................
................................
.....................
64

33

9.2.4

ContextManager

................................
................................
................................
................................
.............
67

34

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

5

9.2.5

ContextParticipant

................................
................................
................................
................................
.........
72

1

9.2.6

ImplementationInformation
................................
................................
................................
...........................
75

2

9.2.7

MappingAgent

................................
................................
................................
................................
.................
78

3

9.2.8

SecureBinding

................................
................................
................................
................................
.................
79

4

9.2.9

SecureContextData
................................
................................
................................
................................
.........
81

5

APPENDIX
I: WEB USE CASES

................................
................................
................................
................................
............
84

6

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

6


1

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

7

Preface

1

This document was prepared by Robert Seliger, Sentillion, Inc., on behalf of Health Level
2

Seven’s CCOW Technical Committee. Comments about the organization or wording of the
3

document should be dir
ected to the author (robs@sentillion.com). Comments about technical
4

content should be directed to
ccow@lists.hl7.org
.

5


6


7


8


9


10


11

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

8


1

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

9

Changes since 1.2

1


2



Added support for annotation agents, including the ContextAgent interfa
ce.

3



Added support in the ContextManagementRegistry::Locate method for applications
4

hosted on Citrix and WTS servers.

5


6

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

10


1

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

11

1

Introduction

1

This document specifies the details needed to develop web implementations of applications and
2

components that conform to th
e HL7 Context Management Specification, Technology
-

And
3

Subject
-

Independent Component Architecture, CM
-
1.3, which shall hereafter be referred to as

4

the CMA. In these systems, context management is primarily (but not necessarily exclusively)
5

between web ap
plications. Using this specification, the resulting applications and service
6

components will be able to communicate with each other per the CMA even if they were
7

independently developed.

8

The scope of this document is limited to the details pertaining to i
mplementing CMA
-
9

conformant applications and components using the common web technologies such as those
10

defined by the Internet Engineering Task Force (IETF), World Wide Web Consortium (W3C)
11

and the European Computer Manufacturers Association (ECMA), as the
se technologies are
12

pervasive and standard. These technologies include, but are not limited to: HTTP for message
13

transport; Universal Resource Locators (URL) for representing logical addresses of entities
14

located on the web; XML and HTML as necessary for d
ata representation; Java, Java
15

Applets, JavaScript, or other scripting languages for program logic. Other web technologies not
16

explicitly described in this document may also work with the specification defined in this
17

document.

18

While there is no precise d
efinition for “web application,” the “lowest common denominator”
19

for such applications is assumed to be a 2
-
tier system in which the user
-
interface is presented
20

by a web browser and where data is served by a remote web server. Application logic may be
21

phys
ically distributed among the tiers, including the browser.

22

However, perhaps the most salient hallmark of this model of a web application is that the only
23

software that is assumed to reside on the user’s access device prior to use of a web application

24

is t
he browser. All elements of the application, including code as well as data, are dynamically
25

loaded into the browser at the time of access.

26

There are a number of ways to create web applications that are more sophisticated than the
27

least common denominator
web application described above. These so
-
called thin client
28

applications do not execute within a browser, but nevertheless use web technologies such as
29

HTTP to interact with servers. While not the design center for this specification, sophisticated
30

web ap
plications will nevertheless be able to take full advantage of the specification.

31

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

12

1.1

Definition of Web Application

1

A web application is defined as a set of one or more web pages, whose content and behavior
2

are logically related, and one or more web servers th
at work in concert to serve these pages to
3

users whose access is mediated by a web browser. The web pages may be static in nature, or
4

may be active in appearance and/or perform computations. Pages that are active in this
5

manner are generally programmed usi
ng a scripting language such as ECMA Script and/or
6

programming language such as Java.

7

1.2

Compatability

8

This specification is compatible with at least the following Java
-
capable web browsers:

9



Microsoft Internet Explorer 4.0 SP 1, or later.

10



Netscape Navigator V
ersion 4.0, or later.

11

The specification is likely to be compatible with other implementations of Java
-
capable web
12

browsers.

13

The specification also requires the capability to open local HTTP sockets via trusted Java
14

applets for the purpose of sending and re
ceiving HTTP messages between the applets resident
15

in the same host, and which may reside in the same or different browser instances on the host.
16

It is assumed that any platform that hosts web
-
based CMA
-
compliant applications also
17

respects the Internet Por
t Number Assignment Authority’s designation of well
-
known port
18

numbers.

19

1.3

Definition of Clinical Desktop

20

A context
-
enabled web clinical desktop results when a client computing device is used by a
21

particular user to access CMA
-
compliant web applications that
share clinical context. These
22

applications are accessed via one or more web browser instances. The type of each web
23

browser instance may be different (e.g., Netscape Navigator, Microsoft Internet Explorer,
24

etc.).

25

The means for supporting multiple concurren
t clinical desktops on the same client computing
26

device is not specified. The means for supporting a shared clinical desktop across multiple
27

client computing devices is not specified.

28

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

13

1.4

Web Technology Challenges

1

Web technologies present unique challenges to
implementing the CMA. These challenges
2

include:

3



The difficulties of maintaining state between a web server and each of its
4

clients.

The most wide
-
spread web communications protocol, Hyper Text Transfer
5

Protocol (HTTP), does not provide an implicit means fo
r maintaining state between
6

messages. (State is maintained for a single message transmission, so that it is possible
7

to associate a reply with the request that elicited the reply.) The maintenance of state
8

between message transmissions requires special des
ign considerations and often the
9

adoption of application
-
specific state management conventions. This situation presents
10

challenges to implementing the stateful relationship between a context manager and its
11

context participants.

12



The overhead of sending a m
essage using HTTP.

HTTP, which is layered on top
13

of TCP/IP, is designed such that a TCP/IP connection may be established and then
14

torn
-
down for each message transmission. This situation requires increased sensitivity
15

to the number of messages required to p
erform a context change transaction.

16



The absence of a standardized means for communicating unsolicited data or
17

state changes from a web server to its clients.

The current state of the art for so
-
18

called web
-
casting is actually based on polling schemes, in w
hich a client periodically
19

polls one or more web servers to determine if there has been a change that is of
20

interest to the client. These schemes lead to a tension between computing and network
21

resource utilization and responsiveness to context changes on
the part of the client.
22

This situation complicates the process by which the context manager asynchronously
23

notifies its participants that the context has changed.

24



The strictness of accepted web security mechanisms.

Web security mechanisms,
25

particularly tho
se defined for browsers, greatly limits what the browser
-
resident portion
26

of an application can do. For example, the default behavior for a Java applet operating
27

in the sandbox security model is that it can only communicate with the web server
28

from whence
it came. This situation requires sensitivity to the programming idioms
29

required or implied for context participants.

30



The challenges of determining the identity of the host for the client portion of
31

a web application.
Due to concerns about privacy and secur
ity, explicit measures
32

have been taken to make it extremely difficult for the client portion of a web
33

application (i.e., running within a browser) to determine the identity of its host. The
34

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

14

situation makes it hard for two CMA
-
based web applications to dete
rmine that they
1

are co
-
resident on the same “desktop” and should therefore participate in the same
2

context system.

3

Many of these limitations can be overcome through the use of a distributed object
4

infrastructure as the means for communication between the
browser
-
resident portion of an
5

application and its web server. These infrastructures include: Microsoft’s DCOM/ActiveX,
6

Object Management Group’s CORBA, or Java’s Remote Method Invocation (RMI) capability.

7

Unfortunately none of these technologies are domi
nant or pervasive enough to predicate a
8

healthcare standard upon. Instead, a different tact is taken, in which an application architecture
9

and means for communication among an application’s constituent components is not assumed.
10

This enables application de
velopers to choose the web technologies and architectures that meet
11

their needs. The only things that are standardized for a web
-
based CMA are the interfaces and
12

communication technology that applications must use for interaction amongst and between
13

CMA
-
co
mpliant applications and components. The details follow.

14


15


16

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

15

2

Technology Mapping

1

The CMA is technology
-
neutral. This means that while an underlying component system is
2

assumed, a specific system is not identified within the architecture. It is the purpose of
this
3

document, and its companions for other component technologies, to map the CMA to a specific
4

target technology. For the web, the technology
-
specific details specified in this document
5

include (but are not limited to):

6



HTTP
-
based messaging

7



multiple inte
rfaces

8



security

9



error handling

10



character set

11



implementable interface definitions

12

It is beyond the scope of this document to provide all of the details that are needed in order to
13

fully implement conformant CMA applications and components. The necessary add
itional
14

details are covered in a series of companion specification documents, starting most notably with

15

the Health Level Seven Context Management Specification, Technology
-

And Subject
-

16

Independent Component Architecture, Version CM
-
1.3.

17

As illustrated i
n
Figure
1
, these documents are organized to facilitate the process of defining
18

additional link subjects and to accelerate the process of realizing the CMA using any one of a
19

variety of technologies.

20


Figure
1
: Organization of HL7 Context Management Specification Documents

21


Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

16

The context management subjects and technologies that are of interest are determined by the
1

HL7 constituency:

2



There is a single HL7 context management data definition spec
ification document for
3

all of the standard link subjects. This document defines the data elements that comprise

4

each link subject. Concurrent with the publication of this document, the following
5

document has been developed:

6

Health Level
-
Seven Standard Con
text Management Specification,

7

Subject Data Definitions, Version CM
-
1.3

8



There is an HL7 context management user interface specification document for each
9

of the user interface technologies with which CMA
-
enabled applications can be
10

implemented. Each docume
nt reflects the user interface requirements established in
11

this document in terms of a technology
-
specific look
-
and
-
feel. Concurrent with the
12

publication of this document, the following document has been developed:

13

Health Level
-
Seven Standard Context Manag
ement Specification,

14

User Interface: Microsoft Windows and Web Browsers, Version CM
-
1.3

15

Finally, there is an HL7 context management component technology mapping specification
16

document for each of the component technologies. Each document provides the techn
ology
-
17

specific details needed to implement CMA
-
compliant applications and the associated CMA
18

components, as specified in this document. This document serves the role of specifying the
19

details for a CMA implementation using web technology.

20

2.1

Technology Mappin
g Overview

21

In the web technology mapping, per the CMA, each context system is comprised of a context
22

manager, context participant applications (possibly with an authentication repository), and one
23

or more context agents. The roles and responsibilities of t
hese components are unchanged from

24

the CMA, and they each implement the interfaces defined in the CMA.

25

The CMA does not specify the physical location of these components. In the web technology
26

mapping, which inherently supports distributed computing, the
context manager may be co
-
27

located or physically distributed relative to the context participants it serves. Similarly, a context
28

agent may be co
-
located or physically distributed relative to the context manager it serves. In
29

either case, communication amon
gst and between context participants, the context manager,
30

context agents, and other CMA components is via HTTP, as described next.

31

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

17

2.2

Component Model Mapping

1

Each component defined in the CMA specification is implemented as a web
-
capable program.
2

Component r
eferences are represented as absolute dereferencable URLs
1
. A URL contains all
3

of the information necessary to represent the address of a web entity and can be resolved to
4

the network location of the entity it references. The format and content of a URL d
epends
5

upon the implementation of the component to which the reference refers, and may vary across
6

component implementations.

7

Each interface defined in the CMA specification is implemented as a set of related HTTP
8

messages, one for each method, that a com
ponent may receive. The URL that references a
9

particular web component shall be the only URL necessary for accessing all of the interfaces
10

implemented by the component.

11

Denotation of the specific interface to which a message is directed shall be encoded i
n the
12

message. Each message shall also contain a representation of the same parameters and
13

exceptions as the corresponding CMA
-
defined method. The complete details of how interface
14

methods are represented as HTTP messages is specified in Chapter
6
,
Representing CMA
15

Methods as HTTP Messages
.

16

In addition to the CMA
-
defined interfaces, the web technology
-
specific interface
17

InterfaceInformation, which enables interface interrogation, is also defined (See Se
ction
9.1.1
,
18

InterfaceInformation
). All web
-
based CMA applications and components shall implement this
19

technology
-
specific interface. A client may use this interface to ask a CMA
-
compliant
20

component wh
ether or not it implements a particular CMA interface.

21

Finally, a web
-
based Context Management Registry serves as the web realization of the CM
-
22

specified Interface Reference Registry. The Context Management Registry provides a well
-
23

known service for obta
ining interface references to web
-
based CMA component instances.
24

For example, the registry provides the means for locating the context manager instance that is
25

responsible for managing the context for a particular clinical desktop.

26

2.3

Context Manager

27

A contex
t manager for web applications may reside on the clinical desktop within the browser
28

(e.g., as an applet), on the clinical desktop but outside of the browser, or on a server. In all of
29

these cases, conceptually there is only one context manager instance fo
r each clinical desktop.

30




1

In order to keep the web mapping of the CMA as simple as possible, URIs, which are Universal Resource Identifiers, and
URNs, which are Universal Resource Names, shall not be used

to represent component references.

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

18

If the context manager is hosted on a server, then it is a context manager implementation
1

decision as to how the abstraction of one context manager per desktop is achieved.

2

If the context manager is hosted within a web browser, th
en the browser must be capable of
3

sending context management
-
related HTTP messages to external sources. The browser must
4

also be capable of receiving HTTP messages from these sources and dispatching the
5

messages to the context manager.

6

The context manager
implements the interfaces defined in the CMA:

7



ContextManager

8



ContextData

9



SecureBinding

10



SecureContextData

11



ImplementationInformation

12

The mapping of these interfaces to HTTP messages is specified in Chapter
9
,
Interface
13

Listing
.

14

2.4

Context Participant

15

In the CMA, the context participant capability of a web application may be implemented within
16

the application’s web client or web server.

17

2.4.1

Implementation Considerations

18

If the context participant capability is i
mplemented in the application’s client, then special
19

attention to security may be necessary. For example, with Java 1.1, a context participant
20

implemented as an applet must be a signed applet. This is because the applet needs to have
21

access to desktop reso
urces, such as sockets. In Java 1.1 this is not possible when the sandbox
22

security model is applied, but can be achieved when the signed applet model is used.

23

If the application’s context participant capability is implemented in the application’s web serve
r,
24

then the server presumably is capable of serving multiple concurrent web clients. If this is the
25

case, then it is an application implementation decision as to how the correspondence between
26

the application’s client portion and its server
-
based context p
articipant portion is maintained.

27

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

19

2.4.2

ContextParticipant Interface

1

A context participant is a client of the context manager’s interfaces. In addition, a context
2

participant is a server when it implements the optional ContextParticipant interface. See
3

Chapter
4
,
Context Participant Implementation Responsibilities
, for a description of when this
4

interface is required and when it is optional.

5

A context participant implements this interface as a set of HTTP mes
sages that it receives,
6

each of which corresponds to a method defined for the ContextParticipant interface. The
7

approach for mapping CMA methods to HTTP messages is the same as defined for the
8

context manager. (See Chapter
6
,
Representing CMA Methods as HTTP Messages
.)

9

It is through the ContextParticipant interface that the context manager communicates with a
10

participant to conduct context change surveys and to notify a participant of the result of each

11

survey. A participant that implements this interface must be capable of receiving unsolicited
12

HTTP messages.

13

A context participant provides a URL to its ContextParticipant interface to the context
14

manager when it joins the common context, is represented
as a URL. The content and format
15

of this URL depends upon the implementation of the context participant. The URL may contain

16

context session
-
specific and/or context participant instance
-
specific information.

17

It should be noted that if the URL includes the
name of the host upon which the context
18

participant is executing, then the host shall be accessible by the Domain Name Server (DNS).
19

To avoid the dependence upon the DNS, the URL should incorporate the host’s IP address
20

instead of its name.

21

2.5

Web Context Ma
nagement System

22

The web context management components and the interfaces that they support are illustrated
23

in
Figure
2
: Web Interfaces in a Common Context System
.

24

The means by which the URLs for these interfaces are obtained is su
mmarized in
Table
1
:
25

How URLs Are Obtained
.

26


27


28

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

20


1


Figure
2
: Web Interfaces in a Common Context System

2

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

21


Server

Client’s means for obtaining server’s URL …

Client

Means for obtain
ing reference

Context Management
Registry

Context Participant

A context participant uses the URL
http://localhost:2116/

to
communicate with the context management
registry, an instance of which is present on any
desktop capable of hosting CMA
-
compliant
ap
plication clients.. The well known port 2116
was assigned by the Internet Port Number
Assignment Authority to CCOW.

Context Manager

Context Participant

A context participant obtains the URL for a
context manager from the context management
registry that
is resident on the desktop from
which the participant application was launched.

Context Manager

Context Agent

The context manager provides its URL the
context

agent when the context manager calls
MappingAgent::ContextChangesPending or
ContextAgent::Conte
xtChangesPending.

Context Agent

Context Manager

A context manager is configured with the URLs
for the site
-
specific context agents that it is to
use.

Context Participant

Context Manager

A context participant provides its URL to the
context manager when
the context participant
calls ContextManager::JoinCommonContext.

Authentication
Repository

Context Participant

A context participant is configured with the
URLs for the site
-
specific authentication
repository that it is to use.


Table
1
:
How URLs Are Obtained

1


2

2.6

Web System Component Distribution Options

3

There are six variations of component distribution options for web based context management
4

solutions. Two of these variations


a server
-
centric approach and a client
-
centric approa
ch


5

are illustrated in
Figure
3
: Example Component Distribution Options
.

6

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

22

All six variations are summarized in
Table
2
:

Web

Component Distribution Options
, which
1

assumes two CMA
-
compliant web applications
, each with a client portion and a server portion
2

and the context manager that they share. The table indicates the location of each applications
3

context participant implementation, and the location of the context manager.

4


Figure
3
: Example Component Distribution Options

5


6


7

Application 1

Application 2

Context Manager

Client

Client

Client

Client

Client

Server

Client

Server

Client

Client

Server

Server

Server

Server

Client

Server

Server

Server


Table
2
:

Web

Component Distribution Options

8



9


Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

23

3

Context Management Registry

1

The web technology mapping for the interface instance registry defined in the CMA Chapter 6,
2

Component Model, is a local service, the address of which is well
-
known, that is resident on
3

each des
ktop that hosts CMA
-
compliant application clients. The means by which this service is
4

installed upon a desktop is not specified, and depends upon the implementation of the service.

5

The purpose of this local service, known as the context management registry

(CMR), is to
6

enable CMA
-
compliant component instances to be located. Specifically, a CMA
-
compliant
7

web application may obtain from the registry the URL for the specific context manager
8

instance that it is to use when participating in a context management
session.

9

The registry is capable of responding to HTTP messages that employ URL
-
encoded
10

arguments, per Chapter
6
,
Representing CMA Methods as HTTP Messages
. The registry
11

listens for messages on the wel
l
-
known port
2116
, which has been assigned by the Internet
12

Port Number Assignment Authority to Health Level Seven expressly for use by
13

implementations of the registry. Independent of the implementation of the registry, its URL is
14

always
http://localhost:21
16/
.

15

3.1

Security Concerns

16

The proper use of the context management registry is necessary to defend against security
17

attacks. The specific attack of concern is one in which rogue user A launches a valid CMA
-
18

compliant application from their desktop, but coerces

the application to join unsuspecting user
19

B’s context session. This attack could be implemented by providing a compromised context
20

management registry that returns URLs for CMA components associated with desktops other
21

than the one on which it is running.

22

There are two parts to the defense against this attack: firstly ensuring that a client cannot
23

obtain a valid URL for a context management component for another desktop; and secondly
24

ensuring that the URL obtained by a local client is not compromised.

25

To
ensure the first, the registry shall only service local requests to locate a CMA component,
26

such as the context manager. The only way in which a client may issue such a request is for it
27

to have a component co
-
resident on the same host as the registry it w
ants to communicate
28

with. For a client component to be co
-
resident, it either needs to have been installed on the
29

host, or downloaded in the form of a trusted applet. In either case, explicit user action is
30

required. This means that the user is empowered t
o maintain the integrity of the desktop by
31

being careful as to which clients they install or trust.

32

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

24

To ensure the second, any application that is architected such that its context participant is
1

hosted other than on the desktop, e.g. on a web server, must
implement a means to
2

communicate the URL it obtains from a desktop
-
resident registry instance to its server in a
3

secure fashion.

4

Such an application generally entails the use of a desktop
-
resident applet that is part of the
5

application, and whose purpose
is to obtain the necessary URL(s) from the registry. This applet

6

then communicates the URL(s) to the server
-
resident portion of the application. In so doing,
7

this communication needs to be protected so that the server
-
based context participant can be
8

assur
ed that the URL it receives came from its own desktop
-
resident program. Otherwise it
9

would be possible for rogue user to coerce a server
-
based context participant to join the wrong
10

context. For example, the rogue user might reverse
-
engineer the URL needed

to communicate
11

with the server and include the URL for the context manager as an argument.

12

When such an application is used over public networks, then an SSL connection shall be used
13

to communicate the URL(s) from the client to the server. When used over
a private network,
14

in which case the likelihood of such an attack is much less, the use of an SSL connection for
15

this purpose is recommend but not required.

16

Though this section describes the implementation using applets, applications may use any other
17

appr
opriate mechanism that supports the same level of security.

18

3.2

Context Management Registry Responsibilities

19

The context management registry shall support the interface ContextManagementRegistry,
20

which in turn contains the method Locate. This method accepts as

an input parameter the
21

name of the component instance to locate, the CMA version of the component, the URL of the
22

calling application’s ContextParticipant interface, and an optional additional data element that
23

further describes the component of interest.

The use and content of this data element may vary
24

across different types of components.

25

3.2.1

Locating the Context Management Registry

26

An application shall use the URL
http://localhost:2116/

to address the registry. Each
27

desktop that is capable of hosting CMA
-
c
ompliant applications shall have a local instance of
28

the registry listening on this port.

29

For security reasons (see Section
3.1
), the registry will only accept invocations of the method
30

ContextManagementRegistry::Locate that o
riginate from the same host as the registry instance
31

resides upon. Therefore, the portion of the application that invokes this method must be co
-
32

resident on the same host as the registry instance.

33

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

25

This generally means that embedded within the application’
s web page is code, typically in the
1

form of a signed applet, that is capable of formulating the invocation of the method and then
2

performing the method via an HTTP socket. When an applet is used, it needs to be signed so
3

that it can perform the socket cal
l within the framework of browser
-
based security
4

mechanisms.

5

3.2.2

Locate Method

6

The Locate method returns three outputs. The first output is the URL for the desired
7

component. This output may be used to communicate with the component.

8

The second output is a st
ring that contains parameters that must be included in the HTTP GET
9

or POST messages that are used to send method invocations to the located component. (See
10

Section
9.1.3.1
,
Locate

for details.)

11

The th
ird output is the domain name for the organization or site being served by the located
12

component (e.g,
www.duke.edu

might denote Duke University Medical Center, whereas
13

www.mayo.edu

might denote The Mayo Clinic). This output enables a registry client whose

14

functionality varies depending upon the site or organization that it is serving to determine the
15

site or organization on whose behalf the located component is operating. For example, an
16

application served via a multi
-
customer application service provider
might use this parameter to
17

determine which customer site it is serving.

18

3.2.3

How the Registry Locates a Component

19

The means by which the context management registry determines which URL to return to the
20

caller is not specified. The content and format of this U
RL depends upon the implementation of
21

the located component. The URL may contain context session
-
specific and/or component
22

instance
-
specific information. It may be the case that the registry has implementation
-
specific
23

knowledge about the components that i
t locates and that this information is used by the registry
24

to create the necessary URL’s.

25

3.2.4

Locating the Context Manager

26

Currently, the registry may only be used to locate a context manager
2
. Using the Locate
27

method, the name for the component to be located

shall be the case insensitive string
28

CCOW.ContextManager

and the CMA version for this component shall be
1.3
. Both of
29

these strings are case insensitive. Further, the optional input used to specify the URL for an
30




2

In the future, the Context Management Registry may support the capability to locate other types of CMA components.

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

26

application’s ContextParticipant interface

shall be used whenever the caller of the Locate
1

method is an application that implements this interface.

2

3.2.5

Special Support for Applications Run In Citrix or Windows Terminal
3

Server Remote Sesssions

4

It may be the case that applications accessed from a clini
cal desktop are actually executing
5

within a remote Citrix or Windows Terminal Server session, which in turn displays the
6

application on the desktop. In order for these remote applications to join the context session for
7

the desktop, it is necessary that th
ey locate the same context manager as is located by the
8

applications accessed directly from the desktop.

9

To enable this, an optional data element defined for the Locate method shall be used when the
10

caller is an application running in a remote Citrix hoste
d or Windows Terminal Server (WTS)
11

hosted session. This data element makes it possible for the context management registry that is
12

resident on a Citrix or WTS server to locate the URL for the context manager associated with
13

the remote desktop at which the
application will be displayed. (See Section
9.1.3.1.2
,
Usage of
14

the Parameter
descriptiveData
, for the specific usage of this data element by Citrix of WTS
15

hosted applications.) The means by which a re
gistry implementation locates the appropriate
16

context manager URL this is not specified.

17

Note that it is always allowable to use this optional data element. When the data element is
18

provided but it is not needed by the registry, then the registry shall ign
ore it.

19

3.3

Using the Context Manager URL

20

An application shall obtain the URL for the context manager instance that it shall use solely
21

from the context management registry resident on the desktop from which the application was
22

launched. An application shall u
se the method ContextManagementRegistry::Locate to obtain
23

the necessary URL whenever it joins the common context system (via
24

ContextManager::JoinCommonContext) for a particular clinical desktop. For security reasons
25

(see Section
3.1
) an application shall never accept a context manager URL from another
26

application.

27

When the application’s context participant is implemented on the application’s web server, then
28

it will be necessary for the application to communicate the context man
ager URL it obtained
29

from the registry to its server
-
based context participant. The means by which this is achieved
30

depends upon the application’s implementation. However, when the application is used over
31

public networks, than for security reasons it shal
l be the case that this URL is communicated
32

via an SSL connection.

33

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

27

An application shall not assume that the context manager URL it obtained is valid after it
1

leaves a common context session (via ContextManager::LeaveCommonContext).

2

3.4

Locating Authentication
Repositories

3

An application that uses an authentication repository shall be configurable such that the URLs
4

for the authentication repository that it is to use can be defined.

5

3.5

Context Manager Responsibilities

6

A context manager shall be configurable such th
at the URLs for the site
-
specific context
7

agents that it is to use can be defined.

8


9

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

28


1

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

29

4

Context Participant Implementation Responsibilities

1

Developers of CMA
-
compliant web applications have a great deal of flexibility in terms of how
2

they implement their app
lications. However, there are CMA
-
imposed constraints that must be
3

respected, as described below. Additional constraints are specified in the document HL7
4

Context Management Specification, User Interface, Microsoft Windows and Web Browsers,
5

CM
-
1.3.

6

4.1

Context

Change Notifications

7

A context participant shall be capable of changing its data display whenever a context change
8

transaction is initiated by the user via another application that is a participant in the same
9

context session. Depending upon the architect
ure of a CMA
-
compliant web application, the
10

implementation of the context system of which it is a member, and the network in which this
11

system resides, it may be difficult to affect the change of the application’s data display due to a
12

context change.

13

The

reason is that knowledge of the context change may reside on a server (i.e., one that hosts
14

the context participant portion of one or more of the web applications and/or that hosts the
15

context manager), and communication from server to client can be diffi
cult or impossible in
16

certain networks. This is particularly true for public networks wherein it may not be possible
17

for a server to obtain the IP address of a client, or send it an unsolicited message, due to
18

intervening firewalls, routers, or gateways.

19

4.1.1

N
otification Protocol

20

To accommodate these restrictions, a protocol involving client
-
only HTTP messages is defined.
21

This protocol is used for notifying the web pages belonging to CMA
-
compliant applications
22

whenever a context change transaction that affects
these pages is committed. Only the web
23

pages for applications that do not have an alternative means for detecting the completion of a
24

context change transaction need to participate in this protocol.

25

4.1.1.1

Listener Responsibilities

26

When first displayed, a web pag
e that requires a local notification of a context change must
27

open an HTTP socket, register the URL, including the port number, for the socket with the
28

context manager, and listen on the socket for a context change notification. The socket shall be
29

created

such that its port number is dynamically assigned by the underlying operating system.
30

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

30

The method Register, defined for the context manager’s ListenerRegistrar interface, shall be
1

used to register the URL for a web page’s listener socket (See Section
9.1.2
,
2

ListenerRegistrar
).

3

The method ListenerRegistrar::Register also requires the participant coupon for the application
4

that is displaying this web page. This enables the

context manager to associate a listener URL
5

with a specific context participant. This means that the application must first join the common
6

context via ContextManager::JoinCommonContext before any of its web pages can register
7

their URLs with the context
manager.

8

An application may have multiple web pages, each of which is a listener. Each page may
9

create its own listener socket and register this socket with the context manager.

10

When a web page receives a notification on its listener socket it shall resync
hronize the
11

context
-
sensitive portions of its display with the current context. The means by which the web
12

page resynchronizes with the context depends upon the implementation of the underlying web
13

application.

14

The listener socket shall be closed and unreg
istered from the context manager when the page
15

is no longer displayed. The method Unregister, defined for the context manager’s
16

ListenerRegistrar interface, shall be used to unregister the URL for a web page’s listener
17

socket (See Section
9.1.2
,
ListenerRegistrar
). The context manager shall unregister all listener
18

URLs for a context participant when the participant leaves the common context and has not
19

already unregistered its listener URL(s).

20

4.1.1.2

Notifier
Responsibilities

21

At the conclusion of a committed transaction, the web page displayed by the application that
22

was used to instigate a context change transaction shall send an HTTP GET message to each
23

local socket registered with the context manager. The li
st of URLs for these sockets shall be
24

returned by the context manager as an output parameter for the method
25

PublishChangesDecision defined for the interface ContextManager. This is a technology
-
26

specific parameter (i.e., it is not defined in the CMA definit
ion for this method). Adding this
27

parameter to this method provides a simple means for an application to obtain the necessary
28

port numbers when it completes a transaction.

29

4.1.1.3

Notification Message

30

The notification message shall contain a single URL
-
encoded par
ameter with the name
31

contextChangeCoupon
, the value of which shall be the long integer value representing the
32

coupon for the committed context change transaction. The representation of this parameter
33

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

31

shall be as defined in Chapter
6
,
Representing CMA Methods as HTTP Messages
, Section
6.3
,
1

Named Arguments
.

2

4.1.2

Avoiding Race Conditions

3

A window exists in which a context change transaction instigated by an
other application in the
4

same context session may occur
before

the listener socket is ready to receive notifications.
5

This is due to the fact that an application’s web page cannot register its listener port until after
6

the application has joined the commo
n context. The application that joined the context system
7

may miss the necessary notification and therefore be out of synchrony with the current
8

context.

9

To avoid this situation, the method ListenerRegistrar::Register, which is used to register with
10

the co
ntext manager the port number for a listener socket, returns the context coupon for the
11

most recently committed context change transaction. A web page shall compare this coupon to
12

the coupon it believes to represent the most recent transaction. The means b
y which the web
13

page determines the value of the coupon it believes to represent the most recent transaction
14

depends upon the implementation of the underlying web application.

15

If the value of the coupon returned by ListenerRegistrar::Register is greater t
han the coupon
16

held by the web page, then the web page shall resynchronize the context
-
sensitive portions of
17

its display with the current context. The means by which the web page resynchronizes with the
18

context depends upon the implementation of the underl
ying web application.

19

4.1.3

Listener and Notifier Applets

20

A web page may use a signed applet to implement its listener and/or notifier responsibilities. A
21

third
-
party applet may be used as a listener, or as a notifier, simply by embedding the applet
22

necessary w
eb pages.

23

4.2

Browser
-
Resident Context Participants

24

The context participant portion of a web application may reside on the client within the
25

browser, or on the application’s server. In either case the context participant must be able to
26

open an HTTP connection

to the context manager, and it must also be able to accept incoming
27

HTTP messages that emanate from the context manager.

28

This requirement may pose certain complexities when the participant is browser resident
29

because the default security model for most b
rowsers prevents a web page from
30

communicating with servers other than the one that provided the web page. One way to avoid
31

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

32

this restriction is to use a signed applet. A signed applet enable uses to decide whether they
1

trust the source of an applet that is

subject to less restrictive security constraints.

2

4.3

Cached Web Pages

3

Most web browsers support the caching of web pages that the user has previously accessed.
4

This enables the browser to redisplay the page without necessarily accessing the server from
5

whenc
e the page came. A redisplay might occur if the URL to a cached page is opened by the
6

user via another page, the URL is explicitly entered by the user as an address, or the user
7

pages back to view previously viewed pages.

8

It is possible that the context ha
s changed since the last time the page was displayed. A web
9

application that is an active context participant shall show data that is consistent with the new
10

context, or it may attempt to set the context to reflect its internal state.

11

In order to implement

either of these behaviors, a page must be capable of detecting that it is
12

being redisplayed. This can be accomplished, for example, by embedding an applet or a
13

scripted function whose job is to perform the necessary actions upon a display event.

14

Alternati
vely, a page can be marked as not cacheable. This means that the page will be freshly
15

retrieved by the browser from the page’s web server each time the page is accessed. A page
16

marked as not cacheable will, by definition, always reflect the current context
.

17

4.4

Context Change User Dialogs

18

The CMA specifies that if a surveyed application votes to conditionally accept a context
19

change, or if an application is busy, then the instigating application must present the user with a
20

dialog through which the desired cour
se of action can be indicated.

21

The appearance and wording of this dialog for CMA
-
compliant web applications shall be the
22

same as defined in the document HL7 Context Management Specification, User Interface,
23

Microsoft Windows and Web Browsers, CM
-
1.3.

24

There

are many ways in which this dialog can be implemented, including as a Java applet, using
25

Java Script, or HTML.

26

4.5

When to Leave the Common Context

27

A web application joins the common context the first time it is accessed from a particular
28

clinical desktop. H
owever, it is not as easy to for a web application to decide when to leave the
29

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

33

context. This is because the nature of the web is such that applications are not so much opened
1

and closed, but rather are visited, often periodically over extended periods of t
ime.

2

In general, an application should leave the common context when its web pages are no longer
3

resident on the desktop from which the application is being accessed. This includes cached
4

pages as well as pages in view.

5

There are several ways that an appl
ication can accomplish this. First, it can assert that its
6

pages should never be cached. This way, an application maintains participation in the context
7

system only when its pages are visible.

8

Alternatively, an application can implement its pages so that
they are cacheable, but with the
9

inclusion of an applet or scripted function that detects when the browser purges the page from
10

the cache. The application ceases its participation in the context system when it no longer has
11

any cached or visible pages. (A
variation of this approach is for the application to designate an
12

expiration time for its pages, ensuring that they will be discarded after some period of time,
13

thereby enabling the application to leave the context system when all of its pages have
14

expired
.)

15


16

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

34


1

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

35

5

Security

1

The web technology mapping for securing communications amongst and between CMA
-
2

compliant applications and components employs a two
-
tier approach.

3

The required tier implements the chain of trust and associated secure interfaces specified in t
he
4

CMA using web technologies. This ensures that all CMA
-
related communications pertaining to
5

the chain of trust can be authenticated and message integrity can be verified, enabling an
6

authentication repository and context manager to respectively enforce c
lient access privileges
7

(where clients are programs, not people).

8

The second tier, which is required when CMA
-
related communications take place over public
9

networks, additionally ensures that all such communications are encrypted while also providing
10

an ad
ded degree of message authentication. Second tier encryption prevents unwanted parties
11

from viewing context data as it is communicated across the network. Second tier message
12

authentication ensures that only known parties (where a party is a program, not
a person) may
13

participate in a context system.

14

The second tier protections are achieved by channeling all CMA
-
related HTTP
15

communications through an inherently secure network connection using upon the Secure
16

Socket Layer v3 standard.

17

The details for implem
enting tier 1 security and tier 2 security are described below.

18

5.1

Tier 1 Security: CMA Interfaces

19

Web implementations of the CMA
-
defined secure interfaces shall use the RSA public key /
20

private key scheme and shall use the MD5 one
-
way hash algorithm. This en
sures that all
21

CMA
-
related HTTP messages can be authenticated and message integrity can be verified
22

using robust and proven algorithms that can be implemented with readily available commercial
23

technologies.

24

5.1.1

Secure Binding Properties

25

The CMA
-
defined interfa
ce SecureBinding requires that the bindee indicate to the binder
26

various security properties that depend upon the bindee’s implementation. The properties that
27

must be indicated, and the allowed value or values for each property, depend upon the
28

underlying
implementation technology.

29

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

36

For a web implementation, the following secure binding property names and values defined in
1

Table
3

shall be used.

2


3

Property Name

Allowed Value

Meaning

Technology

Web

Web technology.

PubKeyScheme

RSA

RSA public key / private key scheme.

PubKeySize

N

N is a positive integer representing the number of
bits contained in the public key.

HashAlgo

MD5

MD5 secure hash algorithm (creates 128 bit hash).


Table
3
: Secure Binding Propert
ies

4


5

Property names and values are not case sensitive. Property values shall be character
-
encoded
6

per the convention stated in the CMA specification.

7

5.1.2

Creating Digital Signatures

8

A digital signature is created from a hash of the data that is to be signed.
The data from which
9

the hash is computed must be represented in exactly the same manner as in which the data
10

was sent or received in a message, not including the HTTP
-
encoding of special characters.
11

(See Chapter
6
,
Representing CMA Methods as HTTP Messages
.)

12

5.1.3

Signature Format

13

Digital signatures passed via any of the CMA
-
defined web interfaces shall be MD5 signatures
14

with block padding as defined in PKS#1
3
. The bytes in a signature are in big
-
endian orde
r. This
15

binary data shall be character
-
encoded per the convention defined in the CMA specification.

16

5.1.4

Public Key Format

17

Public keys passed via any of the CMA
-
defined web interfaces shall be represented as a DER
18

encoded string per the ISO/IEC X.509 v3 standar
d. The bytes in a public key are in big
-
endian
19

order. This string contains binary data that has been character
-
encoded per the convention
20

defined in the CMA specification.

21




3

PKS #1 v2.0: RSA Cryptography Standard. RSA Laboratories, October 1, 1998.

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

37

5.1.5

Hash Value Format

1

Hash values passed via any of the CMA
-
defined web interfaces shall

be MD5 hashes as
2

defined in RFC1321
4
. The bytes in a hash are in big
-
endian order. This binary data shall be
3

character
-
encoded per the convention defined in the CMA specification. Hash values shall be
4

compared for equality by comparing their character
-
enc
oded string representations. Character
5

case shall not be considered when comparing these strings.

6

5.2

Tier 2 Security: Secure Sockets Layer

7

When communicating over public networks, CMA
-
compliant web applications and components
8

shall use SSL. Mutual authenticat
ion and
112
-
bit triple DES symmetric keys
shall be used,
9

wherein applications and context agents are clients, an authentication repository and the
10

context manager are servers. This requires that each CMA application and component
11

implementation shall have
an X.509 v3 compatible certificate.

12

5.2.1

Certificate Creation

13

The certificate shall be issued by a certificate authority that the site trusts. The signature
14

algorithm shall be RSA. CMA applications and components shall use the names shown in
15

Table
4

as one of the organizational unit (ou) fields within the certificate subject name.

16


17

Component

Field

Application

ou=CCOW.
ApplicationName

where
ApplicationName

is the same name that

application uses when it performs
ContextManager::JoinComm
onContext, less the
instance suffix

Authentication Repository

ou=CCOW.AuthenticationRepository

Context Manager

ou=CCOW.ContextManager

Mapping Agent

ou=CCOW.MappingAgent_
Subject


where
Subject

is the name of the standard or
custom mapped subject




4

R. Rivest. RFC 1321: The

MD5 Message
-
Digest Algorithm. Internet Activities Board, April 1992.

Context Management Specification, Component Technology Mapping: Web

Version CM
-
1.3

Copyright 2001, Health Level Seven

38

Annotat
ion Agent

ou=CCOW.AnnotationAgent_
Subject


where
Subject

is the name of the standard or
custom annotated subject


Table
4
: Certificate Subject Names

1

The field names in are not case sensitive. The characters used to represent an appl
ication
2

name may only include alphanumeric characters, the period (.) character and the underscore
3

(_) character.

4

5.2.2

Certificate Authentication

5

CMA
-
compliant web applications and CMA components shall be configurable such that the
6

implementations of these comp
onents can be instructed by a systems administrator as to which
7

other CMA application and/or component implementations they should trust when presented
8

with a valid certificate. Further, these applications and components shall be configurable such
9

that the
y can instructed by a systems administrator as to which certificate authorities they are
10

to trust for the purpose of authenticating a certificate presented by a CMA component.

11

5.3

Additional Security Considerations

12

It is recommended that users of CMA
-
compliant

applications should not be able to see or
13

otherwise easily access the cipher text, which is data that has been either digitally signed
14

and/or encrypted using digital keys. A malicious user could use cipher text in combination with