Release 23.R1 (11.50)

What's New

OneSpan Notary (Remote Online Notarization)

• Introducing OneSpan Notary: OneSpan Notary enables both Remote Online Notarizations (RON) and in-person notarizations. The RON functionality enables a Notary and signers to join a remote online notary session in which the Notary: (1) acts as the session’s host; (2) permits users to sign documents; (3) confirms the signed documents with a Digital Notary Seal.

• This RON functionality introduces the following new features: (1) Notary Commission; (2) eJournal; (3) a transaction type called Remote Online Notarization.

  From the point of view of OneSpan Sign, a “Notary” is a Sender who has either been granted "Notary rights"., or who has been assigned the role Notary.

  Once a Sender is a Notary in that sense, they must configure a “Notary Commission” by: (1) clicking My Account > Notary Commission; (2) providing commission information in the dialog box that appears.

  When a Sender creates a remote online notary transaction, they must specify: (1) a valid Notary for the transaction; (2) a date and time for the transaction's signing session.

  After the Notary enters a remote online notary session, they must confirm each signer’s identity. For this initial release, the only supported authentication method is that the Notary knows the signer personally.

  A remote online notary session follows the same rules as a Virtual Room session.

  After all documents have been signed by the signers and the Notary, the Notary can end the remote notarization session. The Notary will then be redirected to an eJournal. This is an electronic log in which the Notary must record information related to their notarization. The journal can be downloaded from the My Account > Journal link in the Sender part of the New User Experience.

  For this initial release, only the following notary jurisdictions are supported: (1) Alaska; (2) Arizona; (3) Hawaii; (4) Minnesota; (5) Ohio; (6) Oklahoma; (7) Tennessee; (8) Texas; (9) Virginia; (10) Washington.

  To enable OneSpan Notary, please contact our Sales Team.

Rebranding

• Rebranded OneSpan Sign with new colors & logo: We've updated: (1) the logo and colors in the Electronic Consent document; (2) the watermark signing logo; (3) the logo in the Evidence Summary; (4) the colors in email templates.

Senders

• Added transaction descriptions to transaction names: In the Sender part of the New User Experience, transaction descriptions now appear in any list or table that contains transaction names. These descriptions appear directly under the names, but use a smaller font. This will enable Senders to differentiate transactions that have the same name.

• A document can be signed by some, and accepted by others: Formerly, Senders could assign only one of the following states to a transaction's document: (1) Signable; (2) Accept-Only. The assigned state applied to all transaction recipients. Senders now have the option of assigning another state to a document. The new state requires a document to be: (1) signed by some recipients; (2) accepted by other recipients. Note: The Transaction Owner (aka "Myself") cannot accept documents.

• Can reposition multiple fields at once: Formerly, the multiple selection of fields within the Designer could be used only to align fields. Now, this multi-select functionality can also be used to reposition multiple fields at once within the same document. This will enable some transactions to be created faster.

• ID Verification supports same email address: A transaction that uses ID Verification can now accommodate signers who have the same email address.

Developers

• Added Document ID & Recipient ID to the Audit API: The Document ID and Recipient ID are now in the JSON returned by the call api/packages/<packageId>/audit. This information will enable developers to: (1) differentiate documents that have the same name; (2) differentiate recipients who have the same name. Note: The Recipient ID is not tracked for ID Verification events.

Bug Fixes

User Authentication

• PB-87150: Fixed an issue concerning repeated authentication attempts via ID Verification's configuration called Document Verification Only. The system should have allowed only three failed attempts, but it allowed four.

• PB-87989: Fixed the following issue. If a user employed a Signer Authentication Token to access the Signer Experience, the system failed to display its customized message for unauthorized OFAC access.

Signer Experience

• PB-90661: Fixed an issue in which a signer who had just completed all their actions on a transaction was presented with the misleading message: Currently not your turn to sign.

• PB-89223: Fixed an issue that arose in the left pane of the Signer Experience. The problem was that the word DOCUMENTS overlapped the number of documents, and the word UPLOADS overlapped the number of uploads.

• PB-87913: Fixed an issue in which the Signer Experience's left pane displayed a document’s status as Signing completed, though the document still required actions.

• PB-91298: Fixed a rare race condition that caused the text entered by a signer in a Text Area field not to appear in the document after the signer: (1) signed the document; (2) reopened the document.

• PB-91711: Fixed an issue in which some Autofields were not getting populated if multiple signers had an Autofield with the same name.

Senders

• PB-85790: Fixed an issue in which a Sender opened an expired transaction from the Drafts tab, and then resent it. The problem was that the system failed to resend the transaction.

• PB-89092: Fixed an issue in which a transaction failed to be sent as expected. The root cause was that the transaction had been created from a template that used conditional logic on a field that no longer existed.

• PB-87718: Fixed an issue in which it was possible to configure a transaction expiry date that exceeded the Designer’s maximum number of days before expiration.

• PB-89186: Fixed an issue in which a user logged in to a Free Trial account, and then changed the language from the top-right menu. The problem was that the system failed to change the language of the Free Trial banner.

• PB-76319: Fixed the following issue. By clicking the Org Accounts icon on the Dashboard, Senders viewed sub-accounts that they should not have been able to view. These were sub-accounts in which the Senders had no Role.

