Vibh_26's account

Hi, 

We have recently introduced Forced SSO in one of our client's account. After that SSO implementation user is no longer able to login to this application via the credentials method. Can you please provide insights in to the API key login method and also are there any security implications if we use the API key method to login?

Is it safe to login via API key method, please share if there are any disadvantages of logging in via the API key method. I am assuming if OneSpan has given the capability to login via API key method it must be secure but i read on the integration documentation below mentioned points: Are the below mentioned points applicable to the package export and download tool?

API Keys

While API keys can be used with OneSpan Sign, we recommend that you use Client Apps instead. Clients Apps are more flexible and help reduce the number of potential security vulnerabilities.

Client apps provide the following benefits over API Keys:

• With Client Apps access can be created, rotated, or revoked as needed. API Keys are fixed, and thus if you want to make any access changes you will need to contact our Support Team.

• Multiple Client Apps can be used if you have multiple integrations configured. This helps to limit the scope of any fraudulent attack on your system. Conversely, only one API Key is provided for all integrations.

• Client Apps use temporary tokens to allow API access, which are only available for a brief period of time. API Keys do not expire, and thus any breach will require you to contact our Support Team.

Hi, 

We have recently introduced Forced SSO in one of our client's account. After that SSO implementation user is no longer able to login to this application via the credentials method. Can you please provide insights in to the API key login method and also are there any security implications if we use the API key method to login?

Hi Duo, 

I think my question is also on the same lines. We are creating a solution where a batch will take care of the deletion process automatcally post 60 days of coming into a specific status. For example if a completed status has spent 60 days in the system after first time attaining the COMPLETED status, this transaction will be deleted by our batch on 60th day. But the problem arises when a user manually moves this COMPLETED (applies to other transaction status as well) to trashed folder causing the last modified date to be updated which causes the calculation of 60 days to start again from the last modified date and not from the day when this transaction first achieved the COMPLETED status. As per our compliance mandate we cannot stroe client related documents on external system for a periiod of more than 60 days but due to thsi limitiation we are seeing scenarios where documents can be stored for more than 60 days on OneSpan. I know OneSpan also has a deletion mechanism in place based on transaction status, can you elbaorate on the logic as to how do you calculate RETAIN UNTILL parameter. Does this parameter change based on last modified date or strictly follows the date on which a transaction status first came to life? For example my transaction remained in DRAFT/EXPIRED/DECLINED status for 59 days and OneSpan data retention setting is set to delete the trnasaction on 60th day.But user moved it to TRASHED folder, will this activity change the deletion time at OneSpan end as well and move the deletion time by 60 days ahead?

Is there a way we can have a transaction lifecycle and an API to get the history of transactions:

For Example -

Transaction was created on 1st July and is in Draft State.

Transaction was modified on 2nd Jul and still in Draft state.

Transaction was moved on 3rd July to In Progress state

Transaction was modified on 4th July and In Progress State.

Transaction was completed on 5th July and in COMPLETE state.

Kindly help in understanding if there is any kind of API of this nature.

Note : We are aware about the data retention settings in OneSpan but we want to create a system of our own to control and manage the documents.

Thanks Duo for this information. So just like you have completed field the date on which the transactiom was marked as complete, do we have similar fields for other transaction status such as DRAFT, EXPIRED, DECLINED, IN PROGRESS. The idea here is to use this as an event and use it to calculate the deletion days. Currently as we don't have the event/transaction captured date we are having problems in calculating the deletion days because once a user moves the a draft status to TRASHED folder the last modified date is updated and there is no date field that actually specifies that when this transaction first came in to DARFT STATE. We cannot use created date as the draft creation date because there is a possibility that draft first went to SENT state and sender made an edit to bring it back to DRAFT state so in this case we again want the new draft creation date not the original transaction creation date.

 To summarise, do we have any sort of events that we can listen to and create checkpoints and calculations based on that to delete transactions after 60 days. 

1. For draft we want to delete it after 60 days it has bene in the same state for 60 days. Even if it moves to trashed folder manually by the user we want it o be deleted after 60 days from the date it first came to this state.

2. Based on above logic we have requirement for all other statuses when they have passed the 60 days duration in a specific status, we need to renove them.

But the problem happens in above scenarios  when someone moves them to trashed folder nad based on the last modifed date and absence of when a transaction came in to a specific status the calculation again starts from 0 for deletion.