Release 25.R2

Comportement modifié

Voici quelques-uns des changements de comportement dont vous voudrez peut-être être conscient.

Amélioration de la génération de clés API

Pour augmenter la sécurité de nos clés API, nous avons mis en place un algorithme de nouvelle génération qui générera des clés plus longues. Ce changement signifie que toutes les clés API existantes dans les environnements Sandbox ont été converties pour suivre le nouveau format. De plus, toutes les nouvelles clés créées lors de la création d’un nouvel utilisateur dans un environnement Sandbox suivront également ce nouveau format.

Pour vous donner le temps de vous préparer et d’effectuer des tests d’intégration, nos environnements de production seront mis à jour dans une prochaine version, qui sera annoncée à une date ultérieure.

Notez que toutes les intégrations qui ont été implémentées à l’aide des anciennes clés continueront à fonctionner. Ces touches resteront fonctionnelles jusqu’à nouvel ordre.

Les anciennes clés de bac à sable ont déjà été converties et ne peuvent pas être récupérées. Ainsi, il est fortement recommandé de conserver une copie de votre clé de production actuelle stockée dans un endroit sécurisé, dans le cas où ces clés de production seraient nécessaires pour vos intégrations actuelles. Vous ne pourrez pas récupérer la clé actuelle une fois que cette version sera publiée dans les environnements de production. Pour plus d’informations sur les déploiements en environnement de production, consultez notre Trust Center.

OAuth 2.0 s’agit du protocole standard de l’industrie pour l’autorisation en ligne. OneSpan Sign prend désormais en charge le protocole OAuth 2.0 axé sur l’accès consenti, en utilisant les informations d’identification du client de type Grant (uniquement). Pour plus d’informations sur OneSpan Sign et OAuth 2.0, reportez-vous à la Managing API Access and Authentication Settings.

Possibilité d’utiliser des clés d’accès ou une autre méthode d’authentification

Auparavant, si un destinataire avait enregistré un passkey à des fins d’authentification, la clé d’accès était la seule méthode d’authentification à sa disposition. Désormais, si un destinataire a enregistré une clé d’accès ET que l’expéditeur a configuré une autre méthode d’authentification (telle que IDV, KBA, Q&A, SMS), les deux méthodes d’authentification seront présentées au destinataire. (réfs PB-107892)

Changements supplémentaires de comportement

• Pour des raisons de sécurité, nous n’autoriserons plus les signataires à utiliser du code HTML dans le champ Raison lors du refus d’une transaction. (réfs PB-108289)

• De même, nous n’autoriserons plus les expéditeurs à saisir du code HTML dans les champs Message à tous les destinataires et Message personnel d’une transaction. Cependant, cela peut être activé en contactant notre équipe d’assistance. (réfs PB-108287)

• Nous avons mis à jour le message qui s’affiche lors de la suppression d’un membre d’un Sender Group pour préciser que le membre sera supprimé du groupe, mais qu’il ne sera pas supprimé en tant qu’expéditeur dans le compte. (réfs PB-110714)

Changements à venir

Voici quelques-unes des nouvelles fonctionnalités, modifications et améliorations que nous présenterons dans une prochaine version.

Amélioration de la génération de clés API

Pour augmenter la sécurité de nos clés API, nous avons mis en place un algorithme de nouvelle génération qui générera des clés plus longues. Cette modification signifie que toutes les clés API existantes dans les environnements de production seront converties pour suivre le nouveau format. De plus, toutes les nouvelles clés créées lors de la création d’un nouvel utilisateur suivront également ce nouveau format.

Étant donné que cette modification a déjà été implémentée dans les environnements Sandbox, nous vous recommandons d’utiliser ces environnements pour préparer et effectuer des tests d’intégration avec les nouvelles clés.

Notez qu’une fois que ce changement sera déployé dans nos environnements de production, toutes les intégrations utilisant les anciennes clés continueront de fonctionner jusqu’à nouvel ordre.

Il est fortement recommandé de conserver une copie de votre clé de production actuelle stockée dans un emplacement sécurisé, au cas où cette clé serait nécessaire pour vos intégrations actuelles. Vous ne pourrez pas récupérer la clé actuelle une fois que cette version sera publiée dans les environnements de production. Pour plus d’informations sur les déploiements en environnement de production, consultez notre Trust Center.

OAuth 2.0 s’agit du protocole standard de l’industrie pour l’autorisation en ligne. OneSpan Sign prend désormais en charge le protocole OAuth 2.0 axé sur l’accès consenti, en utilisant les informations d’identification du client de type Grant (uniquement). Pour plus d’informations sur OneSpan Sign et OAuth 2.0, reportez-vous à la Managing API Access and Authentication Settings.

