Use cases (concrete) added to requirement i014: document security

[stephen.green@systml.co.uk]

I've added use cases according to my action item
to requirement #014 concerning document confidentiality
security. It now reads:

"Requirement Number: 014

Requirement Type: language feature

Requirement Name: data hiding

Requirement Description: allow the hiding of certain data in eventBoard

Requirement Rationale:

Sometimes web services enablement of legacy systems involves inclusion  
of content in a message or SOAP header which must not appear in a  
trace. Normally tracing would be turned off in such a system in  
production. When testing, and all the more so with monitoring, the  
event board persists the event trace. Hiding certain data would allow  
persisting of events even in the monitoring of a production system. It  
should be possible to designate that an item of data not be persisted  
visibly in the event board.

Concrete use case #1:

1. An ebXML collaboration using ebBP and/or ebCPPA

2. Confidentiality is required as document security level

3. Confidentiality level required is 'persistent'

According to ebBP Spec 2.0.3, lines 2434 and following: "Persistent  
confidentiality is intended to preserve the confidentiality of the  
message such that only the intended party (application) can see it.  
The message MUST remain in encrypted form after it is delivered to the  
messaging node and will be decrypted only by the authorized  
application. S/MIME MAY be used to provide that functionality,  
independent of the transient confidentiality."

Also, any inappropriate visibility given to a document during  
monitoring, say, MUST trigger an exception event and signal. ebBP  
2.0.3 "It is important to surface exceptions so action can be taken".  
Note: both persistence and processing of the confidential data are to  
triger events which result in signals for providing the 'visibility'.

Concrete use case #2:

as use case #1 but in this case an audit trail is required for non-repudiation

Concrete use case #3:

as use case #1 but in this case it is clear to the monitoring software  
who is and who is not authorized to see the encrypted document  
payload. However, the monitoring software is not considered part of  
the authorized business application so there MUST NOT be any  
unencrypted visibility of the document to this software.

Concrete use case #4:

as use case #1 but in this case it is not within the capability of the  
monitoring software to know who has authorization to view the document  
without encryption.

Concrete use case #5:

as use case #1 but the design of the message handler (a web server  
with web services) means that as soon as the message is received the  
document is unencrypted and so MUST NOT have any visibility or be  
persisted anywhere (trace, etc off) until it reaches the business  
application where the access restrictions can be applied

Concrete use case #6:

as in use case #1 but here the business application which provides  
appropriate access restriction is where the monitoring is performed so  
the document can be shown without encryption and access to see it in  
the persisted components of the even board can be restricted  
appropriately

Concrete use case #7:

confidentiality required at persistent level for not just document but  
for whole message

Concrete use case #8:

confidentiality required at transient level for not just document but  
for whole message so message is encrypted between message handlers  
only and using SSL

Concrete use case #9:

confidentiality required but with web services stack providing the  
document level (and /or message level) security. This may mean that  
other standards or proprietary solutions exist to profile and govern  
this security requirement."

http://wiki.oasis-open.org/tamie/RequirementItems#preview

Best regards
-- 
Stephen D. Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice