Re: [tamie] Use cases (concrete) added to requirement i014:document security

[stephen.green@systml.co.uk]

One more use case added:

Concrete use case #10:

confidentiality required but only for individual pieces of data in the  
message because there is a legacy application receiving the data which  
necessitates confidential data being included in the message. Some  
other parts of the message are needed in the event board, however,  
because conformance depends on actions which depend on such content.  
For example, the type of document in response depends on content of an  
element in the document sent - Order is sent which includes  
Order/OrderResponseType which determines whether or not a simple Order  
Response is returned. Fine grained distinction between confidential  
and visible parts of messages therefore seems to be required for this  
case. The testing and monitoring script writer is able to make these  
distinctions in the script.

-- 
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



Quoting 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
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php