Une toute nouvelle présentation introductive !

Nous introduirons une présentation améliorée du produit pour les nouveaux utilisateurs. Grâce à cette procédure améliorée, les nouveaux utilisateurs pourront suivre un guide étape par étape pour créer, préparer et envoyer leur première transaction. (refs PB-111389)

Quoi de neuf

Voici quelques-unes des nouvelles fonctionnalités et améliorations que nous avons apportées à cette version.

BÊTA- Autres améliorations apportées aux groupes ad hoc :

Suite à notre première version de Ad Hoc Groups dans la version 25.R1, nous continuons d’améliorer et d’améliorer cette fonctionnalité. Dans cette version, vous trouverez ce qui suit : (refs PB-108663)

• La possibilité de définir un message personnel pour chaque destinataire de groupe ad hoc.

• Possibilité de spécifier si les membres du groupe ad hoc peuvent télécharger le document Evidence Summary une fois la transaction terminée.

• Vous pouvez désormais activer ou désactiver la livraison d’e-mails pour les groupes ad hoc.

• La mise à jour et la suppression de groupes ad hoc et de membres peuvent être effectuées à partir de l’interface utilisateur et à l’aide d’API.

• Vous pouvez remplacer un destinataire par un groupe ad hoc.

• De même, vous pouvez convertir un groupe ad hoc en un autre type de destinataire.

• Vous pouvez définir une langue spécifique pour vos groupes ad hoc.

• L’utilisation d’un ordre de signature est désormais possible.

• La visibilité des documents est désormais prise en charge par les groupes ad hoc.

• Rappels de signature. Les boutons de rappel sont disponibles à la fois au niveau de la transaction et au niveau du destinataire.

• Rappels programmés par e-mail

• Un affichage plus clair des informations sur les bénéficiaires du groupe ad hoc dans le résumé des preuves.

Cette fonctionnalité est actuellement en version bêta et n’est disponible que pour les environnements Sandbox .

BETA - Nouveaux tableaux de bord des transactions :

Nous avons mis à jour nos rapports d’analyse des transactions avec les nouveaux tableaux de bord suivants : (refs DAG-50)

• Performance des transactions : Ce tableau de bord permet de visualiser et d’analyser les performances des transactions, y compris leur distribution et leurs modifications au fil du temps.

• Vitesse de transaction : Ce tableau de bord permet d’analyser le temps nécessaire pour que les transactions passent par les différentes étapes jusqu’à leur achèvement.

• Volume des transactions : ce tableau de bord permet d’analyser le volume des transactions et les tendances de statut au fil des mois, ce qui peut à son tour aider à identifier les modèles et les tendances de performance.

Notez ce qui suit :

• Cette fonctionnalité n’est disponible que pour les utilisateurs disposant de rôles d’administrateur ou de gestionnaire , ou pour les utilisateurs disposant de l’autorisation Rapports activée pour eux.

• Pour activer cette fonctionnalité, vous devez contacter notre équipe d’assistance.

• Les données sont actuellement limitées aux transactions qui n’ont PAS été purgées ou supprimées avant le 30 mars 2025. À compter d’avril 2025, toutes les données sur les transactions seront disponibles.

Cette fonctionnalité est désormais disponible dans tous les environnements (à l’exception des environnements FedRAMP - pour plus d’informations, voir Unsupported FedRAMP features).

Une nouvelle clause de non-responsabilité relative à la conservation des données a été ajoutée :

Nous avons ajouté une clause de non-responsabilité à la page Conservation des données afin de clarifier les règles de priorité pour la suppression des données. Pour résumer, si la limite de durée de vie totale de la transaction est plus courte que toute autre limite de conservation des données , la limite de la durée de vie totale de la transaction prévaudra et supprimera la transaction une fois qu’elle aura atteint la limite définie. Veuillez noter que cette clause de non-responsabilité n’est fournie qu’à titre informatif - aucun changement n’a été apporté au fonctionnement de la conservation des données. (réfs PB-113365)

BETA - Améliorations de la contre-signature

Counter Signing est désormais pris en charge pour les expéditeurs de compte et les destinataires des propriétaires de transaction (moi-même), en particulier pour les types de transaction de signature électronique et de signature électronique en personne . Cette amélioration couvre l’ensemble du flux de bout en bout, de la configuration des contre-signataires dans l’interface utilisateur de l’expéditeur à la réalisation de l’expérience du signataire, garantissant ainsi la création, la signature et l’achèvement des transactions en douceur.

