Authentification des signataires

Pour télécharger l'exemple complet de code, consultez notre site de partage de code .

Pour ajouter une couche supplémentaire de sécurité à vos transactions en ligne, OneSpan Sign propose des options d'authentification des destinataires robustes et flexibles. Plus précisément, vous pouvez sélectionner différentes façons de vérifier l'identité du destinataire d'une invitation à une transaction avant qu'il ne soit autorisé à accéder aux documents de la transaction.

L'authentification générale désigne des outils intégrés à OneSpan Sign qui vous permettent de vérifier l'identité du destinataire via SMS, e-mail ou un format personnalisé de questions-réponses.

L'authentification basée sur les connaissances (KBA) dépend d'un fournisseur tiers de KBA pour effectuer l'authentification. Ce prestataire est LexisNexis. .

Les questions KBA sont générées dynamiquement, en fonction des informations contenues dans le rapport de crédit personnel du signataire.

L'authentification KBA peut être utilisée conjointement avec l'une des méthodes générales d'authentification ci-dessus.

Pour permettre l' authentification basée sur les connaissances, veuillez contacter notre équipe de support.

Validation du numéro de téléphone SMS

Lors de l'utilisation de l'authentification SMS, le OneSpan Sign évalue le numéro de téléphone fourni dans la charge utile de la requête afin de déterminer comment il doit être interprété et validé. Comprendre ce comportement aide à garantir que les numéros de téléphone sont correctement traités et que les messages d'authentification sont délivrés avec succès.

Si un numéro de téléphone contient exactement 10 chiffres sans signe d'ouverture +, OneSpan Sign suppose automatiquement que le signataire se trouve en Amérique du Nord. Dans ce cas, le code 1 pays est ajouté au numéro avant qu'il ne soit stocké ou retourné dans la charge utile de réponse.

Par exemple :

5551234567 devient 15551234567

Ce comportement ne s'applique que lorsque le chiffre est de 10 chiffres et n'inclut pas de code pays explicite.

Certains pays utilisent également par défaut des numéros de téléphone à 10 chiffres. Si le signataire se trouve en dehors de l'Amérique du Nord mais que son numéro compte toujours 10 chiffres, vous devez inclure un en-tête + dans la charge utile de la requête. Cela garantit que le système ne suppose pas à tort que le numéro appartient au plan de numérotation nord-américain.

Par exemple :

+5551234567

Utilisation de l'authentification générale

Le code ci-dessous illustre comment modifier le bloc signataire pour chaque méthode d'authentification générale. Si vous avez besoin d'une comparaison avec la création basique d'objets documents, ou si c'est la première fois que vous créez un package avec le SDK Java, consultez cette page Création d'une transaction.

.withSigner(
    newSignerWithEmail("first.signer@email.com")
        .withFirstName("First")
        .withLastName("Signer")
        .challengedWithQuestions(
            ChallengeBuilder.firstQuestion("What's your favorite sport?")
                .answer("soccer")
                .secondQuestion("What music instrument do you play?")
                .answer("drums")
        )
)
.withSigner(
    newSignerWithEmail("second.signer@example.com")
        .withFirstName("Second")
        .withLastName("Signer")
        .withSmsSentTo("1234567890")
)

Envoi manuel d'un code SMS

Un nouveau code SMS est généré et envoyé à chaque fois qu'un signataire clique sur le lien de l'email. Si pour une raison quelconque vous devez envoyer manuellement un nouveau code SMS, vous pouvez le faire en utilisant PackageService et en passant les objets PackageId et Signer comme paramètres. Le code suivant le fera ainsi :

eslClient.getPackageService().sendSmsToSigner(
    packageId,
    retrievedPackage.getSigner(email1)
);

Utilisation du KBA

Vous pouvez aussi authentifier un signataire avec KBA. Vous pouvez aussi modifier le bloc signer pour implémenter la KBA. Le code suivant le fera ainsi :

.withSigner(newSignerWithEmail(email1)
                        .withFirstName(FIRST_NAME)
                        .withLastName(LAST_NAME)
                        .challengedWithKnowledgeBasedAuthentication(newSignerInformationForLexisNexis()
                                .withFirstName(FIRST_NAME)
                                .withLastName(LAST_NAME)
                                .withFlatOrApartmentNumber(FLAT_OR_APARTMENT_NUMBER)
                                .withHouseName(HOUSE_NAME)
                                .withHouseNumber(HOUSE_NUMBER)
                                .withCity(CITY)
                                .withZip(ZIP)
                                .withState(STATE)
                                .withSocialSecurityNumber(SOCIAL_SECURITY_NUMBER)
                                .withDateOfBirth(DATE_OF_BIRTH)))

