Affichage des articles dont le libellé est message. Afficher tous les articles
Affichage des articles dont le libellé est message. Afficher tous les articles

mardi 31 juillet 2012

SEPAmail et mon client de messagerie

Puis-je recevoir un contenu SEPAmail dans mon client de messagerie habituel ?


A priori, l'idée est assez naturelle.

Mon client de messagerie (Mail User Agent ou MUA) sait :
  • récupérer et transmettre un courriel à son facteur usuel (Mail Transfert Agent ou MTA)
  • chiffrer/déchiffrer un contenu au format S/MIME
  • afficher un courriel
  • stocker, classer, indexer un contenu SMTP dans un format unitaire ou globalisé
Bref, il sait lire, écrire, stocker, récupérer et transmettre pour envoi une enveloppe SEPAmail.

Que lui manque-t-il alors pour qu'il devienne mon client SEPAmail (Interface Homme Machine IHM) ?


Pas grand chose à vrai dire...

Il faut juste que je puisse :
  • ne voir que l'information utile dans la missive (format xml) et le message (format xml)
  • voir cette information sous une forme lisible
  • être aidé dans la mise en œuvre du protocole SEPAmail, et notamment pour l'acquittement automatique et obligatoire

Comment faire cela simplement ?

Je peux par exemple imaginer installer une extension qui puisse mettre en œuvre les fonction suivantes autour de la missive :
  • affichage à l'utilisateur humain de l'entête de la missive pour les champs importants :
    • horodatage
    • expéditeur
    • destinataire
    • priorité
    • type de missive
  • affichage à l'utilisateur humain du contenu de la missive selon son type
  • possibilité d'acquitter la missive nominale de façon manuelle (voire automatique) avec un code d'acquittement validant au moins la bonne distribution
Je peux aussi imaginer qu'il y ait une extension pour chaque application SEPAmail (RUBIS, GEMME, JADE, ...) qui me fournisse les fonctions suivantes :
  • affichage à l'utilisateur humain du contenu du message selon son type, sous une forme à trouver, à défaut une table de type formulaire
  • affichage des binaires contenus dans le messages sous forme de pièces jointes classiques après vérification antivirale locale
  • possibilité de mettre en œuvre le message suivant s'il existe au sein de la séquence liée à l'application SEPAmail en reprenant les informations du message précédent
En extension de norme, je peux me servir de mon adresse de courriel classique avec mon relais d'acheminement (ma banque ou l'adhérent SEPAmail qui me fournit le service SEPAmail) et il me faudra alors associer à cette adresse de courriel un biclé certifié et insérer les certificats de mon relais d'acheminement.

Quelques petits schémas pour illustrer

exemple d'architecture autour d'un MUA
Voici ce que pourrait être l'architecture applicative autour de mon client de messagerie habituel :
  • trois acteurs :
    • l'adhérent SEPAmail qui fournit le service, par exemple ma banque
    • l'utilisateur SEPAmail qui utilise le service, par exemple, moi, client de ma banque ayant souscrit le service SEPAmail RUBIS
    • mon fournisseur d'accès internet qui m'a également fourni une adresse de courriel et les services de son MTA
  • cinq composants :
    • la plate-forme de l'adhérent, que je ne connais pas et accessible via par des adresses de courriels fournies par l'adhérent
    • le MTA de mon FAI, que j'utilise sans vraiment le savoir en ayant configuré au démarrage mon client de messagerie (configurations smtp et imap/pop)
    • le parefeu de mon réseau (ma Box) ou mon système d'exploitation, configuré le plus souvent nativement pour permettre le passage de courriel
    • mon client de messagerie (MUA) préféré et utilisé qui va accueillir des extensions SEPAmail pour être compatible avec ce service
    • un anti-virus que mon MUA sait appeler si nécessaire, notamment quand une extension SEPAmail extrait une pièce jointe et me l'expose à l'ouverture ou l'exécution
  • trois zones :
    • le SI de l'adhérent SEPAmail, inconnu pour moi
    • internet, également peu connu de moi
    • mon réseau domestique ou de travail, symbolisé sur le schéma par le carré en pointillé autour de mon MUA
