OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.


From: Ronald.Ten-Hove@Sun.COM [mailto:Ronald.Ten-Hove@Sun.COM]
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:


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 ?


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,

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


[wsbpel] Issue 291 - Proposal for vote


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


Alex Yiu <alex.yiu@oracle.com>


wsbpeltc <wsbpel@lists.oasis-open.org>


Alex Yiu <alex.yiu@oracle.com>

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]