Résultats

Après avoir exécuté votre code, si une transaction est envoyée avec l'authentification du signataire activée, vos signataires devront valider leur identité en utilisant la méthode spécifiée dans la transaction.

Avec l' authentification basée sur les connaissances, l'identité du signataire est vérifiée en lui posant une série de questions sur son rapport de crédit personnel.

Pour télécharger l'exemple complet de code, consultez notre site de partage de code .

Pour ajouter une couche supplémentaire de sécurité à vos transactions en ligne, OneSpan Sign propose des options d'authentification des destinataires robustes et flexibles. Plus précisément, vous pouvez sélectionner différentes façons de vérifier l'identité du destinataire d'une invitation à une transaction avant qu'il ne soit autorisé à accéder aux documents de la transaction.

L'authentification générale désigne des outils intégrés à OneSpan Sign qui vous permettent de vérifier l'identité du destinataire via SMS, e-mail ou un format personnalisé de questions-réponses.

L'authentification basée sur les connaissances (KBA) dépend d'un fournisseur tiers de KBA pour effectuer l'authentification. Ce prestataire est LexisNexis. .

Les questions KBA sont générées dynamiquement, en fonction des informations contenues dans le rapport de crédit personnel du signataire.

L'authentification KBA peut être utilisée conjointement avec l'une des méthodes générales d'authentification ci-dessus.

Pour permettre l' authentification basée sur les connaissances, veuillez contacter notre équipe de support.

Prétraitement des numéros de téléphone et directives de mise en forme E.164

En plus de la validation du numéro de téléphone SMS décrite ci-dessus, OneSpan Sign utilise également un flux de prétraitement qui aseptifie et standardise toutes les entrées dans le format E.164 reconnu internationalement. Cela garantit que les chiffres sont stockés et retournés dans une structure cohérente à travers toutes les API.

E.164 est la norme mondiale pour la numérotation téléphonique internationale telle que définie par l'Union internationale des télécommunications (UIT). Il définit comment les numéros doivent être structurés afin qu'ils puissent être reconnus et acheminés partout dans le monde. Un numéro de téléphone E.164 comprend :

• Un maximum de 15 chiffres

• Chiffres seulement (0–9)

• Pas d'espaces, de traits d'endroit, de parenthèses ou d'autres séparateurs

• Un point de départ + A pour indiquer un numéro international

OneSpan recommande de soumettre directement les numéros de téléphone au format E.164. Cependant, notre système accepte également plusieurs formats alternatifs saisis par les utilisateurs et les standardise automatiquement. Cela signifie que nous acceptons différentes entrées formatées et les convertissons dans la bonne structure E.164 lors du prétraitement.

Par exemple, nous acceptons des entrées telles que :

(+32) 0470123456

Même si cet exemple inclut des parenthèses et un zéro à l'avant après le code pays, notre prétraitement supprime les caractères non digitaux et le zéro en tête, et les renvoie au format E.164 :

+32470123456

L'utilisation d'un zéro en tête est acceptée par la plupart des pays européens, mais peut ne pas l'être par tous. L'utilisation d'un zéro en tête n'est pas acceptée pour les nombres nord-américains.

L' Get Package API renverra toujours le numéro de téléphone dans ce format standardisé.

