RE: Security requirements

Dear Ugo and others,
 
Well I will postulate three cases:
 
1) security costs.  This 'cost' can manifest itself in two ways (may be
you can think of more?)
  a) performance - so if I have  or am seeking relatively unimportant
information but need lots fast I might want to do without the security
feature
  b) money cost - if the security costs per use then again I might not
want to incur the expense for unimportant information
 
2) the web service may be capable of a particular service, but some of
the 'clients' (or peers) using the service may not.  Contra wise the
client might be capable but only some instances of the web service might
be capable (again because of the development and running costs of having
various security features).
 
Generally speaking you need to be able to consider the value of the
assets (/ information) that you are seeking to protect.  If the value is
considered low or the cost of a security breach is low then security may
not be worth the expense.  If it is valuable and / or the consequences
of a breach are considerable (loss of reputation etc.) then it may well
be worth applying - sometimes it can be a legal or regulatory necessity.
So it can be a trade off - and the business experts and the security
experts working together need to be able to make trade offs appropriate
for their situation.
 

Best Regards,

Tony                           


 <http://www.choreology.com/>  

Tony Fletcher

Technical Advisor 
Choreology Ltd.
68, Lombard Street, London EC3V 9L J   UK


Phone:  

+44 (0) 870 7390076


Mobile: 

+44 (0) 7801 948219


Fax:    

+44 (0) 870 7390077


Web:

 <http://www.choreology.com/> www.choreology.com


Cohesions(tm)


Business transaction management software for application coordination



Work: tony.fletcher@choreology.com 


Home: amfletcher@iee.org

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
Sent: 21 November 2003 21:01
To: Fletcher, Tony; public-ws-chor@w3.org
Subject: RE: Security requirements


Tony,
 
Ok, I understand the case where, as you say, WSDL might specify some
security features as optional for individual messages, but I have a hard
time imagining a use case where that would apply. If I expect some level
of security for my Web service, why would I allow some messages not to
comply with it?
 
Ugo

-----Original Message-----
From: Fletcher, Tony [mailto:Tony.Fletcher@choreology.com]
Sent: Friday, November 21, 2003 12:52 PM
To: Ugo Corda; public-ws-chor@w3.org
Subject: RE: Security requirements


Dear Ugo and other Choreographers,
 
See below for comments embedded.
 

Best Regards,

Tony                           


 <http://www.choreology.com/>  

Tony Fletcher

Technical Advisor 
Choreology Ltd.
68, Lombard Street, London EC3V 9L J   UK


Phone:  

+44 (0) 870 7390076


Mobile: 

+44 (0) 7801 948219


Fax:    

+44 (0) 870 7390077


Web:

 <http://www.choreology.com/> www.choreology.com


Cohesions(tm)


Business transaction management software for application coordination



Work: tony.fletcher@choreology.com 


Home: amfletcher@iee.org

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
Sent: 21 November 2003 19:40
To: Fletcher, Tony; public-ws-chor@w3.org
Subject: RE: Security requirements


Hi Tony,
 
I imagine that when you talk about "language implementation" you mean
"detailed definition of language constructs".
<Tony> Yes </Tony>
 
I understand your point about first clearly specifying language
requirements. My point was about also keeping an eye on what is already
supported out there in the same policy area.  
<Tony> Agreed, I do realise that one needs to be realistic in specifying
requirements and not 'require' things that you have no hope of
delivering with out very good reason.  However, in general, I believe
that requirements should be considered on the merits and how to
implement them or even if it is possible/ practical to implement
especially in a V1 specification. </Tony>
 
Since the policy discussions are still ongoing within the WSDL WG, I
cannot guarantee that the type of abstract policies you are talking
about will actually be fully supported in WSDL. All I am saying is that,
IF WSDL support that type of abstract policy definitions, and IF the CDL
relies on the existence of WSDL files, then it might not be necessary to
duplicate the same information within the CDL itself but just rely on
what WSDL already specifies.  
<Tony> This may be the core of the discussion between us.  I am saying
as clearly as I can that you can not do it ALL in WSDL - by the nature
of WSDL - and that is why we need a Choreography language on top of
WSDL.  What you can specify in the WSDL is the mandatory security
features / policies.  For instance that this Web Service always requires
mutual authentication, or that confidentiality shall never be used with
this web service.  Such mandatory features should not appear in a
choreography description.  If a choreography description tries to
override a mandatory feature then it should either be ignored (if its
effect is to weaken security contrary to the mandatory policy), or
generate a fault (if it is trying to demand something that is just not
available).
 
The WSDL should also be able to state that one or more security features
are optional for the web service.  So for instance it can do
confidentiality but one does not have to use it on every instance of use
of the web service.  These are the cases where you can use the
choreography description to state exactly which messages have to be sent
confidentially and which do not.  I hope this is clear.</Tony>
 
Ugo