privacy/visibility use cases/requirements

I have an action from the last conf call to summarize previous 
discussion about privacy.

These were discussed in several previous messages to the list, most 
notably in this message:

http://lists.w3.org/Archives/Public/public-ws-chor/2003May/0012.html

and the ensuing thread.

Here is what I suggest it is useful to capture from the thread:

Mini use case #1:

JD: "If I am dealing with business transactions over the Internet, even 
with
trusted parties, I am typically fairly paranoid about exposing internal
systems to said parties. For example, in servicing an incoming request,
I may interact with systems (possibly web service-enabled, possibly not)
to which I don't give external parties any direct access. In fact, I
enforce that they have no direct access by employing a firewall."

Requirement: "internal" processes can be part of executing a 
choreography but need to be made invisible to external parties 
interacting according to the choreography. (Internal/external not 
defined here - see long thread on this topic).

SRT commented that some internal processing may be just not specified in 
the choreography - we may for example say that a service is invoked, 
without saying what happens during service invocation. Those are details 
that are not defined at the choreography level.

N.b. also if description of choreography execution is out of scope (per 
e.g. Yaron's proposal) then "hiding" internal execution details may not 
be an issue.

At minimum however IMO this requirement implies a separation between 
execution details and the interface with which a choreography 
participant interacts.

Mini use case #2:

JD: "Certain parts of my processing of a
request may expose parts of my business I regard as proprietary or
confidential. For example, I may have outsourced credit checks to a
third party. Perhaps I don't want the world to know which third party I
am using. Technically speaking the third party is part of my overall
choreography; but I want it to be invisible to my business partners."

Requirement: it should be possible to publish a portion of an overall 
choreography to a party involved in that choreography, without thereby 
giving that party knowledge of interactions (message flows) in which it 
is not directly involved.

A proposed mechanism to fulfill this requirement is to have multiple 
(but connected) choreography definitions, so that interaction between 
party A and party B can be captured in one definition, while interaction 
between party A and party C can be captured in another definition, to 
which party B is not given access.

Mini use case #3:

JJ Dubray: "I want to be able to describe choreographies where
sometimes, I require the services of a partner, and sometimes, I can do
it myself (sounds very common during design activities where sometimes
you contract the design to suppliers), as a matter of fact both cases
can happen in the same unit of work (e.g. designing a car) at run-time.
So the border line between what is external or internal can only be
resolved at run-time. "

Comment: I await clarification on this, but I'm not sure that it 
introduces a requirement different from #2. Suppose the proposed 
mechanism described above is implemented, and the choreography is 
segmented into two. Then one of the roles may be fulfilled sometimes by 
an internal partner, sometimes by an external one. In each case the 
partner "sees" only the necessarily visible part of its interaction. Is 
this unacceptable in the case where the role is fulfilled internally?

--Jon

Received on Wednesday, 21 May 2003 18:34:44 UTC