La contre-signature est également désormais prise en charge dans Bulk Transactions, ce qui garantit un comportement cohérent des signataires dans les flux de transactions uniques et en bloc.

Cette fonctionnalité est actuellement en version bêta et n’est disponible que pour les environnements Sandbox .

Intégrations de flux de travail

Dans OneSpan Sign pour Salesforce, vous pouvez désormais activer ou désactiver la fonction d’ordre de signature qui a été introduite dans OneSpan Sign Release 25.R.1 (réfs PB-111794)

Nous avons apporté les améliorations suivantes à nos intégrations de flux de travail OneSpan Sign pour Greenhouse, OneSpan Sign pour SharePoint, OneSpan Sign pour MS Dynamics et OneSpan Sign pour HubSpot : (réfs PB-111184, 113079, 113082)

• Les utilisateurs peuvent désormais ajouter une méthode d’authentification (SMS, Q&R) pour les contacts.

• Il est désormais possible d’ajouter plusieurs signataires aux champs de contact.

• Vous pouvez maintenant définir un ordre de signature pour vos contacts.

Nous avons également développé une nouvelle intégrationWorkday qui s’aligne plus étroitement sur le cadre Workday Business Process. Cette intégration intègre la signature en tant que sous-processus au sein d’un processus métier. Dans ce processus, une étape de signature est déclenchée à la fin de l’étape précédente, et l’achèvement et l’archivage des documents signés déclenchent ensuite l’étape suivante dans le cadre de processus métier. (réfs DAG-103)

Le Transaction Report affiche désormais deux colonnes supplémentaires pour vous donner des informations supplémentaires sur vos transactions : (refs PB-108394)

• Source de la transaction : l’intégration de flux de travail qui a initié la transaction. Par exemple, CRM ou HubSpot.

• Destination de la transaction : l’emplacement d’archivage ou de stockage de la transaction. Par exemple, Google Drive.

Bogue

Les problèmes suivants ont été résolus dans cette version :

Administrateurs

• Dans les situations où un utilisateur a choisi d’ignorer une invite de géolocalisation, le résumé des preuves comprend un message trompeur indiquant « Géolocalisation : n’a pas permis la géolocalisation ». Nous avons mis à jour ce message afin qu’il indique désormais « Géolocalisation : l’utilisateur n’a pas répondu ». (réfs PB-111867)

• Account Reports génèrent à nouveau au quotidien. (refs PB-113170)

Authentification

• Si une erreur système se produit lors de l’authentification IDV (par exemple, si la connexion réseau est interrompue ou si une erreur système se produit), les utilisateurs verront un message d’erreur et ne seront plus invités à entrer un numéro de téléphone. (réfs PB-111867)

Notarisation et salle virtuelle

• Lors de la création d’une transaction Virtual Room avec un fuseau horaire PST, il y avait un écart entre l’heure programmée définie dans la transaction et l’heure affichée dans l’invitation à la réunion envoyée au destinataire. Plus précisément, le fuseau horaire affiché au destinataire était trois heures plus tôt que l’heure spécifiée par l’expéditeur. Ce problème a été résolu. (réfs PB-112691)

Expéditeurs

• Le lien URL dans le modèle email.lock.signer redirigeait parfois un utilisateur vers l’expérience du signataire, et non vers le tableau de bord de l’expéditeur. Le lien fonctionne maintenant correctement. (réfs PB-110927)

• Toute tentative d’utilisation d’une esperluette (&) dans un e-mail n’entraîne plus d’erreur d’e-mail non valide . (réfs PB-111839)

• Nous avons résolu un problème qui empêchait l’utilisation de la date d’expiration d’être différente et celle des jours d’expiration.

Signataires

• Lorsque vous tentez d’afficher un Signer Experience sur un appareil mobile, les valeurs des listes déroulantes ne s’affichent pas correctement. Cela ne se produit plus. (réfs PB-111868)

• Nous avons résolu un problème qui empêchait les noms de champ dans les messages d’erreur affichés dans le Signer Experience de correspondre aux noms de champ définis dans le Designer. (réfs PB-112851)

• Les signatures disparaissaient parfois d’un document dans le Signer Experience lorsqu’un signataire avait des pièces jointes à télécharger et que les signatures étaient confirmées. Ces signatures réapparaîtront sur le document une fois actualisées. Ces signatures ne disparaissent plus. (refs PB-114232)