Hoan VU
École Nationale Supérieure des Mines de Saint-Étienne - Thèse pour obtenir le grade de Docteur. Spécialité : Informatique

Politique de confiance dans une transaction de e-commerce

  1. Infrastructure de gestion de la confiance sur Internet
  2. Définitions: Contrôle, Transaction, Authentification et Certificat
  3. La confiance dans les domaines d’application Internet
  4. Risque, Réputation, Recommandation et domaine d’application Internet
  5. Sécurité, Négociation et Gestion de la confiance confiance sur Internet
  6. La gestion de la confiance sur Internet basée sur la politique
  7. Gestion de la confiance au web sémantique basée sur l’expérience
  8. Approches hybrides de la gestion de la confiance sur Internet
  9. Système de négociation de la confiance au web sémantique
  10. Prise en charge du risque pour la gestion de confiance sur Internet
  11. Comparaison des systèmes de gestion de confiance sur Internet
  12. Contraintes pour un système de gestion de la confiance
  13. Modèle global de gestion de la confiance sur Internet
  14. Modèle de confiance de SECURE
  15. Logique temporelle linéaire LTL, Confiance au web
  16. Framework logique pour les systèmes de réputation
  17. Architecture d’un système de gestion de la confiance
  18. Formalisation de la confiance aux applications
  19. Transaction dans le cadre du commerce électronique et la confiance
  20. Évaluation de la contribution d’un utilisateur à Wikipédia
  21. La notion de négociation, Modèle de la négociation de la confiance
  22. Architecture du système de négociation de la confiance
  23. Protocole de négociation, Système de négociation de la confiance
  24. Module de négociation de la confiance
  25. Transaction de e-commerce et Tiers de confiance pour le paiement
  26. Politique de confiance dans une transaction de e-commerce
  27. La gestion de la Stratégie de Négociation – Transaction en ligne
  28. Processus de gestion du risque, Système de gestion de la confiance
  29. Modèle du risque risque et le système de gestion de la confiance
  30. Politique du tiers de paiement, Transaction de commerce électronique
  31. Prototype de négociation de la confiance : Architecture
  32. Politique de confiance: Spécification de la politique en XML
  33. Réalisation du module de vérification de la politique de sécurité
  34. Le système de gestion de la confiance au web