Voici ce que pourrait être l'architecture applicative au sein de mon client de messagerie :
  • un composant de cryptographie pour permettre la gestion des certificats avec le coffre-fort de mon système d'exploitation ainsi que la mécanique cryptographique autour du chiffrement et de la signature
  • un composant permettant la vérification d'une authentification sous un protocole type SAPPhire
  • une extension commune autour de la missive
  • des extensions pour chacune des applications SEPAmail que j'ai contractées.
    composants du client de messagerie
     

Que reste-t-il donc à faire pour que cela fonctionne ?

Il faut simplement que des éditeurs développent des extensions pour les clients de messagerie usuels (Outlook, Thunderbird, Mail)...

lundi 18 juin 2012

SEPAmail est une messagerie orientée paiement

Le dispositif SEPAmail est orienté paiement documentaire.
Il permet à deux entités économiques :
  • de s'échanger des documents autour du paiement (devis, facture, demande de règlement, avis de virement, avis de remboursement...)
  • de demander explicitement ou implicitement à sa banque d'enclencher automatiquement un paiement (virement, paiement carte, prélèvement si mandat) 
Nous retrouvons cette orientation avec la plupart des applications SEPAmail : RUBIS, JADE, GEMME, DIAMOND, IOLITE.
Cependant, SEPAmail permet aussi de n'échanger que du document, comme avec JASPE ou AGATE.
Dans ce cas, la banque apporte comme valeur ajoutée son articulation de confiance et son plan d'adressage européen.

Il est donc possible qu'une entité non bancaire devienne adhérent SEPAmail.
Pour cela, il faudrait que l'entité dispose  :
  • de canaux avec ses clients permettant une authentification du niveau minimal demandé par SEPAmail
  • d'un BIC pour pouvoir correspondre avec les autres adhérents SEPAmail
  • d'une infrastructure lui permettant de se connecter au réseau d'adhérents SEPAmail
L'entité pourrait alors opérer facilement des applications non orientées paiement.

vendredi 15 juin 2012

SEPAmail est une messagerie articulée

Les banques disposent de réels atouts pour participer à une messagerie

Les  entités économiques ont des canaux avec leurs banques permettant l'échange d'information avec un excellent degré de confiance.
Entre elles, les banques disposent également de possibilités d'échange d'information avec un excellent degré de confiance.

Si deux entités économiques ne disposent pas d'un canal de confiance entre elles, alors le dispositif SEPAmail permet de le faire en articulant les canaux existants de confiance. La messagerie profite ainsi des bienfaits du modèle 4 coins, que nous avons déjà évoqué.

L'articulation autour d'un relais d'acheminement


Les banques jouent un rôle de relais d'acheminement de messagerie, une véritable articulation permettant des fonctions difficiles à réunir par les entités économiques elles-même.
En effet, ces articulations permettent :
  • de joindre des espaces de confiance
  • de joindre des canaux de messagerie de nature différente, permettant le multi-canal
  • de faire transiter une information dans un espace contractuel permanent
  • de voir les flux transiter et d'apporter de la valeur ajoutée sur ces flux (sécurité, vérification, validation, structuration, enrichissement, stockage, réponse sous mandat)

vendredi 18 mai 2012

Vocabulaire SEPAmail : enveloppe, missive et message

La double encapsulation

SEPAmail met en œuvre une double encapsulation :
  • le message SEPAmail est encapsulé dans une missive SEPAmail
  • la missive SEPAmail est encapsulée dans une enveloppe SEPAmail

Le message SEPAmail

