Re: issue 57 on security parameters

[Karsten Riemer <Karsten.Riemer@east.sun.com>]

Jim,
I see what you mean. Persistent/Transient, while not necessarily directly
technology related, certainly are related to the software stack, and we have
to decide whether that is a good thing to specify in a business process or
not.

Here is my personal interpretaion (Chris, correct me if it is different from
yours). Persistent means "all the way into the application space", and
Transient means, "transport level" only. The business equivalent of this might
be Persistent meaning "TrustedParty to TrustedParty", vs. Transient meaning
"Firewall-to-Firewall". For instance exchange of personal health information
from a doctor to an insurance company might need to be "TrustedParty to
TrustedParty", meaning that no-one but the doctor and the claim adjustor are
allowed to see it, whereas a purchase order between two companies probably is
probably only required to be secure "Firewall-to-Firewall" (if that). 

Regardless of our decision on the boolean-vs-threeway value, we should decide
whether it makes sense to have a catch-all flag at transaction level, while
maintaining individual flags for TamperProof, Authenticated, Confidential at
the DocumentFlow level, and if so, we need to describe the override
relationship between the two.

-karsten

>Karsten,
>
>Are the 3 values technical values (for the benefit of the under lying
>technology)
>or business values (facilitates the business semantics).
>I suspect the former may be true. What is the meaning of the values in and
>of
>themselves. Confidential, tamperproof, and authenticated  are concepts taken
>from
>the UN/ECE and ABA standards and are boolean in definition (Yes,No). At the
>BTV
>level, the semantics are still business semantics. I think we need some
>clarity on
>the meaning of the values.
>
>Jim
>
>
>Karsten Riemer wrote:
>
>> Jamie,
>> for your write-up for Tuesday, here is Chris Ferris's recommendation.
>>
>> 1. For the three security parameters (isConfidential, isTamperProof,
>> isAuthenticated) that reside on DocumentFlow and on Attachment, change the
>> datatype from boolean to 'docSecurity', i.e. either "No", "persistent", or
>> "transient". 2. Replace attribute isSecureTransportRequired on
>> BusinessTransaction with the same triplet of attibutes in 1. above.
>>
>> Note, if we do this, we should also change UMM accordingly.
>>
>> Writing this, I am actually wondering about the value of being able to
>specify
>> security at the transaction level if you have it at documentFlow level.
>> Instead, it would seem a good idea to be able to override this at
>> BusinessTransactionActivity level. I won't push this, just a thought, I
>will
>> bow to the experts. It just is an example of where parameterized overrides
>> would be a very useful generic feature.
>>
>> -karsten
>>
>> ------------------------------------------------------------------
>> To unsubscribe from this elist send a message with the single word
>> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
>