security considerations

[Greg Pavlik <greg.pavlik@oracle.com>]

Proposed text for security considerations follows. Please note that we 
are also proposing additional changes to the schema for the context 
structure to include the wsu:Id attribute optionally.

Greg

Security Considerations

WS-Context is designed to be composable with WS-Security. WS-Context 
provides a context structure that is typically bound to a SOAP header as 
well as endpoints for management of context lifecycle and contents.

It is RECOMMENDED that messages containing context headers use 
WS-Security facilities for digitial signatures to guarantee message 
integrity and to verify originators of both messages and contexts. The 
message as a whole, the individual context headers, or both may be 
signed. In addition, when contexts are passed by value sensitive context 
data should be encrypted with XML encryption facilities as described in 
WS-Security for confidentiality.

The ContextType schema includes an optional attribute, wsu:Id, which is 
used for ease of processing of WS-Security features. It is RECOMMENDED 
that implementations use the wsu:Id attribute to support encryption and 
signing of the context element. In addition, the context-identifier 
element definition includes an optional wsu:Id attribute to allow 
context services to sign identifiers, while allowing other services (eg, 
the context manager) to freely update and change the content of the 
context itself.

It is RECOMMENDED that authorization checks be applied to context 
service and context manager operations. It is out of the scope of this 
specification to indicate how user identity and authorization are 
managed. Implementations may use appropriate mechanisms for the Web 
services environment. For example, user identity may be asserted via 
mechanisms described in Web Services Security Username Token Profile 1.0.

In addition to any authorization checks it may perform on the sender of 
a message, it is RECOMMENDED that applications services perform checks 
that contexts were created by authorized issuing authorities. A separate 
authorization problem arises for specific participation in specific 
activities. For example, a user may be permitted to access a service but 
not to participate in arbitrary transactions associated with the 
service. It is RECOMMENDED that application services maintain 
authorization checks for participation in specific activities based on 
domain specific requirements

In order to defend against spoofing of context-identifiers by an 
attacker it is RECOMMENDED that service managers create 
context-identifiers incorporating random parts.