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
Use cases doc states
(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"
UsernameToken assertion in Security Policy supports only
and <HashPassowrd> assertion.
to the use case document, Nonce, and Creation timestamp should be sent
plain text passwords for better security which is a very valid
However, present security policy, and the schema(?) supports only
which can indicate to the requestor, the provider's requirement for
Password Digest, Nonce, and Created.
<HashPassword> is not present (assuming it is not
tells the requestor, that only Username, and clear text Password is
This no way indicates that the service may need a Nonce as well.
what it essentially means is that, service provider is actually
choice to the requestor:
Send a plaintext password without Nonce/Created. (Less secure) -
2.) Send a plaintext password WITH Nonce/Created. (More Secure) - -
any requestor will take the less secure route to access to service.
should have happened is:
Service provider unambiguously declaring its intention to check for
Nonce/Created irrespective of PasswordType, and rejecting any messages
then do not conform to its policy. This leaves the requestor with only
secure route to take.
that for service provider to indicate its requirement for these
TC should consider adding assertions like
<sp:NonceAssertion>, and <sp:CreatedAssertion>. The policy
look something like:
WS-SecurityPolicy schema should also be updated for the same.