Signature serveur

Goodflag permet à un signataire de signer des documents avec un certificat serveur créé « à la volée » après authentification auprès d’un fournisseur d’identité, ou via un code à usage unique (OTP) envoyé par e-mail ou par SMS. Voici les différents composants impliqués dans la création d’une signature serveur :

• Application demandeuse (requester) : application métier chargée de créer les demandes de signature. Ce composant est hébergé par l’entité demandeuse.
• Request Manager : composant serveur qui héberge les demandes de signature et les documents joints. Ce composant Goodflag doit être hébergé par l’entité demandeuse.
• Page de consentement : application HTML5 qui guide le signataire tout au long du processus de consentement et de la création de la signature. Ce composant Goodflag s’exécute dans le navigateur web du signataire. Il est servi par l’Evidence Manager.
• Evidence Manager : composant serveur qui collecte les preuves de signature. Ce composant Goodflag est hébergé par le fournisseur de signature.
• Serveur Odisia : composant serveur qui héberge la clé cryptographique du signataire. Ce module Goodflag est intégré à l’Evidence Manager.
• Autorité de certification : infrastructure à clés publiques qui délivre le certificat du signataire. Ce composant est hébergé par le fournisseur de signature.
• Fournisseur d’identité : serveur d’autorisation conforme OpenID Connect qui délivre le jeton d’identité du signataire, à partir duquel le certificat du signataire est dérivé. Ce composant est hébergé par l’autorité d’enregistrement.

Voici un schéma simplifié illustrant le flux de signature serveur :

1. Le signataire navigue avec son navigateur web sur l’application demandeuse, où il doit signer des documents.
2. L’application demandeuse initie une demande de signature sur le Request Manager et transmet les documents à signer.
3. L’application demandeuse redirige le signataire vers la page de consentement.
4. Le signataire accède à la page de consentement.
5. La page de consentement récupère auprès du Request Manager la demande de signature et la liste des documents à signer.
6. La page de consentement présente les documents au signataire et lui demande son consentement.
7. La page de consentement identifie le signataire auprès du fournisseur d’identité via le protocole OpenID Connect.
8. La page de consentement génère la clé du signataire sur le serveur Odisia.
9. La page de consentement récupère les DTBS (Data To Be Signed) des documents à signer auprès du Request Manager.
10. La page de consentement demande au serveur Odisia de signer les DTBS, et à l’Evidence Manager de produire le fichier de preuve.
11. La page de consentement transmet le fichier de preuve au Request Manager afin de générer les documents signés de façon asynchrone.
12. La page de consentement redirige le signataire vers l’application demandeuse.
13. Le signataire accède à l’application demandeuse.
14. Une fois les documents signés produits par le Request Manager, l’application demandeuse les récupère.
15. L’application demandeuse récupère le fichier de preuve et l’archive avec les documents signés.

Signature locale

Goodflag permet également à un signataire de signer des documents avec son propre certificat (un token cryptographique, par exemple), en utilisant Odisia desktop sur son ordinateur. Voici les différents composants impliqués dans la création d’une signature locale :

• Application demandeuse (requester) : application métier chargée de créer les demandes de signature. Ce composant est hébergé par l’entité demandeuse.
• Request Manager : composant serveur qui héberge les demandes de signature et les documents joints. Ce composant Goodflag doit être hébergé par l’entité demandeuse.
• Page de consentement : application HTML5 qui guide le signataire tout au long du processus de consentement et de la création de la signature. Ce composant Goodflag s’exécute dans le navigateur web du signataire. Il est servi par l’Evidence Manager.
• Odisia desktop : application native qui accède à la clé cryptographique du signataire pour signer les documents. Ce composant Goodflag s’exécute sur l’ordinateur du signataire.

Voici un schéma simplifié illustrant le flux de signature locale :

1. Le signataire navigue avec son navigateur web sur l’application demandeuse, où il doit signer des documents.
2. L’application demandeuse initie une demande de signature sur le Request Manager et transmet les documents à signer.
3. L’application demandeuse redirige le signataire vers la page de consentement.
4. Le signataire accède à la page de consentement.
5. La page de consentement récupère auprès du Request Manager la demande de signature et la liste des documents à signer.
6. La page de consentement présente les documents au signataire et lui demande son consentement.
7. La page de consentement ouvre Odisia desktop.
8. Odisia desktop demande au signataire de choisir un certificat de signature.
9. Odisia desktop récupère les DTBS des documents à signer auprès du Request Manager.
10. Odisia desktop envoie les DTBS signés à l’Evidence Manager et demande la production du fichier de preuve.
11. Odisia desktop transmet le fichier de preuve au Request Manager afin de générer les documents signés de façon asynchrone.
12. Odisia desktop se ferme.
13. La page de consentement redirige le signataire vers l’application demandeuse.
14. Le signataire accède à l’application demandeuse.
15. Une fois les documents signés produits par le Request Manager, l’application demandeuse les récupère.
16. L’application demandeuse récupère le fichier de preuve et l’archive avec les documents signés.