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 <mailto: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 <mailto:amfletcher@iee.org>