Then again, I could be wrong. Relying on the core error codes might
lead to ambiguity. And I note that they do not seem to support MAC
or HMAC. Perhaps we could define a namespace for XCBF and
list our own XCBF specific codes, but the only one I can see that we
need might be a clone of the wsse code:
xbcf:UnsupportedAlgorithm - An unsupported signature, hash, MAC,
HMAC or encryption algorithm
was used
And this would not be necessary if the WSS code were more general and
specified hash, MAC and HMAC, or merely used more general words like
"cryptographic algorithm" to include these along with signature and
encryption.
Seems to me though, that the these others could be used without problems:
wsse:InvalidSecurityToken - An invalid security token was provided
wsse:FailedAuthentication - The security token could not be authenticated
or authorized
wsse:FailedCheck - The signature or decryption was invalid
Phil
Phillip H. Griffin wrote:
Monica,
In looking again more closely to the WSS-X509 dcoument, I note
that WSS-XCBF does not mention error codes (section 3.5).
Perhaps we should add a section for this. I suggest the following
mimicing the text in WSS-X509:
Implementations may use custom error codes defined in private namespaces
if needed. But it is recommended that they use the error handling codes
defined
in the WS-Security specification for signature, decryption, encoding and
token
header errors. When using custom error codes, implementations should be
careful not to introduce security vulnerabilities that may assist an attacker
in the
error codes returned .
Phil
