[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] 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 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? 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. Danny, -1. We need to use RFC language, uppercase. Hi Alex,
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]