Le message contient le signifiant à échanger entre les utilisateurs SEPAmail expéditeur et destinataire.
Il appartient forcément à un type défini (voir le type MessageType du schéma XML type_sepamail_message.xsd).
Un message est toujours une information structurée dans un format XML selon un schéma XMLSchema publié dans un espace de nom dédié de la communauté SEPAmail.

La missive SEPAmail

La missive SEPAmail sert à :
  • l'adressage,
  • l'identification des destinataire et expéditeur
  • l'acheminement du message et notamment son horodatage
La missive est aussi construite dans un format XML.

La missive respecte toujours la structure suivante :
  • un identifiant
  • un type
  • un ordre
  • une priorité
  • un entête contenant lui même l'adressage
  • l'information à échanger (le message, l'acquittement, la commande, le résultat...) et une signature facultative de cette information si besoin
La missive peut être vue comme le support de toutes les indications d'acheminement de l'information.

L'enveloppe SEPAmail

L'enveloppe SEPAmail garantit :
  • l'authentification du relais d'acheminement,
  • la confidentialité de la missive,
  • le transport de la missive sans révéler son adressage.
Pour cela SEPAmail utilise une enveloppe SMTP+S-MIME comme container de la missive chiffrée, la signature numérique de l'expéditeur, un adressage de type SMTP (par exemple [ecosystem]@[BIC].sepamail.eu) et une priorité.
Ainsi, cette enveloppe peut être envoyée et relayée telle quelle sur le réseau de la messagerie électronique (mode canonique) ou par un service web, même basique (mode flash).

Remarque : il existe aussi une enveloppe fichier afin de permettre le transport de plusieurs missives à la fois au sein d'un système d"information quand il n'y a pas de besoin d'authentification et de confidentialité. Pour bien distinguer ces deux enveloppes, seule l'enveloppe SMTP+S-MIME est appelée enveloppe SEPAmail.

Pour aller plus loin

Nous préciserons dans d'autres billets les différents types de messages et de missives et leurs usages.
Sur ces sujets, nous conseillons la lecture de :

mercredi 16 mai 2012

Vocabulaire SEPAmail : la messagerie SEPAmail, les applications SEPAmail

Il ne faut pas confondre la messagerie SEPAmail et les applications SEPAmail qui utilisent la messagerie SEPAmail.

 

La messagerie SEPAmail

La messagerie SEPAmail est un dispositif permettant à deux entités économiques européennes de s'échanger de l'information de façon sécurisée.
Ce dispositif est mis en place par un réseau d'adhérents, essentiellement des banques européennes.
Il repose sur des standards de l'internet (IP, DNS, SMTP, S/MIME, syslog).
Un modèle en couches (enveloppe/missive/message) est proposé comme standard par la communauté SEPAmail. Ce modèle permet de spécifier de façon assez élégante des règles autour de l'échange, de l'adressage, du routage et de la sécurité.

 

Les applications SEPAmail

Les applications SEPAmail ont des noms de pierres précieuses.
A ce jour, on compte 7 applications :
  • AGATE, la pièce jointe générique
  • DIAMOND, la vérification d'identifiant bancaire
  • GEMME, le mandat de prélèvement
  • IOLITE, la transmission de facture
  • JADE, l'avis de virement
  • JASPE, la signature de document
  • RUBIS, la demande de règlement
Une application SEPAmail utilise la messagerie SEPAmail pour échanger des messages structurés entre les parties dans un dialogue de type question/réponse avec la possibilité de joindre des documents. Comme la banque est un relais de cet échange, elle peut, si le contrat avec son client le précise, enrichir les flux et automatiser des opérations, notamment de paiement (carte, virement, prélèvement).

Avec cette messagerie sécurisée et des applications partagées entre les adhérents SEPAmail, la dématérialisation, l'automatisation et la sécurisation sont beaucoup plus aisées à mettre en œuvre pour les entités économiques.

La mise en place de SEPAmail  dans les relations entre les entités économiques présage ainsi des réductions de coûts très importantes.

 

Pour aller plus loin :