Re: [soa-rm-ra] Follow-up to 7-5-08 Telecom

[Danny Thornton <danny_thornton2@yahoo.com>]

In the security layers section describing network,
transport, and application layers, channel encryption
would fall into the category of transport layer and
message encryption would fall into the category of
application layer. 

Explicitly stating channel and message encryption in
the security layers section could make this point more
clear.

Danny


--- Francis McCabe <frankmccabe@mac.com> 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,
> michael.poulin@uk.fid-intl.com 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
> >
> >
> >
> >
> 
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