6.5.3 Observations et structures d’événements
Nous proposons dans cette section un modèle d’observation de la transaction. Celuici est décrit par la structure d’événements définie par chacune des entités, le vendeur et l’acheteur. Nous précisons que le modèle d’observation de chaque entité lui est propre et dépend de la structure d’événements qu’il a choisie. Nous présentons la structure d’événements de l’acheteur dans la figure 6.7 et celle du vendeur figure 6.8.
Acheteur : Structure d’événements
Fig. 6.7 Acheteur : Structure d’événements
La structure d’événements de chaque entité décrit les relations de conflit et de causalité que doivent respecter les événements. Les points suivants présentent des explications détaillées sur chacun des événements de la structure d’événements de l’acheteur et du vendeur.
Vendeur : Structure d’événements
Fig. 6.8 Vendeur : Structure d’événements
Acheteur : structure d’événements
La spécification des événements de la structure d’événements de l’acheteur est donnée ci-dessous.
-object_request : événement local indiquant que l’acheteur passe une commande à un vendeur.
-object_received : indique qu’il reçoit un message contenant une confirmation du paiement et un plan d’envoi du produit de la part du vendeur.
-obj_time_out : indique qu’il n’a reçu aucune information du vendeur après avoir passé sa commande.
-high_risk, average_risk, low_risk : événements locaux qui décrivent le niveau de risque de la transaction (élevé, moyen ou faible). Ces événements sont déterminés par le risk manager qui sera présenté dans le chapitre 7. Ce composant utilise les informations disponibles sur la transaction (coût total, probabilité d’échec. . . ) pour évaluer le niveau de risque.
-positive, neutral, negative : évaluation de la qualité de la transaction par le client.
-payment_request : l’événement qui indique que le vendeur a envoyé une demande de paiement suite à la commande.
-pay_direct : événement qui indique que le paiement est effectué directement (carte bancaire, argent liquide…). Cet événement fait suite à la demande de paiement du vendeur.
-pay_TTP : événement qui indique que le paiement est effectué en ayant recours aux services d’un tiers de confiance.
-pay_ignore : indique qu’il ignore la demande de paiement du vendeur.
-pay_confirm : indique qu’il confirme le paiement auprès du tiers de confiance.
-pay_confirm_req : l’événement qui indique que le vendeur demande une confirmation de paiement
-pay_cancel : indique que le vendeur ne valide pas son paiement auprès du tiers de confiance.
À partir de cet ensemble d’événements et l’objectif du client, nous pouvons trouver que l’événement qui spécifie l’objectif du client dans la structure d’événements est object_received.
Vendeur : structure d’événements
Nous trouvons ci-dessous la spécification de la structure d’événements du vendeur.
-object_order : indique que le vendeur reçoit une commande d’un acheteur.
-object_send : événement qui indique que le vendeur a envoyé le produit à l’acheteur.
-order_ignore : événement local qui indique que le vendeur ignore la commande du client. Cela peut survenir dans le cas d’une commande invalide ou dans le cas d’un client considéré comme étant un escroc, un voleur…
-ask_payment : l’événement indiquant que le vendeur réclame le paiement de la commande à l’acheteur.
-payment_received : indique que le vendeur a reçu le paiement de l’acheteur par la méthode de paiement direct.
-payment_TTP_received : indique que le vendeur a reçu le paiement avec la méthode de paiement par du tiers de paiement.
-pay_TTP_notified : indique que qu le vendeur reçoit une notification de paiement par un tiers de confiance.
-payment_time_out : indique qu’il n’a toujours pas reçu de paiement après un délai fixé.
-Les autres événements ont la même sémantique que ceux décrits pour la structure d’événements de l’acheteur.
-ask_pay_confirm : l’événement indiquant que le vendeur demande une confirmation de paiement l’acheteur.
À partir de cet ensemble d’événements et de l’objectif du vendeur, nous voyons que les événements d’objectif du vendeur dans la structure d’événements sont payment_received et payement_TTP_received.
6.5.4 Politique de confiance
Grâce à sa structure d’événements, chaque entité qui participe à la transaction (vendeur et acheteur) peut construire sa propre politique de confiance. Cette politique lui permet de vérifier que, à chaque étape, la négociation se déroule en satisfaisant correctement sa politique. La politique est exprimée sous la forme d’une formule logique PP-LTL qui décrit le comportement attendu tout au long de la transaction.
Politique de l’acheteur
La politique que l’acheteur met en place tend à minimiser les risques qu’il prend. Il refuse de prendre des risques avec les gens qu’il ne connaît pas, si les pertes financières possibles sont trop conséquentes ou s’il a déjà eu des problèmes avec le vendeur.
Avec la structure d’événements du client présentée par la figure 6.7, nous constatons que le client peut éviter deux conséquences risquées qui peuvent survenir s’il effectue le paiement après la demande du vendeur :
-la conséquence pay_direct → obj_time_out indique que le client a payé par un règlement direct mais que le vendeur n’a pas envoyé le produit;
-la conséquence pay_T T P → obj_time_out indique que le client a payé par l’intermédiaire d’un service de confiance mais que le vendeur n’a pas envoyé le produit.
Pour éviter cela, en tenant compte des informations liées aux risques et à l’historique des transactions, le client peut proposer les politiques suivantes pour éviter de voir apparaitre ces conséquences lors de la négociation.
-Lorsqu’il reçoit une demande de paiement du vendeur, le client n’effectue pas de paiement direct s’il trouve que dans ses transactions antérieures avec ce vendeur il y a déjà eu pay_direct → obj_time_out, ou si le risque lié à la transaction est elevé.
ψ1 : pay_direct =⇒ ¬(payment_request∧
high_risk ∧ F −1 (pay_direct ∧ obj_time_out))
-Lorsque le risque est bas, ou lorsque le risque est moyen et que dans le passé il
n’y a jamais eu pay_direct → obj_time_out, le client n’utilise pas les services du tiers de confiance.
ψ2 : pay_T T P =⇒ payment_request ∧ [low_risk
∨(average_risk ∧ G−1 (pay_direct ∧ obj_time_out)]
La politique globale de l’acheteur serait alors : ψA ≡ ψ1 ∧ ψ2 .
Politique du vendeur
De la même manière, le vendeur veut se protéger des acheteurs indélicats et minimiser ses risques de pertes financières. Nous utilisons la structure d’événements pour spécifier d’abord les conséquences à risque pour le vendeur.
Dans l’arbre des transitions, nous voyons que le vendeur a intérêt à éviter les conséquences qui contiennent les chaînes suivantes :
-object_send → T T P _time_out : le client a payé par un tiers de confiance, le vendeur a envoyé le produit mais il n’y a jamais eu de confirmation du paiement.
-object_send → pay_time_out : le vendeur a envoyé le produit avant de demander un paiement au client et le client ne le paie pas.
-ask_pay_conf irm → T T P _time_out : le vendeur a envoyé le produit avant d’avoir le paiement; le client a payé par le tiers de confiance mais ne confirme jamais le paiement.
-obj_order → ignore_cmd : cas où le vendeur reçoit des commandes de clients considérés comme indélicats.
En utilisant les informations de risque et l’historique, le vendeur peut proposer les politiques suivantes pour éviter ces situations :
-Le vendeur n’accepte pas les commandes de la part de clients qu’il a évalués de manière négative dans le passé. ψ1 : G−1 (negative) =⇒ obj_order ∧ ignore_cmd
-Si le vendeur accepte d’envoyer le produit au client avant d’en avoir le paiement, il envoie en même temps la demande de paiement. ψ2 : (object_order ∧ object_send) =⇒ ask_payment
-Le vendeur envoie le produit au client avant de demander un paiement seulement dans le cas où les risques sont faibles et s’il n’y a pas eu d’évaluation négative sur une transaction avec ce client. ψ3 : object_send =⇒ [low_risk ∧ F −1(negative)]
-Le vendeur n’accepte que le mode de paiement par un tiers de confiance si les risques sont élevés et si dans le passé, il n’a pas eu de problème de paiement après l’envoi du produit.
ψ4 : [high_risk ∧ F −1 (object_send ∧ pay_cancel)]
=⇒ T T P _notif ied
La politique globale du vendeur est donc : ψ ≡ ψ1 ∧ ψ2 ∧ ψ3 ∧ ψ4 .
Lire le mémoire complet ==> (Infrastructure de gestion de la confiance sur Internet )
Thèse pour obtenir le grade de Docteur – Spécialité : Informatique
École Nationale Supérieure des Mines de Saint-Étienne

Cliquez sur suivant article pour lire la suivante partie de ce mémoire:

Abonnez-vous!
Inscrivez-vous gratuitement à la Newsletter et accédez à des milliers des mémoires de fin d’études !
Publier son mémoire!
WikiMemoires - Publier son mémoire de fin d’études !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *