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 --------
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.
============================
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|