Our customer is using the VIP Users API and have noticed the following behavior when trying to authenticate a user having multiple credentials. 

1. Error code returned from the authenticateUser call when credentials have different status other than Enabled (e.g. one is locked, other is disabled)is 6009: Authentication failed 
2. Error code retuned the authenticateUser call when credentials have the same status other than Enabled (e.g. one is locked, other is also locked) is 600D: Operation not allowed in current state of credential 

To add to this, the 6009 error is also returned if the OTP is validated and is wrong. So there’s no way to differentiate in the application logic that the validation fails if the otp is actually wrong or if the validation is not performed due to the fact that the tokens are in states that cannot validate any codes. 

We would expect that in case 1 the 600D error would also return since both credentials are in a state where they cannot validate OTPs or at least another code that is not the same as the Authentication Failed. Our client would like this to be opened as an Enhancement Request and be solved as soon as possible. 

Regarding returning 6009 while the credentials are in mixed state (issue 2 below): 
When none of the credentials can be used to authenticate, we return an error code saying the “Operation is not allowed in current status”. When even one credential can be authenticated, we authenticate using the OTP and return the appropriate status code. Please note that “DISABLED” credential state is NOT really a state that the credential cannot be authenticated. We allow temporary password to be used when a token is in DISABLED state. That is the reason why we return “Authentication failed”, instead of “Operation not allowed”. 

To illustrate further, please refer to the table below: 
Credential 1 status Credential 2 status Will the OTP be validated? Remarks 
ENABLED DISABLED Yes The OTP will be validated against both credentials. On the second credential, it will be treated as if it were a temporary password. 
DISABLED DISABLED Yes The OTP will be validated against both credentials, as if it were a temporary password. 
LOCKED LOCKED No Both the tokens are in a state where the validation is not allowed. 
LOCKED INACTIVE No Both the tokens are in a state where the validation is not allowed. 

There is a work around to handle this issue: 
Use getUserInfo() to find out the credential status being returned, so they can find out if it is due to the token being locked/inactive or due to OTP/temp password failed.