Les extensions futures

Cette page est à l'état de discussion.

Elle n'a donc aucune valeur normative, et pourrait même disparaître du périmètre de SEPAmail.

Si vous voulez contribuer, utilisez la page de discussion SVP. Consultez également les autres pages en discussion.

Les principes initiaux de SEPAmail permettent de satisfaire les besoins de nombreux cas d'usage. Cependant deux évolutions paraissent nécessaires dans une version proche.

Services aux communautés Internet

Une communauté Internet (Linkedin, e-Bay, FaceBook,...) permet de rassembler des personnes sur des activités partagées sur une base de confiance auto-définie. Par exemple, le nombre d'étoile d'un vendeur/acheteur e-Bay permet une appréciation par une tierce personne. Cependant il est nécessaire de recourir, de temps en temps, à des mécanismes plus objectifs de confiance, en particulier lorsqu'il s'agit de paiement. Dans ce cas, l’utilisation d'un moyen de paiement reconnu classique (carte de paiement) ou dédié (Paypal pour e-Bay) permet de satisfaire le besoin.

Cependant, lorsque les moyens de paiement proposés ne suffisent pas : mandats de prélèvement, devis (le paiement interviendra plus tard), il est nécessaire de recourir à d'autres systèmes. Dans ce cas, la communauté est très vigilante à ce que ces systèmes ne brisent pas, au travers de leur utilisation, la logique communautaire.

SEPAmail proposera une approche complémentaire permettant de satisfaire à ces besoins et contraintes.

Sur ce schéma les flux en noirs correspondent à la vision actuelle de SEPAmail.

1. l'émetteur initial réalise une activation dans sa communauté. Par exemple, la finalisation d'une enchère déclenche une activation initiale pour une demande de règlement RUBIS par le vendeur.
2. la communauté envoie à sa banque avec les éléments nécessaires pour un routage vers la banque de l'émetteur. ce dernier aura au préalable inscrit son QXBAN dans son compte de communauté.
3. la banque de la communauté routera l'envoi (puce 3) vers la banque de l'émetteur.
4. l'émetteur initial reçoit donc une proposition d’initialisation qu'il lui suffit de valider, avec les moyens et sur le canal proposés par sa banque, pour revenir dans un schéma SEPAmail classique. Dans notre exemple, une demande de règlement avec tous les éléments contractuels saisis au moment de la mise en enchère.
5. pour éviter tant la désintermédiation de la communauté qu'une mauvaise ergonomie pour l'utilisateur, SEPAmail aura identifié la nécessité de faire une copie (puce 5) des messages vers la banque de la communauté. Ainsi l'émetteur initial et le destinataire pourront voir l'avancement des échanges complet sur leur communauté.

Un tel mécanisme renforce au passage les mécanismes de confiance déjà mis en place au niveau de la communauté.

HURRA, un récépissé signé

HURRA pour Human Readable Receipt Attachment, est un mécanisme qui offre un récepissé de type PDF signé et horodaté par la banque dés lors que l'utilisateur réalise un envoi tant pour l'initialisation que pour la validation.

Le but est de permettre à un utilisateur qu'il a bien réaliser la transaction mais indépendamment du système SEPAmail. Par analogie, la déclaration des impôts sur Internet permet l'enregistrement en PDF (ou impression) sur son disque dur d'un récépissé utilisable pour prouver facilement sa déclaration.

Dans un tel mécanisme, il est important que :

• l'émetteur puisse s'affranchir du système SEPAmail. En effet un tel récépissé n'est utile que s'il y a eu un dysfonctionnement du système.
• le destinataire puisse contrôler le récépissé hors du système SEPAmail.

Les grands principes de ce récepissé sont donc :

• l'utilisation de PDF signé et horodaté par la banque de l'émetteur
• la capacité pour tout utilisateur externe de pouvoir vérifier les éléments de ce récépissé. En première analyse, la norme 2D-DOC permet de répondre à ce besoin.