+ [Indicatif pays] [Code de destination nationale] [Numéro d'abonné]

Voici quelques exemples de nombres E.164 :

Utilisation de l'authentification générale

Le code ci-dessous illustre comment modifier le bloc signataire pour chaque méthode d'authentification générale. Si vous avez besoin d'une comparaison avec la création basique d'objets documents, ou si c'est la première fois que vous créez un package avec le SDK Java, consultez cette page Création d'une transaction.

.WithSigner(
    SignerBuilder.NewSignerWithEmail("first.signer@example.com")
        .WithFirstName("First")
        .WithLastName("Signer")
        .ChallengedWithQuestions(
            ChallengeBuilder.FirstQuestion("What's your favorite sport?")
                .Answer("golf")
                .SecondQuestion("What music instrument do you play?")
                .Answer("drums")
        )
)
.WithSigner(
    SignerBuilder.NewSignerWithEmail("second.signer@example.com")
        .WithFirstName("Second")
        .WithLastName("Signer")
        .WithSMSSentTo("1234567890")
)

Envoi manuel d'un code SMS

Un nouveau code SMS est généré et envoyé à chaque fois qu'un signataire clique sur le lien de l'email. Si pour une raison quelconque vous devez envoyer manuellement un nouveau code SMS, vous pouvez le faire en utilisant PackageService et en passant les objets PackageId et Signer comme paramètres. Le code suivant le fera ainsi :

eslClient.PackageService.SendSmsToSigner(
    packageId,
    retrievedPackage.GetSigner(email1)
);

Utilisation du KBA

Vous pouvez aussi authentifier un signataire avec KBA. Vous pouvez aussi modifier le bloc signer pour implémenter la KBA. Le code suivant le fera ainsi :

.WithSigner(
    SignerBuilder.NewSignerWithEmail(email1)
        .WithFirstName(FIRST_NAME)
        .WithLastName(LAST_NAME)
        .WithCustomId(signerId)
        .ChallengedWithKnowledgeBasedAuthentication(
            SignerInformationForLexisNexisBuilder.NewSignerInformationForLexisNexis()
                .WithFirstName(FIRST_NAME)
                .WithLastName(LAST_NAME)
                .WithFlatOrApartmentNumber(FLAT_OR_APARTMENT_NUMBER)
                .WithHouseName(HOUSE_NAME)
                .WithHouseNumber(HOUSE_NUMBER)
                .WithCity(CITY)
                .WithState(STATE)
                .WithZip(ZIP)
                .WithSocialSecurityNumber(SOCIAL_SECURITY_NUMBER)
                .WithDateOfBirth(DATE_OF_BIRTH)
                .Build()
        )
)
 .WithDateOfBirth(DATE_OF_BIRTH)
                                        .Build()))

Résultats

Après avoir exécuté votre code, si une transaction est envoyée avec l'authentification du signataire activée, vos signataires devront valider leur identité en utilisant la méthode spécifiée dans la transaction.

Avec l' authentification basée sur les connaissances, l'identité du signataire est vérifiée en lui posant une série de questions sur son rapport de crédit personnel.

Validation du numéro de téléphone SMS

Lors de l'utilisation de l'authentification SMS, le OneSpan Sign évalue le numéro de téléphone fourni dans la charge utile de la requête afin de déterminer comment il doit être interprété et validé. Comprendre ce comportement aide à garantir que les numéros de téléphone sont correctement traités et que les messages d'authentification sont délivrés avec succès.

Si un numéro de téléphone contient exactement 10 chiffres sans signe d'ouverture +, OneSpan Sign suppose automatiquement que le signataire se trouve en Amérique du Nord. Dans ce cas, le code 1 pays est ajouté au numéro avant qu'il ne soit stocké ou retourné dans la charge utile de réponse.

Par exemple :

5551234567 devient 15551234567

Ce comportement ne s'applique que lorsque le chiffre est de 10 chiffres et n'inclut pas de code pays explicite.

Certains pays utilisent également par défaut des numéros de téléphone à 10 chiffres. Si le signataire se trouve en dehors de l'Amérique du Nord mais que son numéro compte toujours 10 chiffres, vous devez inclure un en-tête + dans la charge utile de la requête. Cela garantit que le système ne suppose pas à tort que le numéro appartient au plan de numérotation nord-américain.

Par exemple :

+5551234567

Pour télécharger l'exemple complet de code, consultez notre site de partage de code .

Pour ajouter une couche supplémentaire de sécurité à vos transactions en ligne, OneSpan Sign propose des options d'authentification des destinataires robustes et flexibles. Plus précisément, vous pouvez sélectionner différentes façons de vérifier l'identité du destinataire d'une invitation à une transaction avant qu'il ne soit autorisé à accéder aux documents de la transaction.

L'authentification générale désigne des outils intégrés à OneSpan Sign qui vous permettent de vérifier l'identité du destinataire via SMS, e-mail ou un format personnalisé de questions-réponses.

L'authentification basée sur les connaissances (KBA) dépend d'un fournisseur tiers de KBA pour effectuer l'authentification. Ce prestataire est LexisNexis. .

Les questions KBA sont générées dynamiquement, en fonction des informations contenues dans le rapport de crédit personnel du signataire.

L'authentification KBA peut être utilisée conjointement avec l'une des méthodes générales d'authentification ci-dessus.

Pour permettre l' authentification basée sur les connaissances, veuillez contacter notre équipe de support.

Prétraitement des numéros de téléphone et directives de mise en forme E.164

