PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.
The issues coordinators will notify the list when that has occurred.
Protocol: ws-sc / ws-sp / ws-sp usecases example draft
Artifact: spec / schema / use cases doc
Support for more stringent security implementation in WS-SP as per requirements in WS-SP Usecases document
WS-SP Use cases doc states
"Line (M046) contains the Nonce element and Line
(M047) contains a timestamp. These two elements should also be included in the
PasswordText case for better security"
The UsernameToken assertion in Security Policy
supports only <NoPassword>, and <HashPassowrd> assertion.
According to the use case document, Nonce, and
Creation timestamp should be sent even for plain text passwords for better
security which is a very valid requirement IMO. However, present security policy,
and the schema(?) supports only HashPassword, which can indicate to the
requestor, the provider's requirement for sending Password Digest, Nonce, and
If <HashPassword> is not present (assuming it
is not <NoPassword>), it tells the requestor, that only Username, and
clear text Password is mandatory. This no way indicates that the service may
need a Nonce as well.
So what it essentially means is that, service
provider is actually offering a choice to the requestor:
1.) Send a plaintext password without Nonce/Created.
(Less secure) - Acceptable to service
2.) Send a plaintext password WITH Nonce/Created. (More Secure) - - Acceptable
Obviously any requestor will take the less secure
route to access to service.
What should have happened is:
Service provider unambiguously declaring its intention to check for
Nonce/Created irrespective of PasswordType, and rejecting any messages which
then do not conform to its policy. This leaves the requestor with only the more
secure route to take.
I propose that for service provider to indicate its
requirement for these elements, the TC should consider adding assertions like
<sp:NonceAssertion>, and <sp:CreatedAssertion>. The policy would
look something like:
The WS-SecurityPolicy schema should also be updated
for the same.