RE: Security requirements

Hi Tony,
 
I imagine that when you talk about "language implementation" you mean "detailed definition of language constructs".
 
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.
 
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.
 
Ugo

-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]On Behalf Of Fletcher, Tony
Sent: Friday, November 21, 2003 11:27 AM
To: public-ws-chor@w3.org
Subject: FW: Security requirements


Dear David and Ugo and others,
 
I have a number of comments that I would like to contribute then I will bow out and let others deicide how to take forward.
 
Firstly we seemed to have dived straight into language implementation issues.  May I encourage everyone to consider and discuss the merits of the requirements that I suggested first.  Only if we agree the basic requirements is it really worth moving onto language implementation (and a project often starts of with grandiose requirements that can not all be met or completely met).  So I would ask : do people agree with my list of proposed requirements or would you like to add, subtract or re-phrase???
 
To respond specifically to some of David and Ugo's points:
 
1. Where do you stop.
We get to decide that!
I suggested strongly that the way we might met the requirements for integrity, confidentiality, etc (and yes you could include reliable messaging as well) would be just to state the requirement at that point on the choreography description - the what but NOT the how.  Thus changing hash algorithms, SOAP and so forth are well below the woodwork as far as we are concerned and do not enter the picture.  I agree and stated in my initial contribution on this topic that we should not be concerned about how the declared security requirement is met.
 
2. You lose choreography reuse.
I agree with this point but that does not mean that we should not provide the ability to state security requirements in the language.  It is always true that a choreography description that is made too specific may not be suitable for other purposes, so you are likely to run into this problem irrespective of security.  What you should be able to do is craft a choreography description with out any security 'mark up'.  This becomes your re-usable unit that you can re-use many times over with varying security mark up.
 
Another point I have already made that I would re-iterate is that a choreography description will only state requirements on what I think is called discretionary security.  Any mandatory security will be applied and enforced below - in the WSDL at the highest and often 'invisibly' to WSDL, etc in the actual communications stack.
 
David's point about extra states is interesting.  I do not think use of RM should give rise to any extra.  The complexity is handle by the RM protocol machine and all the choreography layer need to deal with is message delivered successfully of message not delivered (for some reason) and this is the same as for ordinary messaging.  (RM just increases the probability of success and the probability of failures being correctly signalled - all useful stuff.)  When you request a security feature (or several) then, yes, there is the possibility of an extra type of failure (exception) which the choreography description designer may choose to handle separately from other failure types.  But I think here we have crossed into usage matters and perhaps the need for guidelines, good practice guides and left behind language features.

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: Burdett, David [mailto:david.burdett@commerceone.com] 
Sent: 20 November 2003 01:15
To: 'Ugo Corda'; Fletcher, Tony; public-ws-chor@w3.org
Subject: RE: Security requirements


OK I want to put a stake in the ground ;)
 
The choroegraphy definition language we develop should NOT defiine ANY policy information - this includes security.
 
There are two reasons for this:
1. Where do you stop. For example you might need policy information to cover security standards, digital certificates, reliable messaging protocol, the version of SOAP, the busines document format, etc to use - do we really want to think about how we describe ALL of these (as well as ones I've not thought of) in the CDL? Secondly how do we revamp the CDL we develop whenever any of the standards on which we are dependent change?
2. You lose choreography reuse. If a Choreography definition includes policy information, then, whenever you need to change your policies, for example a different hashing algorithm in your digital signatures, you need publish a new choreography definition. This in turn will mean that you would probably have to reconsider your business process definition (or orchestration, or ... ) as, unless we are very clever, there would be no way to know that the only change in the choreography definition was a policy change and there was no change to the sequence or rules that define how messsages are exchanged and so the business process definition did not need to change.
 
So what should we do about policy information and more specifically security.
 
Firstly, I think the real issue is that the effect of applying a policy could actually affect how a choreography is performed. For example, from BurdettML you could have ...
 
<InteractionDef name="SendOrder" fromRole="Buyer" toRole="Seller" messageFamily="Order">
<InteractionEndStates fromState="OrderSent" toState="OrderReceived"/>
</InteractionDef>

Now if you then included security, then you might have additional states as in (note the bold) ...
 

<InteractionDef name="SendOrder" fromRole="Buyer" toRole="Seller" messageFamily="Order">
<InteractionEndStates fromState="OrderSent" toState="OrderReceived, OrderSecurityFailure"/>
</InteractionDef>


Note that in this the toState would be either OrderReceived or OrderSecurityFailure.   You could then, in the Choreography definition, return a different message depending on whether or not there was a security failure.
 
So the first thing I think we should consider is the allowance of additional states in a Choreography definition to allow the flow of the choreography to change depending on the outcome of applying policies such as security ... or reliable messaging ... although I don't think we should specify the precise policy information that would be used to determine whether or not a security failure, for example had occurred.
 
Secondly, I think that, if we do want to include policy information then it really should be possible to put the policy information into a separate binding layer, so that the basic choreography - that defines the sequence and conditions in which messages are exchanged -  can be reused. This would also mean that if we wanted to support new standards, new policies, etc then only the binding layer needs to change.
 
Thoughts?
 
David


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


Tony,
 
The WSDL security policies I was referring to are also at the declarative level (in the WSDL abstract interface). It's only when a specific binding is defined that those abstract declarations are mapped to specific information (e.g. SOAP headers) on the wire.
 
Ugo

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


Dear Ugo,
 
The idea is not to replicate.  I was hoping I had made that clear at the beginning by saying that I saw the CDL as being declarative - saying that things should happen here or there, but not how they happen.  I was suggesting that one could say that company policy xyz applies at this point or you could state that this particular message must be made confidential when sent (for instance).  For this to actually happen when the message was sent of course the WSDL would have to support that form of security and something 'under' WSDL (the SOAP engines??) would have to apply - by encrypting in this case possibly.
 
I hope the intent is clear now.
 

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: 19 November 2003 21:37
To: Fletcher, Tony; public-ws-chor@w3.org
Subject: RE: Security requirements


Hi Tony,
 
Assuming that our final CDL will be based on WSDL (which might be an incorrect assumption, given the fact that we currently have no stable spec), it's very likely that WSDL 2.0 will contain policy assertions including security-related ones.
 
Would it still make sense, under that scenario, to replicate those security policies at the CDL level?
 
Ugo

-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]On Behalf Of Fletcher, Tony
Sent: Wednesday, November 19, 2003 1:14 PM
To: public-ws-chor@w3.org
Subject: Security requirements


Dear Colleagues,
 
On the teleconference last night I kind of agreed to kick the ball into play on drafting some security requirements.  So here goes.
 
It seems to me that the CDL can be declarative with regard to security.  In other words it should support notation for flagging that certain security requirements have to be met at this point but can then rely on the 'stack' below the Choreography language layer to 'make it so'.
 
It should be possible to flag that a certain policy applies from this point in the choreography until the choreography ends or another flag is encountered.
 
Should be able to refer out to standard policy sets or state specific requirements explicitly.  These should include ability to require:
 
authentication of the partner and or the message content source
 
that a secure audit log is made
 
that a message is protected from change (integrity)
 
that the contents of a message are hidden (confidentiality)
 
that the sending of a message is non-repudiable
 
that the receipt of a message is non-repudiable
 
that the message or message exchange is protected against replay
 
that the time of sending of a message is recorded
 

that the time of receiving of a message is recorded
 
that a time (/date) stamp is attached to a message when sent.
 
I am sure I have missed various things, but I hope that will encourage others to add / correct / rephrase.
 

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

Received on Friday, 21 November 2003 14:39:38 UTC