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


-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 <alex.yiu@oracle.com>
To: wsbpeltc <wsbpel@lists.oasis-open.org>
CC: 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]