En plus de la validation du numéro de téléphone SMS décrite ci-dessus, OneSpan Sign utilise également un flux de prétraitement qui aseptifie et standardise toutes les entrées dans le format E.164 reconnu internationalement. Cela garantit que les chiffres sont stockés et retournés dans une structure cohérente à travers toutes les API.

E.164 est la norme mondiale pour la numérotation téléphonique internationale telle que définie par l'Union internationale des télécommunications (UIT). Il définit comment les numéros doivent être structurés afin qu'ils puissent être reconnus et acheminés partout dans le monde. Un numéro de téléphone E.164 comprend :

• Un maximum de 15 chiffres

• Chiffres seulement (0–9)

• Pas d'espaces, de traits d'endroit, de parenthèses ou d'autres séparateurs

• Un point de départ + A pour indiquer un numéro international

OneSpan recommande de soumettre directement les numéros de téléphone au format E.164. Cependant, notre système accepte également plusieurs formats alternatifs saisis par les utilisateurs et les standardise automatiquement. Cela signifie que nous acceptons différentes entrées formatées et les convertissons dans la bonne structure E.164 lors du prétraitement.

Par exemple, nous acceptons des entrées telles que :

(+32) 0470123456

Même si cet exemple inclut des parenthèses et un zéro à l'avant après le code pays, notre prétraitement supprime les caractères non digitaux et le zéro en tête, et les renvoie au format E.164 :

+32470123456

L'utilisation d'un zéro en tête est acceptée par la plupart des pays européens, mais peut ne pas l'être par tous. L'utilisation d'un zéro en tête n'est pas acceptée pour les nombres nord-américains.

L' Get Package API renverra toujours le numéro de téléphone dans ce format standardisé.

+ [Indicatif pays] [Code de destination nationale] [Numéro d'abonné]

Voici quelques exemples de nombres E.164 :

Utilisation de l'authentification générale

Le code ci-dessous vous montre comment créer un objet de rôle pour chaque méthode d'authentification du signataire. Si vous avez besoin d'une comparaison avec la création document-objet de base, ou si c'est la première fois que vous créez un package avec le SDK Apex, consultez ce guide.

 ESignLiveAPIObjects.Role role = new ESignLiveAPIObjects.Role(); 

ESignLiveAPIObjects.AuthChallenge firstChallenge = new ESignLiveAPIObjects.AuthChallenge(
    firstQuestionAnswer, 
    false, 
    firstQuestion
); // Question & Answer

ESignLiveAPIObjects.AuthChallenge secondChallenge = new ESignLiveAPIObjects.AuthChallenge(
    secondQuestionAnswer, 
    false, 
    secondQuestion
); // Question & Answer

ESignLiveAPIObjects.AuthChallenge smsAuthentication = new ESignLiveAPIObjects.AuthChallenge(
    null, 
    false, 
    phoneNumber
); // SMS

Envoi manuel d'un code SMS

Un nouveau code SMS est généré et envoyé à chaque fois qu'un signataire clique sur le lien de l'email. Si pour une raison quelconque vous devez envoyer manuellement un nouveau code SMS, vous pouvez le faire en utilisant la fonction suivante encapsulée dans le Code Share :

 public void sendSmsToSigner(String packageId, String roleId) 

Utilisation du KBA

Vous pouvez aussi authentifier un signataire avec KBA. Vous pouvez utiliser les deux fonctions encapsulées ci-dessous pour créer un rôle, et l'ajouter à une transaction existante. Les deux fonctions sont utilisées séparément pour Equifax USA et Equifax CA :

public void createRoleWithKBA_EquifaxUSA(
    String packageId,
    String roleId,
    String firstName,
    String lastName,
    String email,
    String streetAddress,
    String city,
    String zip,
    String state,
    Integer timeAtAddress,
    String driversLicenseNumber,
    String dateOfBirth,
    String socialSecurityNumber,
    String homePhoneNumber
)

public void createRoleWithKBA_EquifaxCA(
    String packageId,
    String roleId,
    String firstName,
    String lastName,
    String email,
    String streetAddress,
    String city,
    String zip,
    String state,
    Integer timeAtAddress,
    String driversLicenseNumber,
    String dateOfBirth,
    String socialSecurityNumber,
    String homePhoneNumber
)

Résultats

Après avoir exécuté votre code, si une transaction est envoyée avec l'authentification du signataire activée, vos signataires devront valider leur identité en utilisant la méthode spécifiée dans la transaction.

Avec l' authentification basée sur les connaissances, l'identité du signataire est vérifiée en lui posant une série de questions sur son rapport de crédit personnel.