Comments inline:
On May 12, 2008, at 2:11 PM, Ken Laskey wrote:
> So let me push this a little further now.
>
> When I was working service description, I emphasized that
> description needed to be at the service level rather than the action
> level because otherwise it was difficult if not impossible to
> describe the policies, functions, and effects of a service. Let me
> follow this logic and say the service interaction is that set of
> message exchanges under prescribed conditions that result in certain
> real world effects. The conditions and effects are captured in the
> execution context. The service interaction is then also defined at
> the service level and tightly bound to the execution context. As
> such, I think the scope Michael required (i.e. beyond just the
> message channel) is covered.
>
> Now to also respond to Frank's later response. I don't think saying
>
> both actions and events are *initiated* through messages
>
> really causes any problems and is probably more accurate per Frank's
> observation that the message to initiate the action will not result
> in the effect if the message doesn't get to the point of action.
> Yes, sending the message that tries to initiate an action or
> indicate an event is the critical piece for nonrepudiation, but it
> does not touch the conditions of action unless that corresponds to
> an execution context.
I am sorry, but I cannot fully agree with this. I mentioned non-
repudiation because that was a consequence of the 'attempting to act'
way of thinking.
If you postpone the 'real' action until it gets into the service then
two things follow: it becomes impossible to pinpoint the actual
performance of an action -- especially from the client's perspective
-- and it ignores the client's logical view of the world.
Consider the situation where an agent signs an agreement: i.e., the
fact that an agent agrees to a deal is fully captured by the
appropriate interpretation of the message exchanged and has nothing to
do with any back-end processing a service performs as a result.
Frank
>
> Ken
>
> +++ previous email +++
>
> I think we handled the execution context okay. The question now is
> whether (or when) a separate interaction occurs with each action or
> one interaction covers all actions within a process.
>
> I'm currently wrestling with my wife's medical insurance and related
> open enrollment (non-US citizens living in countries with civilized
> medical systems, please stop laughing) and don't currently have the
> patience to offer an opinion.
>
> Ken
>
> On May 10, 2008, at 9:38 PM, Francis McCabe wrote:
>
>> Michael has a point about 'security in depth'. It is arguably
>> better to encrypt the message than the channel.
>>
>> This is completely independent, however, from the discussion on
>> Execution Context.
>>
>> Frank
>>
>> On May 10, 2008, at 5:16 PM, Ken Laskey wrote:
>>
>>> Michael,
>>>
>>> If I had the chance to modify line 552, I would change SERVICE to
>>> SERVICE INTERACTION. My interpretation is that the service being
>>> used is an element of the interaction, but the execution context
>>> in your example specifies not only the service but also critical
>>> elements of what it means to interact with the service when that
>>> interaction falls under UK jurisdiction. So I acknowledge what
>>> you want to cover but think the service interaction accomplishes
>>> that.
>>>
>>> Before I end, let me push on this from a different angle. If a
>>> process model makes use of several actions, I can look at separate
>>> service interactions as being what is necessary to accomplish each
>>> action or as a single multi-step interaction needed to accomplish
>>> the process. I don't believe we've ever clarified that, but I
>>> think my explanations lean toward the process interpretation. We
>>> made need to pursue that to answer your question.
>>>
>>> Ken
>>>
>>> On May 10, 2008, at 7:05 PM, wrote:
>>>
>>>> Ken and Danny,
>>>>
>>>> while actions better be not assigned to execution context, it is
>>>> NOT my point.
>>>>
>>>> Ken used only one reference in RM to the executions context where
>>>> the latter is applied to "a service interaction". Here is
>>>> another reference, where EC is applied to the service itself:
>>>>
>>>> <RM>
>>>> 551 In support of the dynamics of interacting with services
>>>> are a set of concepts that are about
>>>> 552 services themselves. These are the service description,
>>>> the EXECUTION CONTEXT OF THE SERVICE and
>>>> 553 the contracts and policies that relate to services and
>>>> service participants.
>>>> <RM>
>>>>
>>>> In my original message I am saying that for the SOA service all
>>>> security measures applied to the service interaction MUST apply
>>>> to the service ITSELF also, to this or that degree; the SOA RA
>>>> HAS to point to this, otherwise we are sending a wrong message to
>>>> the community.
>>>>
>>>> To achieve this consistent security view, I propose to replace
>>>> words SOA-based message exchange by the words SOA-based systems
>>>> in the section 5.2.7. That is, I propose to extend security
>>>> requirements onto the SOA eco-system; service interaction is an
>>>> important but only a part of the SOA eco-system.
>>>>
>>>> If you disagree with me, please, say this directly. Below, I am
>>>> giving you a real-life example:
>>>> a fund management company accepts debit card payments via its Web
>>>> portal; the portal is supported by SOA services (inside
>>>> enterprise firewall), which process payments validation and store
>>>> payment attributes (including debit card number, etc.) in its
>>>> local databases for later settlement procedure. Currently, at
>>>> least, in the UK, it is required that all payment attributes
>>>> related to the card to be encrypted in certain way (in all data
>>>> stores through the processing) defined by the PCI DSS standard (https://www.pcisecuritystandards.org/tech/download_the_pci_dss.htm
>>>> ). This protects sensitive card information from the tempering
>>>> even inside the enterprise.
>>>>
>>>> Thus, security of the service body/implementation is equally
>>>> important as the security of the service interaction (via its
>>>> interface). I hope, you get me right this time.
>>>>
>>>> - Michael
>>>>
>>>
>>> -----------------------------------------------------------------------------
>>> Ken Laskey
>>> MITRE Corporation, M/S H305 phone: 703-983-7934
>>> 7151 Colshire Drive fax: 703-983-1379
>>> McLean VA 22102-7508
>>>
>>>
>>>
>>>
>>
>
> -----------------------------------------------------------------------------
> Ken Laskey
> MITRE Corporation, M/S H305 phone: 703-983-7934
> 7151 Colshire Drive fax: 703-983-1379
> McLean VA 22102-7508
>
>
>
>
