OneSpan Sign Release 11.38: Cookie-less Signing

OneSpan Sign version 11.38 was recently deployed to the preview and sandbox environments. In this latest version, we implemented the cookie-less signing in the New Signer Experience, enhanced the form field validation logic when confirming the signature, optimized the UI interface to better facilitate attachment upload process, and completed a bunch of bug fixes. For a complete list of product updates, check the 11.38 Release Note. Also refer to our Trust Center and find the deployment dates for all our environments.

In this blog, we will walk you through how OneSpan Sign implemented the cookie-less signing and how your integration can benefit from this update and provide end users a cookie-less experience across all devices. Without further delay, let’s get started!

End of Third-party Cookie

“Cookies” are small text files stored at browser side and are widely used in the modern web world. OneSpan Sign also stores session cookies or language cookies on the signer's browser to better identify logged-in users and offer features specific to individual users. When integrators consume the signing ceremony from an iFrame and present it within their own application, cookies placed by OneSpan Sign domain will be recognized as third-party cookies.

Although cookies (especially third-party cookies) are designed to serve beneficial purposes, due to the concerns of cookie fraud and invasion of privacy, many prominent browsers have already taken efforts to restrict or even to eliminate third-party cookies and cookie-based advertising. 

Cookie-less Signing Experience

Big changes are coming and OneSpan Sign has prepared ourselves to embrace a web world without cookie. Starting with release 11.38, the major functionalities and most signing scenarios in the New Signer Experience will no longer require cookies. Even if signers blocked the third-party cookie or even all cookies on their browser, they can still finish the signing process either directly through the portal or through an iFrame.

NOTE:

At this time, only the New Signer Experience offers the cookie-less signing. Directly or through integration accessing classic Signing Ceremony and sender portal still require cookies.

• Scenarios that have integration points with third-party entities, such as Equifax or an IdP server, may require the use of cookies 
• Signing with a Trust Service Provider (TSP) still requires the use of cookies
• Although the major functions no longer rely on cookies, the Cookie Policy alert will continue to display as we still track analytics, and we need to inform the signer about the changes.    

Quick Walkthrough

It’s demo time. Follow the steps below, and we will walk you through how the cookie-less signing could make a difference in your experience.

Step 1: Create a transaction

The first step is to create and send a sample transaction. You can either create it through the UI portal or with integrated methods.

Step 2: Generate a signing link

After the transaction has been sent out, you can either copy the link behind the “Go to Document” button from the email notification received by the recipient or generate either a signing URL or a link built by signer authentication token.

Step 3: Visiting the URL directly

At this point, we will try to visit the signing URL with different browser cookie settings and walk you through the expected behaviors.

Allow all Cookies / Blocking third party cookies only

Take Chrome for example. If you specify the cookie policy to allow all cookies or block third-party cookies only and hit the signing link directly at the address bar, you should be redirected to the signing ceremony like the previous experience. 

Open the developer tool (press F12) and navigate to the “Application tab”. Then expand the “Session Storage” menu. There you will find the session ID hosted in browser’s session storage instead of a cookie.

However, by default the session storage can’t be shared across different browser tabs. If you open the redirected link (/transaction/{packageId}/sign/#) in a new tab, you will get an invalid session error.

Blocking all cookies

When the New Signer Experience detected that all cookies are blocked and OneSpan Sign no longer has access to the browser's session storage, the session ID won’t be stored and the URL will remain the full signing URL including the authentication token.

Step 4: Visiting through an iFrame

Next, we will try accessing the Signing Ceremony in an iFrame with the browser blocking all cookies. You can download the sample iFrame from this code share and replace the iFrame URL with the real one.

With Chrome, we can tell if everything is working correctly if we first blocked all cookies and then opened the HTML file, the signing ceremony can be rendered properly, and we can successfully finish the signing process. When using the previous experience, an error would be displayed and the system will ask to enable the browser cookie. 

When using Safari, we can perform the same test. If we activate on both “Prevent Cross-Site Tracking” and “Block All Cookies” the signing experience will be completely cookie-less.

Visit the Developer Community Forums

That concludes our review of the new features delivered or updated in the 11.38 release. If you have any questions regarding this blog or anything else concerning integrating OneSpan Sign into your application, visit the Developer Community Forums. Your feedback matters to us!

OneSpan Developer Community

Join the OneSpan Developer Community! Forums, blogs, documentation, SDK downloads, and more.

Join Today