• PB-83290: Fixed an issue in which sub-accounts failed to inherit the “theme” (e.g., branding colors) configured in the Sender part of the New User Experience.

New User Experience

• PB-87999: Fixed an issue in which some text within PDFs was not rendering properly in the New User Experience. The issue affected both the Signer Experience and senders (e.g., the Designer). Note: This issue has been fixed for most use cases. However, it may still occur when specific hardware configurations are used with unconventional PDF documents. We will continue to monitor PDF.js documentation for any resolution.

Developers

• PB-87868: Fixed the following issue. If OneSpan Sign BackOffice is used to change the value of the parameter email.from in the resource email.properties, the FROM email address in an email template's JSON should be updated automatically. The problem was that this update didn’t happen.

• PB-88857: Fixed an issue in which the system failed to translate a parameter of the email template email.bulk.send.completed.

Virtual Room

• PB-89453: Fixed an issue in which the Get started button was not visible to signers in a Virtual Room session if they were on a mobile device.

• PB-89410: Fixed the following issue that arose during a Virtual Room session. When a signer repeatedly clicked the Signature Navigator’s Next button, the system iterated through the required fields of all the session’s participants. It should have iterated through only the required fields of the current signer.

• PB-89278: Fixed an issue that arose during a Virtual Room session. The problem was that the system displayed an empty space in a signer's list of attachments.

• PB-87215: Fixed an issue in which: (1) a participant joined a Virtual Room session after the session had started; (2) the system failed to inform the participant that a recording of the session was already in progress.

Delegation

• PB-88863: Fixed an issue in which the delegation feature failed in sub-accounts.

Evidence Summary

• PB-86851: Fixed an issue in which the Evidence Summary recorded that a Confirm Signatures event was followed by a View event. The problem was that the View event never occurred.

Accessibility

• PB-89715: Fixed an issue in which Screen Readers failed to correctly read conditional logic that appeared in the Designer.

• PB-91835, PB-91405: Fixed an issue in which Screen Readers on desktop or mobile devices failed to read error messages about invalid or expired SMS passcodes.

Changed Behavior

• PB-88352: Within the Data Retention dialog box, we've changed how an Unlimited retention period is configured. A checkbox has been added.

• PB-89362: If the Incomplete Evidence Summary feature is enabled for an account, that account’s Senders can now download the Evidence Summary no matter what state the transaction is in (including Draft).

• PB-87819: The system will no longer display the popup window that was formerly used to identify recipients as acceptors or reviewers. Instead: (1) to make a recipient an acceptor, the transaction creator can merely select the Accept Only checkbox for that recipient; (2) to make a recipient a reviewer, the transaction creator can just: (a) leave the Accept Only checkbox clear for that recipient; (b) not add any fields to the document for that recipient.

• PB-86346: Before signing is complete, Initials fields used to show the signer’s full name. Such fields now show just the signer’s initials (as they will appear in the flattened – i.e., completed – view of the document).

• PB-88409: This change concerns the Signer Experience message which warns signers that their session will soon expire. Formerly, the time left before expiration was expressed as a decimal number (e.g., 4.83 minutes). That time is now expressed as whole numbers of minutes and seconds (e.g., 4 minutes and 50 seconds). The new format is more human-friendly.

Upcoming Changes

• As part of our Rebranding initiative, we will update the watermark logo that appears in signed Signature Blocks.

• As of Release 23.R2 (11.51), you will not be able to activate Enterprise Administration’s sub-accounts feature. For customers who are currently using sub-accounts, incidents related to undocumented use cases will be lowered to priority P3 or P4. For priority P1 or P2 incidents related to sub-accounts, we will use commercially reasonable efforts to provide workaround solutions if: (1) the account's use is being impacted operationally; (2) the customer cannot find a root cause of that impact within their own systems; (3) we determine that a solution for the incident does not require new code. We made this decision to focus on creating enhanced account-management features that can be achieved by integrating OneSpan Sign with our new OneSpan Transaction Cloud Platform. Note: In Release 23.R2, customers will still be able to: (1) request the creation of new accounts; (2) obtain help from our Support Team to configure their accounts.

• PB-89265: Release 23.R2 (11.51) will improve the performance of the Signer Experience by modifying the rules that govern the fetching of documents. In particular, in some situations the system will fetch an original PDF instead of a flattened PDF. Fetching an original PDF is faster because it’s stored in cache memory, whereas a flattened PDF is always regenerated when it’s fetched.

  The following paragraphs describe further details.

• Flattened PDFs: Flattened PDFs will be fetched for only the following activities: (1) viewing a signed document whose signatures have been confirmed; (2) viewing an Accept-only document after it has been accepted; (3) viewing a document that was signed or accepted by another recipient before the current recipient accessed the transaction.

  Original PDFs: Original PDFs will be fetched for all these activities: (1) accessing a document (regardless of whether it has been designated for signing, Review-only or Accept-only); (2) viewing a signed document whose signatures have not been confirmed; (3) viewing an Electronic Consent document; (4) viewing a Review-Only document; (5) viewing a document for which: (a) the current recipient has completed all their actions; (b) another recipient still has pending actions (sign or accept).

  Note: As we implemented these changes, we made efforts to preserve callback integrity – i.e., to ensure that customers’ callback integrations will continue to work without modification.