Re: [wsbpel] Issue 291 - Proposal for vote

Certainly WS-I BSP makes sense to me. 

I recall a  discussion on the version of WS-Security however.

IIRC we decided to stay silent on the specific version and allow users
to pick the suitable version.

I am open for alternate approaches.

Regards,

Prasad

Ron Ten-Hove wrote:

 If we are
going to make binding-specific recommendations (something we
have carefully avoided elsewhere in the spec), then we should be more
helpful. Which version of WS-Security should we promote? 1.0? 1.0 with
errata applied? 1.1? By the time WS-BPEL 2.0 goes final, the WS-I basic
security profile should be done; perhaps we want to recommend that
instead?

  

Prasad Yendluri wrote:
  
    
    
    
It
seems equally absurd to me to merely “suggest” use of anything
(WS-security in
this case) in a normative section of a specification.

    
Either
we recommend or we don’t. If we do not want to mandate we use lowercase
“recommend”.
Devoting a normative section to merely  “suggest” something is silly.
In that case let
us just stay silent and kill the entire section. 

    

    
WS-Security It is a
stable and well adopted OASIS standard specification. I see
nothing wrong with recommending the use of WS-Security, as long as we
do not mandate it via RFC 2119 language (viz. uppercase RECOMMEND). 

    

    
Alex
already conveyed his  willingness to accept the amendment proposed.

    

    

    
Regards,

Prasad

 

    

    

    
From: 
[mailto:]
    

    Sent: Thursday, July 13, 2006 1:47 PM

    To: Danny van der Rijn

    Cc: Prasad Yendluri;
Alex
Yiu; wsbpeltc

    Subject: Re: [wsbpel] Issue 291 - Proposal for vote

    
 

    
The whole area of security is far too broad
and
deep for us
to give it a proper treatment in three paragraphs. It seems absurd to
recommend
(or RECOMMEND) WS-Security, when it:

    
a) isn't applicable to most binding types

b) isn't sufficient to address the general topic of security

c) has no connection at all with WS-BPEL 2.0.

    
If WS-BPEL had some sort of security model,
and
it
had some
sort of connection to WS-Security, then I could see including it as a
recommendation. Is there such a model and connection, and I missed them
somehow?

    

The way chapter 16 currently reads, it sounds like we (the TC) are
providing a
strong endorsement of WS-Security. Indeed, I wouldn't be surprised if
the
reader of chapter 16 took away an impression that WS-Security will
address all
security concerns except denial-of-service attacks. For this reason, I
was
quite happy with Alex's "softening" of the wording in chapter 16,
using "suggested" in place of "recommended".

    

Danny van der Rijn wrote: 

    
I'm not saying we should force everyone to use
WS-Security.  That's not what "strongly RECOMMENDED" or
"SHOULD" mean.  To be clear, I am advocating, and have always
advocated that we leave the wording as is.

    

    Prasad Yendluri wrote: 

    
Danny,

    

It seems you are actually -1'ng Alex's original proposal and not my
amendment
as you are calling for using the RFC / uppercase wording. I am not
convinced
that we should force everyone to use WS-Security to use BPEL (I think
that
would be result).  However that is the status quo. So is your position
then to keep the current RFC language in that section ?

    

Regards,

Prasad

    

Danny van der Rijn wrote:

    
-1.  We need to use RFC language, uppercase.

    

    Prasad Yendluri wrote: 

    
Hi Alex,

    

If we are including lower case "should" in the text of this section
anyway, I don't see an issue with use of lower case recommended, like 
"it is recommended" or  "it is highly recommended".
"strongly suggested"  seems like an oxymoron to me :)

    

Section 2 of the spec (Notational Conventions), clearly shows the
normative
keywords to be upper case (and referes to RFC2119). If needed, we could
add a
sentence to state that 'only upper case form of these keywords are
normative'
in that section.  Going out of way to change lower case recommended to
suggested is an overkill IMO.

    

Best regards,

Prasad

    

------- Original Message -------- 

    
      
        

          
          
Subject:
          

          
          
          
[wsbpel] Issue 291 - Proposal for vote

          
        

        

          
          
Date:
          

          
          
          
Wed, 12 Jul 2006 17:31:24 -0700

          
        

        

          
          
From:
          

          
          
          
Alex Yiu <>

          
        

        

          
          
To:
          

          
          
          
wsbpeltc <>

          
        

        

          
          
CC:
          

          
          
          
Alex Yiu <>

          
        

      
    
    

Issue 291: Normative wordings in chapter 16 "Security Consideration"

    

Proposal for vote: (changes highlighted in green) 

============================

    
Since messages can be modified or forged, it is
strongly suggested that business process implementations use
WS-Security to ensure messages have not been modified or forged while
in
transit or while residing at destinations. Similarly, invalid or
expired
messages could be re-used or message headers not specifically
associated with
the specific message could be referenced. Consequently, when using
WS-Security,
signatures should include the semantically significant
headers and the message body (as well as any other relevant data) so
that they
cannot be independently separated and re-used. 

    
Messaging protocols used to
communicate among business processes are subject to various forms of
replay
attacks. In addition to the mechanisms listed above, messages should include a message timestamp (as described
in WS-Security) within the signature. Recipients can use the timestamp
information to cache the most recent messages for a business process
and detect
duplicate transmissions and prevent potential replay attacks. 

    
It should also be noted that
business process implementations are subject to various forms of
denial-of-service
attacks. Implementers of business process execution systems compliant
with this
specification should take this into account. 

    
============================