tlolkus's account

Duo, 

I have a new question about recovery when there are KBA Failures due to multiple failed attempts.  Sounds like the KBA Failure Callback is triggered if one of 2 things happens:  1)There is invalid signature data or 2)There are multiple KBA failure attempts to correctly answer questions and the user hits the max number of attempts.

My question is the recovery options for the multiple failures scenario.  Your response indicates that the sender can 'unlock' the user, very similar to how they can unlock someone that fails SMS/Q&A.  I assume that is still correct.  The KBA failure email template indicates however that after a 72-hour period, the signer will be able to regain access to the questions.  I am trying to confirm if both of these recovery options are available.  I am assuming here that the user can either manually unlock them or they will automatically be unlocked in 72-hours, which ever one comes first.  If you could confirm I would appreciate it.  

email.kba.failure
This template sends an email to the package owner when a signer fails in their attempt to authenticate themselves through KBA (Knowledge Based Authentication).

Hi $PACKAGE_OWNER_NAME;,

$PREVIOUS_SIGNER_NAME; has failed authentication, and will not be able to access "$PACKAGE_NAME;".

Please review and update the recipient information then resend the transaction or choose another type of authentication.

If the recipient failed to answer the knowledge-based authentication questions correctly, they will need to wait a 72-hour period to regain access to the questions.

Thank you,
The OneSpan Team

Thanks,

Tricia

Duo,

We greatly appreciate your help in trying to sort all this out.   At the end of the day, it looks like your .Net SDK has some deficiencies when it comes to trying to sort out the specifics of a KBA failure.  Unfortunately, we cannot just depend on the callbacks to try and determine if the KBA failed because of 1) not answering the questions correctly, 2) not answering the questions the maximum number of times thus Locked out or 3) due to invalid signer data.   Each of these 3 scenarios reports the status of KBA as 'FAILED'  through the .Net SDK.  We do not want to compromise our design by using API calls or reflection to try and extract this additional information.  We need to be able to extract this data from the package using the .Net SDK in case the callbacks fail or are unavailable.

Therefore, what is the process to make an official enhancement request to allow all KBA statuses to be available via the .Net SDK?  

Thanks!  I have submitted the enhancement request and I do understand that if this gets fixed in the future we would need to upgrade to get it.  For the moment we are moving forward with just reporting it as KBA Failed in our UI and the Sender will have to try and figure out why it failed.  We expect to get some feedback from customers that won't like this so in anticipation of that, it would be nice if this was fixed in a future release and we can take advantage of it the next time we upgrade.  

I just wanted to post the response I got from Support in case anyone else needs the answer to this question.  Here was there response.

"There is no limit for number of documents. The limit lies with the size and complexity of the document as they will be rendered by the document engine. Higher size and complexity will cause the system to render it more slowly up to a point it may reach the timeout of the DE. 

In terms of file size limit, I believe it is 16mb. It is a hard coded limit. We usually advise customers to try limiting document size to 5mb in practice so that the overall system performance is optimized.

The request size limit depends on the application server configuration and load balancer. For the application server, the esep.xml file for Wildfly systems would be defined in the following:

<http-listener name="default" socket-binding="http"max-post-size=" "/> <https-listener name="https" socket-binding="https" security-realm="WebSocketRealm"max-post-size=" "/>

This can be set to 25MB (26214400). The request size involves all the documents in the transaction including the signature fields and other elements (text fields, text areas, captured signature, etc.)."