L'application JADE, le retour

Bien que la SMIRK de l'application JADE ait été rédigée et publiée depuis longtemps déjà, elle n'a pas encore été "officiellement" validée, et n'est à ma connaissance implémentée nulle part.

Il me semble toutefois intéressant de revenir sur le contenu de cette application -- telle qu'elle est définie dans cette SMIRK du moins -- sous forme d'une série de questions-réponses.

JADE, qu'est-ce que c'est ?

JADE est avant tout un avis d'ordre de paiement. Nous sommes donc dans le cas où une entité, dénommée donneur d'ordre, doit verser une somme d'argent à une autre entité, dénommée bénéficiaire. Plutôt que d'envoyer simplement un ordre de virement à sa banque (sous forme d'un message pain.001 par exemple), le donneur d'ordre peut choisir de lui envoyer un message CreditAdvise de l'application JADE.

Il se passe alors deux choses :

• dans tous les cas, le bénéficiaire est avisé du paiement, il dispose des références exactes et éventuellement des documents associés ; son accord peut être sollicité.
• selon les accords entre le donneur d'ordre et sa banque, et le type de message JADE envoyé, le paiement peut être déclenché automatiquement

Les premiers travaux sur JADE ont été menés en commun avec des factors, mais la complexité des informations devant être acheminées par les factors, ainsi que la multiplicité des intervenants, nous a conduits à préférer définir une application JADE simple, facile à comprendre et utilisable par tous.

Dans le cas simple, comment ça marche ?

Dans le premier cas d'usage, que l'on pourrait qualifier de "basique", le donneur d'ordre n'attend pas de réponse du bénéficiaire : l'employeur virant un salaire, la CAF versant une prestation... n'ont pas besoin de réponse extra-bancaire.

Il n'y a alors qu'un seul message transmis : CreditAdvise. Celui-ci peut être transmis à trois moments :

1. après le paiement : "je vous ai versé, tel jour, telle somme sous telle référence".
2. simultanément au paiement : "je vous verse ce jour ..."
3. avant le paiement : "je vous verserai, tel jour ..."

Dans les cas 2 et 3, des accords entre le donneur d'ordre et sa banque peuvent déclencher l'émission automatique du paiement, conformément au message pain.001 inclus dans le CreditAdvise. Pour le cas 1, il serait imaginable que la banque du donneur d'ordre réalise d'abord le virement, et ne transmette le message JADE qu'ultérieurement, mais ceci implique un format de communication entre la banque et son client (contenu + canal) qui dépasse le cadre de SEPAmail.

Et maintenant, si j'ai besoin d'un accord du bénéficiaire ?

Ici, le cas d'usage est différent : le donneur d'ordre veut absolument un accord du bénéficiaire avant de lui verser les sommes, par exemple :

• solde de tout compte moyennant signature du reçu
• allocation nécessitant une attestation sur l'honneur

Dans ce cas, les deux messages JADE sont mis en jeu :

• CreditAdvise indique les éléments du règlement (date, montant...), fournit des pièces justificatives, et indique la forme de l'accord (voir ci-dessous)
• CreditReply fournit la réponse du bénéficiaire

Lorsque le bénéficiaire donne une réponse positive, en d'autres termes accepte l'accord qui lui est proposé, le virement doit être automatiquement déclenché, sans qu'une nouvelle intervention du donneur d'ordre soit nécessaire. ATTENTION : ceci dépend évidemment des accords entre le donneur d'ordre et sa banque ! Il y a donc un point à prendre en compte lors de la construction d'une offre commerciale autour de ce service : pour que JADE avec réponse ait du sens, et présente une vraie plus-value pour le bénéficiaire, celui-ci doit pouvoir être certain que son accord entraînera bien le versement des sommes proposées.

Quand les sommes sont-elles versées ?

Dans le cas simple, les sommes sont versées selon la date figurant dans le pain.001, si l'accord entre le donneur d'ordre et sa banque le prévoit bien sûr.

Dans le cas à deux messages maintenant, le sujet devient un peu délicat et mérite une explication détaillée : le message CreditAdvise comporte deux dates :

1. dans le pain.001, la date d'exécution souhaitée par le donneur d'ordre
2. hors pain.001, la date limite d'accord du bénéficiaire

Les règles suivantes doivent alors s'appliquer :

• Si l'accord du bénéficiaire est reçu avant la date 1, le paiement interviendra à la date 1.
• S'il est reçu après la date 1 mais avant la date 2, le paiement interviendra au plus vite
• S'il est reçu après la date 2, aucun paiement ne doit être déclenché. Le processus est alors considéré comme abandonné, le donneur d'ordre ayant alors pu lancer une autre procédure.

Quel accord peut-on demander au bénéficiaire ?

L'accord demandé par le donneur d'ordre peut actuellement revêtir deux formes:

1. une simple authentification -- dans ce cas, le fait que le bénéficiaire se soit authentifié pour accepter le virement est considéré comme suffisant
2. un scellement -- dans ce cas, le bénéficiaire doit disposer d'une signature électronique lui permettant de signer effectivement un texte ou un document.

Le donneur d'ordre choisit la forme de l'accord demandé. Si la banque du destinataire ne supporte pas cette forme (typiquement, elle ne fournit pas de certificats donc la forme 2 est impossible), elle répondra par un CreditReply négatif dit "technique". S'il le souhaite, le donneur d'ordre pourra alors envoyer un nouveau message CreditAdvise en demandant une autre forme d'accord.

Avez-vous quelque chose à ajouter pour votre défense ?

Un cas d'usage particulier n'a pas été abordé ici : celui d'un paiement sur QXBAN. Il sera traité dans un article séparé.

En aucun cas les messages de JADE ne représentent une garantie de paiement. Il reste de la responsabilité du bénéficiaire de s'assurer que les sommes lui sont bien parvenues, tout litige restant strictement entre le donneur d'ordre et lui.

JADE est aujourd'hui définie pour les virements, mais tout a été prévu pour qu'elle puisse s'articuler sur d'autres formes de paiements : chèque ou lettre-chèque, carte bancaire. Les champs sont en place pour ceci, il ne manque réellement que l'articulation du paiement -- et un besoin métier avéré.

Le but de JADE n'est pas d'acheminer des documents. Toutefois, elle en transporte, donc il est possible de l'utiliser pour envoyer des bulletins de salaire par exemple. Pour que ceci réponde aux obligations légales, il faut bien sûr que les documents transportés répondent aux normes en vigueur (PDF signés, par exemple). Ceci doit être considéré comme un effet de bord de l'application, dont l'usage est malgré tout à éviter.

Et en conclusion ?

JADE est aujourd'hui une application simple, facile à expliquer, facile à mettre en œuvre. De plus, tous les formats du message pain.001 sont supportés, ce qui permet de l'inclure dans tous les SI existants sans modification profonde.

En revanche, elle ne répond pas forcément aux cas d'usage les plus complexes. Comme pour toues les autres applications SEPAmail, l'apparition de nouveaux cas complexes justifieront certainement l'évolution de JADE vers une version 2.

Revue de presse Août-Septembre

Voici quelques articles sur SEPAmail publiés en aout et septembre 2014 :

• SEPAmail, facilitez vos échanges avec Citizen Can
• eDefact, la dématérialisation de facture proposée par le CMCIC au moyen de SEPAmail
• Le règlement SEPAmail (RUBIS) est présenté par UTSIT et CMCIC un peu partout en France, par exemple à Aix, à Lyon
• Axway présente au mois d'octobre son service autour de SEPAmail
• La caisse d'épargne présente son service SEPAmail Creancier

Côté nouvelles interne à la communauté SEPAmail, le comité norme étudie et commente l'application JADE, autour de l'avis d'ordre de réglement et fait quelques retouches sur l'application DIAMOND, autour de la fiabilisation d'identifiants bancaires (notamment l'IBAN)

Revue de presse Juin-Juillet 2014

Quelques articles cet été sur SEPAmail, annonçant la mise en service pour les clients.

• 25/07/2014 Les échos Une norme propice aux solutions bancaires de place
• 12/06/2014 GFI  Comment supprimer la fraude de signature au contrat
• 12/05/2014 Syrtals le règlement de facture, l'avenir de SEPAmail
• 28/07/2014 Banques en lignes Izly transporte des flux SEPAmail
• juillet 2014 Google Play Mon portefeuille BNP Paribas, première application android permettant le règlement via SEPAmail

Bon été

Se former à SEPAmail

Je reçois assez souvent des questions autour de "comment se former à SEPAmail ?".

Je propose alors d'intervenir dans les entreprises qui le souhaitent avec une offre variant de 1/2 journée à 3 jours et sur des sujets variés :

• SEPAmail, les enjeux (1/2 journée)
• SEPAmail pour les éditeurs (2 jours)
• revue détaillée de RUBIS@SEPAmail (3 jours)
• rédiger une SMIRK (1/2 journée)

J'utilise le logiciel open source scenari (et sa chaine éditoriale Opale) pour produire un livret et une présentation cohérente et évolutive.

Je ne connais pas encore d'autre offre de formation dédiée à SEPAmail, même si quelques formations SEPA parlent de SEPAmail.
Cela est du, il me semble, au nombre de sachants encore peu nombreux.

Mais gageons que 2014/2015 verra de nombreuses offres éclorent, offres que nous pourrions relayer dans ce blog.

En attendant, je vous propose en ligne une mini-formation intitulée "SEPAmail en 20 minutes", inspirée de mon billet de janvier 2013.

FAQ n°6

Q6.1 : Renvoi, doit-on changer la date ?

La question peut se poser ainsi : si je renvoie une missive comme cela est possible, est-ce que je change la date ?

Une réponse rapide est : NON, on ne change que l'ordre quand on renvoie une missive, en l'incrémentant de un.

Voici une explication détaillée de cette réponse rapide :

On trouve la règle à appliquer dans la directive d'implémentation de la missive :
""If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent. All other missive fields, including MsvId and SndDtTm, must be unchanged."

Quel est le sens de cette règle ?

Pour le comprendre, il faut une petite explication :

• Le message SEPAmail, c'est le signifiant échangé entre les utilisateurs
• La missive SEPAmail, c'est l'enveloppe de messagerie du réseau privé SEPAmail
• L'enveloppe SEPAmail, c'est l'enveloppe de sécurité en cas de transport (mode flash ou canonique) sur un réseau public.

Le protocole SEPAmail, c'est un protocole qui permet :

• cette double encapsulation,
• une authentification des parties par les relais,
• un accusé de réception par l'adhérent pour le compte de son utilisateur, quelque soit le cas d'usage (l'application, le nombre d'acteurs...)
• une forme de "garantie" pour un utilisateur émetteur que son envoi sera acquittée (renvoi, escalade, acquittement obligatoire 24/24 7/7 par l'adhérent récepteur selon la priorité)

Renvoyer une missive, ce n'est pas obligatoire mais une possibilité, offerte si le système émetteur chez l'adhérent considère que l'acquittement des envois précédent pour la même missive n'est pas arrivé.

Par contre, acquitter une missive, c'est obligatoire.

Quand l'émetteur renvoie une missive, voilà ce qu'il dit à son récepteur de missive : "je vous ai déjà émis une missive pour telle personne à telle heure. Comme mon système n'a pas encore enregistré d'accusé réception et que j'ai besoin de cet accusé de réception, je vous renvoie, comme j'en ai la possibilité, la même missive. Pour vous signifier que c'est un renvoi, j'incrémente de 1 l'ordre de la missive. Merci de m'acquitter, comme vous en êtes obligé en tant qu'adhérent, cette missive et les précédentes, si vous les avez reçues."

Quand on raisonne sur ces sujets, il faut absolument ne pas vouloir connaître le statut précis ou le comportement précis de son interlocuteur; mais appliquer le protocole de son point de vue.

Celui qui spécifie le composant qui envoie et reçoit les missives des parties, doit, bien entendu imaginer tous les cas, dont celui pour lequel la contrepartie essaie de frauder ou pour lequel la contrepartie a un système défaillant. Des systèmes de régulation de ces comportements sont présents dans SEPAmail et dépasse le simple cadre de l'acquittement des missives. Pour mémoire, ce sont l'engagement contractuel des adhérents, le procédé d'escalade, la surveillance du réseau par SEPAmail.eu.

Q6.2 :  Pourquoi y a-t-il Acquittement et Aknowledgement dans les types de missives ?

Les schémas XML autour de SEPAmail sont écrits en anglais, pour pouvoir être lus par tous. Les types de missives étaient écrits en français, ce qui ne posait pas de problème pour Service, Nominal et SMAPI qui sont équivalents en anglais mais ce n'est pas le cas pour Acquittement.

En 2010, le committer a donc accepté ma demande de transformer Acquittement en Aknowledgment, tout en conservant Acquittement à des fins de rétro-comptabilité. Les deux termes sont donc équivalents, comme annoncé dans la directive d'implémentation de la missive.

La règle implicite est donc la suivante :

Tout composant mettant en œuvre le standard SEPAmail DOIT accepter en réception les types Acquittement et Aknowledgment.

Mon conseil est de rajouter :

Tout composant mettant en oeuvre le standard SEPAmail DEVRAIT utiliser en émission le type Aknowledgment.

Q6.3 Où peut-on trouver des exemples de flux ?

Cette question revient souvent; elle est tout à fait licite.

J'ai créé en 2013 un espace communautaire pour partager nos exemples.

Il se trouve sur la plateforme google code et a pour petit nom SMITE : SEPAmail I want TEst !

L'espace pourrait être augmenté de nos exemples.

Le problème de chacun est de savoir si son exemple est bien conforme à:

•  les schémas XML
•  les directives d'implémentation
•  les règles opérationnelles entre les adhérents

Pour le premier point, c'est facile puisque tous les outils existent et les schémas sont publiés et stables.

Pour le deuxième point, les directives d'implémentation sont publiées mais certaines règles semblent être encore porteuses d’ambiguïté. La démarche est donc de demander au comitter SEPAmail via l'espace communautaire son avis, soit en direct, soit par la fonctionnalité discuter du wiki.

Pour le troisième point, c'est plus compliqué car ces règles ne sont pas publiées. Pour les avoir consultées, je peux vous assurer qu'il n'y a peu de règles qui touchent aux flux messages ou missive dedans (la taille maximale des flux acceptée pour le moment) mais plus des règles pour connecter entre elles les infrastructures et piloter la mise en production après expérimentation.

Je propose à tous ceux qui souhaitent partager leurs exemples de les aider dans leur démarche. N'hésitez pas à me contacter.

Ces pages sont également ouvertes pour ceux qui désirent partager un billet sur ces sujets.

Je souhaite que nous ne faisions pas comme d'autres communautés à écrire les règles sans partager des exemples qui facilitent leur compréhension.

Q6.4 SEPAmail et RUBIS, c'est la même chose ?

SEPAmail est une messagerie sécurisée fournie par des adhérents SEPAmail à leurs clients ou leurs agents, ceux que l'on appelle des utilisateurs SEPAmail.

RUBIS, comme GEMME, JADE, DIAMOND, sont des applications de SEPAmail qui répondent à un besoin précis des utilisateurs.

Donc, SEPAmail et RUBIS ne sont pas la même chose. Les utilisateurs ne devraient pas entendre parler de RUBIS puisque les cinq adhérents actuels se sont entendus sur la notion de "règlement (via) SEPAmail" pour parler de RUBIS. RUBIS reste un nom de code interne à la communauté SEPAmail.

Q6.5 Quelle est la limite en taille d'un message, d'une missive, d'une enveloppe ?

C'est l'une des exceptions à ce que j'ai dit plus haut. La limite a été fixée dans les règles opérationnelles et elle est de 200kos pour l'enveloppe SEPAmail, c'est à dire trop peu. En effet, comme un fichier pdf (par exemple une facture) est encapsulé dans un message SEPAmail, puis une missive SEPAmail et enfin une enveloppe SEPAmail.

Q6.6 SEPAmail, c'est une norme, un standard, un protocole ?

SEPAmail est un protocole, puisqu'il précise un ensemble de règles pour des acteurs qui cherchent à organiser entre eux une fonctionnalité.

Les français distinguent la norme du standard : la norme est un texte normalisé par un organisme de normalisation reconnue (ou officiel). Le standard est un texte utilisé par une communauté.

Si on reconnait SEPAmail.eu comme un organisme de normalisation officiel, alors SEPAmail est une norme. Ce n'est à mon avis pas encore le cas.

Il existe aujourd'hui une communauté de fait autour de SEPAmail, c'est donc bien un standard de fait.

Q6.7 Quel est le statut de votre blog et de vos réponses ? Puis-je m'y fier ?

Notre blog (nous sommes pour le moment deux rédacteurs) se veut un point de rassemblement de ceux qui participent à la communauté SEPAmail (les lecteurs) et de ceux qui veulent partager des points de vues et des informations sur SEPAmail (les rédacteurs, les interviewés...).

Le blog n'est pas le blog officiel de SEPAmail.eu.

Les éclairages amenés n'engagent donc pas SEPAmail.eu et n'engagent, d'une manière générale, que leur auteur.

Il n'y a pas de comité de validation des billets rédigés.

Comme le blog est lu et (de temps en temps) commenté, vous pouvez, à mon sens, vous fier à ce qui est écrit et vous forger une opinion sur son contenu.

Les deux auteurs sont :

• Olivier Jousselin, comitter du standard de 2009 à 2013, rédacteur de la SMIRK Jade en 2013
• Manfred Olm, co-auteur du premier draft en 2008, de quelques SMIRKs en 2011 et 2012, missionné de 2010 à 2012 pour réaliser le contrôle de cohérence entre le standard et les expérimentations ayant été réalisées.

Nous partageons ainsi avec vous le plaisir que vous avez, nous l'espérons.

FAQ n°5

Q5.1 : RUBIS : Combien de décimales sont autorisées dans le montant à payer ?

Le montant se trouve, dans la requête RUBIS (message ActivationRequest), dans le fragment xml Amt (xpath /sem:ActivationRequest/sem:ReqCompl/sem:Request/pain013:PmtInf/pain013:CdtTrfTx/pain013:Amt/pain013:InstdAmt).
Selon le shema XML du pain013, le montant est un nombre décimal positif qui peut avoir 5 décimales au plus.
Selon la directive d'implémentation RUBIS du message ActivationRequest, le montant ne peut pas être nul.
Le montant minimum est donc 0.00001 et un message avec ce montant valide bien le schéma XML du message.

Ce nombre de décimales permet d'effectuer la conversion entres les différentes devises sans ambigüité sur la deuxième décimale. C'est la règle générale qui a été adoptée en Europe au moment du passage des monnaies nationales à l'euro. Elle parait donc adaptée à l'univers SEPAmail et à la zone SEPA en particulier.

L'EPC a précisé pour le pacs.008 puis le pain.001 une règle plus contraignante qui peut se résumer à "Format rule: The fractional part has a maximum of two digits". On retrouve cette règle par exemple pour l'échange de pain.001 entre une banque et son client (référence IG SCT Bank-Client v7.0, Instructed Amount AT-04).

Certains guides du CFONB reprennent la règle ISO (5 décimales) ou la règle EPC (2 décimales).

La question est donc bien licite pour RUBIS.

Concernant une demande de règlement, quel est le sens de payer un montant avec 5 décimales ?
Dans la plupart des usages proposés par RUBIS, cela n'a aucun sens, donc une règle d'au plus 2 décimales aurait du sens.
D'un autre côté, Rubis ne propose que la demande de règlement et non le règlement lui-même, qui est articulé par la banque de débiteur selon le contrat qu'elle a avec le débiteur. Les cas d'usage qui ont été relevés lors du passage à l'euro, peuvent toujours donc se dérouler avec RUBIS.

Il parait raisonnable donc, pour pouvoir s'articuler avec un règlement par virement et être compatible avec les règles EPC d'implémenter à minima les règles suivantes :

• un créancier DEVRAIT utiliser des montants avec au plus deux décimales s'il n'a pas besoin de conversion
• l'adhérent du débiteur DOIT arrondir à deux décimales selon les règles d'usage des arrondis dans le monde bancaire tout montant émanant d'une demande de règlement avec plus de deux décimales avant d'initier un règlement par virement (pacs.008 ou pain.001)

Q5.2 : Comment doit réagir un adhérent si une missive n'est pas adressée à un de ces clients ou l'émetteur n'est pas chez l'adhérent qui envoie la missive ?

Le cas est simple et se présente de temps à autre.
L'adhérent émetteur de la missive envoie à un adhérent une enveloppe SEPAmail correcte contenant une missive dont :

• l'expéditeur (balise Snd) n'est pas un QXBAN de l'émetteur (mauvais BIC)
• le destinataire (balise Rcv) n'est pas un QXBAN du récepteur (mauvais BIC)

La missive peut donc être acquittée puisqu'elle est valide et lue correctement.

En version 1206, le relai entre les adhérents n'est pas autorisé.

• Conséquence 1 : l'adhérent qui reçoit la missive NE DOIT PAS  la relayer.
• Conséquence 2 : L'adhérent qui a envoyé la missive NE DEVAIT PAS la relayer également.

L'acquittement est donc négatif (NAK).
Le code retour peut être utilisé; c'est 511 pour le premier cas (mauvais Snd) et 512 pour le second (mauvais Rcv)

Q5.3 : peut-on envoyer une missive d'ordre 0 ?

Le schéma XML de la missive (voir ici) décrit une balise MsvOrd comme un entier.
Par contre, la directive d'implémentation de la missive donne explicitement l'usage de cette balise : "Usage Rule : this field must be set to 1 (one) at first sending of a given missive. If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent. All other missive fields, including MsvId and SndDtTm, must be unchanged.
Usage Rule: for an acknowledgement missive, the order number will be the one of the missive it acknowledges."

On commence à un et on incrémente de un à chaque renvoi.
On acquite une missive avec le même ordre que la missive nominale acquittée.

Que faire alors si on reçoit une missive nominale d'ordre 0 ?
On acquitte négativement (NAK) avec un code retour 584 ( Order number error).

Mais que faire pour l'ordre de la missive d'acquittement puisqu'il est dit : "Usage Rule: for an acknowledgement missive, the order number will be the one of the missive it acknowledges." ?

Quitte à être non conforme à la directive, je préconise un ordre à 1 et non 0.


De même, si l'ordre n'est pas un entier positif (par exemple un entier négatif), j'acquitterai négativement (NAK) avec un code retour 581 (XML syntax error, non conforming to schema) et un ordre 1.

Q5.4 est-on obligé de renvoyer une missive ?

L’émetteur d'une missive qui n'a pas reçu à temps un acquittement peut renvoyer une missive, selon la directive d'implémentation de la missive et la SMIRK Missive.
La première dit "If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent".
La seconde dit "Un système de renvoi d'une missive peut être implémenté.[...] l'émetteur de toute missive nominale dont l'acquittement n'est pas constaté dans un temps supérieur aux minima définis pour la priorité de la missive peut renvoyer la missive avec un numéro d'ordre incrémenté ; il s'interdit de le faire avant ; il n'est pas obligé de le faire"

L’émetteur peut donc renvoyer une missive mais il n'est pas obligé de le faire; il n'est même pas obligé d'implémenter le système donc de proposer le service à son client.

SEPAmail et le W3C

En ce début de semaine se tient une conférence du W3C à Paris autour du futur du paiement sur le Web.

Le W3C, c'est le consortium de quelques 380 entreprises, fondées en 1994 par Tim Berners-Lee, avec le leit-motiv « un seul web partout et pour tous ».
Toujours piloté de Tim Berners-Lee (inventeur de HTML et HTTP) présenté souvent comme le papa du Web, le W3C est chargé de promouvoir les protocoles qui permettent une application mondiale partagée sur le réseau internet, notamment : HTML, XHTML, XML, RDF, SPARQL, CSS, PNG, SVG, SOAP... Bref, plein de protocoles utilisés par SEPAmail.
 
La problématique, et l'agenda complet de cet évènement se trouve ici.


Plusieurs acteurs de la communauté SEPAmail ont présenté des "prises de position" sur le sujet.

L'une de ces prises de positions expose le besoin de ré-équilibrage de la relation entre le chaland (pour faire vite et imprécis, l'acheteur) et le marchand dans le paiement en général et celui à distance sur le web en particulier.

Dans les pistes avancées pour ré-équilibrer par la standardisation, il y a, entre autres, SEPAmail, mais aussi des technologies dont nous avons parlées dans nos billets.

Je vous livre la version française au format pdf.

Jeffrey Jaffe, l'actuel directeur du W3C (CEO), est à Paris, et devrait rencontrer aujourd'hui certains acteurs de SEPAmail. Pour quelques uns des artisans du protocole SEPAmail, c'est un peu le graal...

SEPAmail : communiqué de presse sur le lancement du service SEPAmail

Lundi 17 mars, les adhérents SEPAmail ont communiqué sur le succès de l’expérimentation SEPAmail en 2013 et sur le lancement du service pour leur client en 2014.
Ce communiqué a été repris cette semaine dans de nombreux articles:

• Les échos (17/03/2014) Le paiement de facture en un « clic » dans les starting-blocks en France
• Les échos (18/03/2014) Le paiement de facture en ligne sera une réalité à l'automne 2014
• 01 informatique (18/03/2014) Bientôt, réglez vos factures en ligne et en un seul clic
• L'écho républicain (17/03/2014) Les banques françaises pour le paiement de factures "en un clic" 
• La tribune de l'assurance (17/03/2014) SEPAmail : Un regroupement pour le règlement de factures
• Chalenge (17/03/2014) Les banques françaises veulent développer le paiement "en un clic"
• CBanque (18/03/2014) Banques françaises : le paiement électronique des factures disponible courant 2014
• Cercle Finance (18/03/2014) BNP Paribas: lance un service de règlement de factures.
• Journal du Net (18/03/2014) Paiement en ligne : six banques préparent le lancement d'un TIP numérisé
• Boursier.com (18/03/2014) Payer ses factures en un clic sera bientôt une réalité
• EduBourse (17/03/2014) BNP Paribas et SEPAmail
• Blog de Jean-Marc Morandini (18/03/2014) Les banques françaises veulent développer le paiement de factures en ligne 
• ITespresso.com (19/03/2014) Sepamail.eu : 5 réseaux bancaires dématérialisent les règlement de factures
• Usine digitale (19/03/2014) Six banques françaises s’unisssent pour lancer Sepamail.eu, un service de paiement des factures en ligne
• Le monéticien (18/03/2014) SepaMail – Paiement des Factures en Ligne
• Banque-en-ligne.fr (18/03/2014) SEPAmail, un clic pour les factures en ligne
• GoodInfo.eu (18/03/2014) Les cinq plus grandes banques se regroupent dans SEPAmail
• Liberation (17/03/2014) Les banques françaises pour le paiement de factures «en un clic»
• La tribune (18/03/2014) BNP Paribas: lance un service de règlement de factures.
• blog migration SEPA (18/03/2014) SEPAmail
• Responis (24/03/2014) Les banques optent pour le paiement électronique des factures
• 
  

Codes de retour du protocole SEPAmail au niveau de la couche Missive

Le protocole SEPAmail liste sur cette page (standard en version 1206) des codes en trois chiffres pour qualifier/préciser la nature de l'acquittement d'une missive.

Nous allons, dans ce billet, successivement :

• reprendre la définition générale de ces codes
• regarder l'usage de chacun des codes
• répondre à quelques questions fréquemment posées

Définition des codes d'acquittement

Les codes d'acquittement forment une nomenclature à chiffres [0-9]{3} sur trois positions :

• la classe (position 1)
• le sujet (position 2)
• le détail (position 3)

Cette nomenclature est similaire aux codes de statut du retour des protocoles HTTP, SMTP etc...

La classe peut être :

• classe 1 = non utilisé pour le moment, information
• classe 2 = succès
• classe 3 = non utilisé pour le moment
• classe 4 = erreur transitoire
• classe 5 = erreur permanente

Inventaire des codes proposés par le standard

La liste des codes d'acquittement proposés peut se schématiser en carte mentale :

Liste des codes retour proposés par la version 1206

Nous allons voir que de nombreux codes ne servent pas.

Ils ont (malheureusement) pour seul effet de perdre ceux qui veulent comprendre le protocole.

Ils sont résiduels aux expérimentations passées (et des besoins ponctuels de développeurs) et n'ont pas vocation à rester dans le standard, maintenant que l'industrialisation est en cours et les expérimentations finies.


Sujet 1 : les addresses


Ce sujet permet d'acquitter une missive nominale sur les champs de l'entête de missive A.5.1 (balise Snd) et A.5.4 (balise Rcv) exclusivement.


5.1.1     Unknown sender

L'expéditeur de la missive, comme défini par la balise A.5.1 (Snd, balises BIC et|ou IBAN) n'est pas connu par le récepteur. Ce code est répondu en complément d'un acquittement de type NAK. Le récepteur se pose la question du BIC de l’émetteur (référentiel commun) ou de la forme de l'IBAN émis, qui est le plus généralement un QXBAN.


5.1.2     Unknown receiver

Le destinataire de la missive, comme défini par la balise A.5.4 (Rcv, balises BIC, IBAN, BBAN, PAN, RIS2D) n'est pas connu par le récepteur. Cela peut concerner le BIC (référentiel commun) ou un identifiant bancaire du récepteur qui n'est pas connu par le récepteur.


5.1.3     Receiver known but out of SEPAmail scheme or ecosystem.

Le destinataire de la missive, comme défini par la balise A.5.4 (Rcv, balises BIC, IBAN, BBAN, PAN, RIS2D) est connu par le récepteur mais ne reçoit pas de missives SEPAmail sur cet ecosystème.
Ce code sert pour préciser à l'expéditeur que ce destinataire existe mais qu'il ne reçoit pas les missives SEPAmail. Il est donc inutile d'utiliser SEPAmail avec ce destinataire pour le moment, et ce, quelque soit l'application de SEPAmail et l'expéditeur.
Ce code ne sert donc pas pour refuser l'attache d'un expéditeur précis ou pour une application de SEPAmail précise.


2.1.9     Receiver known, missive forwarded

C'est le code le plus utilisé, car c'est le seul code de succès de la liste utilisable avec un acquitement positif (ACK).


Sujet 2 : la boite aux lettres


Ce sujet est ambigu car il adresse la couche échange d'enveloppe SEPAmail et non la structure de la missive.


Il est historique à l'expérimentation : lors du passage du mode canonique au mode flash (web services), les implémenteurs de l'expérimentation ont eu besoin de ces codes retours natifs au protocole d'échange SMTP, d'où ces codes concernant les adresses mails de l'enveloppe SMTP/S-MIME et la longeur des messages autorisés, au sens message SMTP et non message SEPAmail.


Mon conseil est de ne pas utiliser ce sujet dans l'acquittement d'une missive et de bien réfléchir à l'implémentation naturelle de l'échange d'enveloppe SEPAmail, quelque soit le type de contenu transporté.


Sujet 3 : les systèmes



Ce sujet traite des erreurs "dites" système, c'est à dire relevant de l'infrastructure connectée.


N.3.1     File system full

Ce code (431 ou 531) ne devrait pas être utilisé en acquittement de missive entre deux adhérents SEPAmail. Il n'adresse pas le contenu de la missive mais l'échange d'enveloppes. Il y a donc d'autres couches protocolaires pour décrire ce statut.


N.3.2     Inaccessible server

Ce code (432 ou 532) ne devrait pas être utilisé en acquittement de missive entre deux adhérents SEPAmail. Il n'adresse pas le contenu de la missive mais l'échange d'enveloppes. Il y a donc d'autres couches protocolaires pour décrire ce statut.


4.3.3     Sending date+time incorrect, and outside of the margin. (Missive has not been handled).

Ce code retour (433 ou 533) permet de traiter une incohérence d'horodatage de la missive, champs A.5.2 (balise SndDtTm) ne permettant pas d'acquitter la missive.
Si la missive peut être acquittée positivement, selon les règles de réception définies dans la directive d'implémentation , alors le bon code retour est 219 avec une précision dans le champs A.6.7 (balise RtgWarn/Code à la valeur BAD_TIME) et non un code 433 ou 533. Il n'y a donc pas de code retour possible 233, comme indiqué par la mention "Missive has not been handled".


5.3.3     Sending date+time incorrect, and outside of the margin. (Missive has not been handled).

Je ne vois pas de sens à ce code retour. Si quelqu'un voit un tel cas, Je suis preneur en commentaire d'un cas d'usage.


Sujet 4   Le débiteur



Ce sujet est une erreur de compréhension du modèle en couche proposé par SEPAmail ainsi qu'une erreur de compréhension de la notion d'application.
Il est dédié à l'application de SEPAmail RUBIS.


Je suis certain qu'il ne devrait pas être utilisé.


Le code 541 devrait plutôt être un code 512 ou 513.
Le code 249 serait un code 219.
La notion de compte de test n'a pas de sens SEPAmail et elle relève d'une confusion avec l'articulation monétique pendant l'expérimentation.


Sujet 5 La sécurité et la cryptographie



Ce sujet est important pour SEPAmail; il concerne la sécurité en général et la cryptographie en particulier, telle qu'elle est utilisée dans l'enveloppe SEPAmail ou dans la missive SEPAmail.
La cryptographie utilisée pour les connexions sécurisée des protocole HTTP, SMTP ou autres, n'est donc pas concernée par ces codes d'acquittement

5.7.2     Impossible to decrypt (key1 or key2). In fact, since the decryption of the S-MIME envelope cannot be processed, the embedded missive cannot be read and acknowledged. Thus, the proper behaviour in this case will be avoiding any response to the sender.

Ce code n'a pas de sens au niveau missive et ne permet pas d'acquitter dans les conditions du protocole SEPAmail. Il ne peut donc pas être utilisé.


5.7.3     Unsupported algorithm or security function

Ce code est utilisé quand un algorithme ou une fonction de sécurité non autorisé par le protocole SEPAmail sont utilisés pour l'enveloppe SEPAmail.
Il est naturel, par exemple, si sha1 est utilisé alors que la directive d'implémentation de la cryptographie exige a minima sha256, d'acquitter toute missive enveloppée à l'aide de sha1 avec un tel code.


5.7.4     Integrity error

Ce code est utilisé s'il y a une erreur d'intégrité dans l'utilisation des fonctions de sécurité. Cela peut être une somme de contrôle non intègre, une clé périmée, une signature lue, mais non référencée, une incohérence entre l'adresse mail utilisée par SMIME et l'adresse utilisé dans l'entête SMTP ou l'échange SMTP.


Sujet 8 Contenu



Ce sujet traite de l'analyse du contenu de la seule missive, avec les quelques adhérences résiduelles aux couches message et enveloppe.


5.8.1     XML syntax error, non conforming to schema

Ce code est utilisé quand une missive n'est pas conforme au schéma XML sepamail_missive.xsd.


5.8.2     Missive contents incoherent

Ce code est utilisé quand une missive est conforme au schéma XML mais n'est pas conforme à la directive d'implémentation de la missive dans le cadre de son utilisation.
C'est le code d'erreur utilisé quand une missive de type SMAPI ou de service est utilisé entre deux adhérents SEPAmail.


5.8.3     Invalid missive identifier

Ce code est spécifique à l'identifiant de la missive, notamment si celui-ci est invalide comme doublon ou ne respecte pas la règle de génération de cet identifiant, règle que j'ai commentée dans un précédent billet.


5.8.4     Order number error

Ce code est utilisé quand le champ A.3 (balise MsvOrd) n'est pas conforme à la règle d'usage.


5.8.5     Version not supported

Ce code est utilisé si la version utilisée de la missive SEPAmail n'est pas mise en œuvre.


5.8.6     Corrupted contents or virus detected. In fact, since the detection of a corrupted content may be prior to the extraction of the embedded missive due to infrastructure constraints, this missive may not be acknowledged to the sender.

Ce code fait l'objet d'une ambiguité portée par la protection de type pare-feu applicative des infrastructures qui ne respectent pas, la plupart du temps, le modèle en couche de la famille TCP/IP, afin de mieux protéger le système d'information. Ces systèmes ne répondent pas correctement sur les couches impactées, afin de ne pas donner lieu à des dénis de service.

Voici des cas d'usage qui pourraient utiliser ce code :

• utilisation d'un caractère UTF8 non autorisé par SEPAmail
• contenu des champs binaires (CDATA) suspect après passage d'un anti-virus
• somme de contrôle non cohérente avec le contenu

 

FAQ sur les codes d'acquittement 

 

Peut-on renvoyer un code retour ne contenant qu'une partie de l'information, par exemple un code de classe 5 sans sujet ni détail ?

Rien n'interdit de spécifier seulement la classe, par exemple 2 ou 4 dans préciser le sujet et le détail d'un code d'acquittement.
Le code d'acquittement n'est pas obligatoire.
Seul l'est le statut de l'acquittement, (balise AcqSta)

Pourquoi ne pas supprimer les codes d'acquittement obsolètes ?

Bonne question. Cela devrait être fait après la fin de l'expérimentation.

Lors des expérimentations et avant le passage en conformité des différentes plateformes des adhérents, il a fallu composer avec différentes version logicielles des implémentations et laisser les codes d'acquittement, notamment ceux liés à RUBIS.

Peut-on inventer des nouveaux codes ?

Pour votre usage interne, j'imagine que oui.

Je conseille de les proposer à la communauté si vous souhaitez partager leur interprétation avec d'autres acteurs SEPAmail.

Comment déclarer SEPAmail à la CNIL si un code d'acquittement donne de l'information sur mon client ?

Il est difficile de répondre de façon générique à cette question.

La plupart des codes proposés sont généraux.

Dans une messagerie, il y a toujours une information transportée et bouclée... donc il y aura de l'information sur l'expéditeur et le destinataire partagée avec les 4 acteurs mis en jeu.

L'intérêt de SEPAmail est que cette relation à 4 est couverte par des contrats clairs entre chaque partie : le contrat adhérent-utilisateur et le contrat d'adhésion SEPAmail.

Il ne faut pas non plus confondre la couche SEPAmail et les applications de SEPAmail, comme RUBIS ou GEMME, qui devraient se déclarer séparément.

Consulter la CNIL ou votre CIL (correspondant informatique et liberté) me paraît un bon préalable pour déclarer.

A quoi sert le champ description de l'acquittement ?

Ce champ sert à mettre une information permettant à l'émetteur de la missive nominale d'analyser plus finement le pourquoi d'un code retour.

Il est libre et doit servir la messagerie sans desservir le client final.

Il est dédié à une analyse humaine et non automate.



Comment peut-on acquitter plusieurs fois une missive nominale ? Si c'est le cas, comment savoir quand le processus d'émission peut-être considéré comme terminé ?

La possibilité d’acquitter une missive en plusieurs fois est évoqué dans la SMIRK MIS1202 et clairement dans la directive d'implémentation de la missive, en donnant un exemple d'acquittement multiple, qui utilise de plus un code 249, code que je proscris un peu plus haut.

Cet acquittement multiple provient d'une demande de pouvoir relier SEPAmail à une chaine de traitement bancaire batch pour RUBIS... là encore, il y a confusion entre les applications de SEPAmail (structurant des dialogues de messages) et la messagerie SEPAmail (mécanisme de routage, d'adressage, d'authentification des partie, de sécurité du transport).

L'acquittement multiple pose aussi une problématique claire de finalisation du processus d'émission et l'implémentation de la fin du processus dépend de l'interprétation des temps de réponse pour acquitter... Est-ce un temps de réponse pour le premier acquittement ou pour le dernier ?

Selon ma compréhension du protocole, l'expérience de l'implémentation, des différents usages de ce protocole, le système d'acquittement devrait être simplifié en proposant clairement que les statuts ACK et NAK soient des statuts finaux (sans possibilité pour le récepteur d'acquitter de nouveau ensuite).

Le système de renvoi sert pour l'émetteur à dire "alors, vous me répondez ?"... Certains récepteurs désirent dire :  "j'ai reçu mais je n'ai pas encore traité, donc pas besoin de renvoyer."

Quelqu'un m'a un jour dit qu'on ne pouvait pas vraiment distinguer si la missive n'était pas arrivée ou si le récepteur n'avait pas encore acquitté.

Ce n'est pas vrai dans l'absolu et vrai dans la pratique de certains systèmes d'information.

Dans l'absolu, le protocole d'échange SMTP (et par analogie d'implémentation pour HTTP+SOAP) permet bien de savoir si le système d'information du récepteur a reçu le paquet d'information... un certain nombre de codes retour sont bien prévus et implémenté par toutes les applications MTA, quand elles ne sont pas bridées par un pare-feu applicatif.

Dans la pratique, les système d'information ne sont pas parfaits et leur exploitation peut perdre des messages, et ce la, pour toute sorte de raison.

La proposition d'ajouter un statut d'attente (WAIT) ne résoudra pas le problème de fond. Il faut que l'acquittement soit simple à mettre en œuvre sur la couche missive, ne se confonde pas avec la couche message et applicative de la messagerie SEPAmail.

Il faudrait donc (et cela sera à mon avis forcément le cas dans la version industrielle dès qu'il y aura de gros flux) que les adhérents de SEPAmail, qui mette en œuvre le réseau privé SEPAmail, s'engage à acquitter une seule fois dans les temps de la priorité de la missive.
Les mécanismes de renvoi et d'escalade sont mis en œuvre pour garantir cette qualité de service. Je milite donc rester simple sans présumer des systèmes d'information mettant en œuvre le protocole SEPAmail.

FAQ n°4 : Autour de quelques règles d'implémentation SEPAmail

Il n'y a pas (encore) d'implémentation de référence du protocole SEPAmail. Il n'y a pas non plus de cas d'usage et d'exemples de flux partagés par la communauté. J'ai ouvert un espace pour cela, mais il n'y a pas encore de soumission importante. Pour ceux qui veulent partager, c'est le projet SMITE, SEPAmail, I Want Test Examples.

L'implémentation SMART des quatre premiers adhérents s'est construite autour d'un produit similaire (SEPAplug®, édité par StreamMind®). L'interprétation des équipes de développement de StreamMind était donc un peu un standard de fait pendant l'expérimentation initiale.

Dès 2010, SEPAmail.eu m'a demandé de faire un contrôle de cohérence entre les documents spécifiant le protocole et les différentes expérimentations autour de RUBIS et de GEMME. Cela m'a permis de confronter les documents produit par le committer de l'époque (Olivier Jousselin) avec les différentes implémentations de composant logiciels.

Un comité Norme s'est constitué en 2011 pour publier le standard SEPAmail en partenariat avec le committer. Trois versions ont vu le jour (la version 1112, 1202 et la version stable 1206, relue et validée par une quarantaine d'acteurs dont les éditeurs de l'expérimentation et tous les contributeurs).

Aujourd'hui, voici la liste des documents de référence du standard :

• la norme en version 1206
• la liste des erratas de la version 1206

Pour les adhérents, il y a aussi :

• un recueil de règles opérationnelles (à demander à sepamail.eu) pour se connecter au réseau SEPAmail
• un cahier de test de conformité (à demander à sepamail.eu) pour mettre en valider la conformité de sa plate-forme ou de son implémentation

Il y a aussi, pour coopérer sur le standard :

• la liste des change request (création de compte exigée)
• le wiki et les pages de discussion

La lecture de ces documents est importante pour connaitre les questions, les remarques des implémenteurs, quand ceux-ci posent des questions à la communauté.

Voici quelques unes des questions les plus souvent posées.

Pourquoi l'identifiant d'un message (balise MsgId) devrait être déduit d'un identifiant de missive (balise MsvId) alors que le message est généré avant la missive ?

La règle issue de la directive d'implémentation des messages est celle-ci : "This identifier should be equal to the missive identifier (MsvId element, see related doc.), followed by an underscore ('_') and by a number, which must be unique in a given missive. In any case, the message identifier MUST be unique for a given sender."

Cette règle, si elle est interprétée de façon naturelle, pose problème. En effet :

• elle fait confondre la couche message et missive
• on dénature la notion d'identifiant en essayant d'y coller un concept de classification
• on limite à des nombres un champ déjà bien réduit par le préfixe en limitant cela à des nombres et non n'importe quel caractère

La plupart de ceux qui ont implémenté le protocole SEPAmail sont restés perplexes devant cette règle puisque le message est, a priori, généré avant la missive.

La plupart s'en sont sortis en générant un identifiant de type Id1_Id2 pour le message et ils ont récupéré l'identifiant Id1 pour construire la missive.
Mais ceci n'est pas satisfaisant dans une logique de protocole en couche.
De plus, un certain nombre de règles implicites, pour le maitre d'ouvrage, se cachent alors derrière cette directive d'implémentation, que l'on peut résumer par les questions qu'il se pose naturellement:

• l'identifiant du message devant contenir l'identifiant de la missive,  faut-il vérifier cette règle ? Et dans ce cas, pourquoi ne pas inclure une balise MsdId dans le message ?
• quelle est la nature de la relation entre un message et une missive: 1-1, 1-n, n-m ?
• est-ce à l'adhérent (le relais et/ou générateur) de gérer ces identifiants ou l'expéditeur de la missive ?
• en construisant un identifiant signifiant, ne suis-je pas en train de donner involontairement de l'information sur mon système ?

Comment interpréter la directive d'implémentation de l'identifiant d'une missive (balise MsvId) ?

La directive d'implémentation de la missive pose le principe suivant "The format of this identifier is YYYYMMDDhhmmssxxx + "_" + sender_id. The first part is the creation date and time, including milliseconds The second part can be used freely by the sender."

Ceci pose des problèmes à l'implémentation, notamment car cela induit en première lecture une liaison à la date de génération de l'identifiant  avec une limitation sur le nombre d'identifiants que l'on peut créer.

Certains verront donc le besoin d'implémenter une règle de vérification des dates.

Ces problématiques d'implémentation sont venues de longues discussions sur le (soi-disant) besoin d'un identifiant unique de bout en bout pour les missives comme pour les messages. Naturellement, le problème n'est pas simple et je vous renvoie sur la notion d'uuid pour en comprendre la portée et les normes concernées.

Selon moi, ces problèmes ont été réglés en pratique il y a déjà longtemps par les MTA (Mail Transfert Agent) et les clients de messagerie. Un récepteur ne pouvant garantir qu'un émetteur sache identifier de façon unique un message, identifie pour lui-même tout ce qu'il reçoit. Nous devrions donc utiliser les solutions déjà trouvées par d'autres et qui, aujourd'hui, fonctionnent bien.

Un implémenteur peut donc générer son propre identifiant de missive et de message à la réception et ajouter celui-ci dans l'entête de la missive et du message.

Ma proposition, pour respecter la version 1206 du standard (et ne pas initier des complications dans l'implémentation) est de supposer que la "creation date and time" soit celle de SEPAmail (et non autre chose), c'est à dire le 1^er avril 2008 vers 13h14 pour tous, comme cela, on en sera quitte pour un poisson d'avril. Je propose donc d'utiliser le préfixe 20080401131415926.

Pourquoi une missive doit absolument contenir un message de type SEPAmail ?

La missive peut contenir dans son corps (balise MsvBdy) zéro ou un message quelconque SEPAmail, comme indiqué dans la directive d'implémentation de la missive SEPAmail.

Il n'est donc pas possible d'inclure plusieurs messages.
Il n'est donc pas possible d'inclure autre chose qu'un message SEPAmail.
La liste des messages SEPAmail est définie dans les schémas.

En 2008, le premier schéma de missive SEPAmail permettait de contenir dans le corps de la missive n'importe quelle donnée (anyType). Ceci avait le charme de permettre de vérifier la validité d'une missive sans celle du contenu de la missive.
Pour l'expérimentation au sein des systèmes d'information bancaires, un responsable de la sécurité a demandé de définir tous les types des données et de ne faire qu'une validation globale de la missive contenant le message.
Les schémas ont donc été changés en conséquence. Les avantages sont ceux mis en avant par le responsable de la sécurité. Comme SEPAmail cherchait à l'époque à privilégier le mode unitaire et ne pas rester dans le mode batch qui est la norme bancaire d'échange d'information, le nombre de messages par missive a été limité à un message au plus.

Les inconvénients de ce choix sont nombreux s'il est respecté à la lettre: confusion de la couche missive et message, impossibilité de chiffrer le message facilement au sein d'une missive en clair, schéma xml très volumineux, balise racine du message xml non équivalente à la balise interne de la missive, etc...

Une proposition d'implémentation intéressante est, à mon avis, d'utiliser un schéma simplifié (par une transformation xsl ?) pour la missive et de bien distinguer les deux couches missive et message, comme on distingue déjà la couche enveloppe.

Pourquoi inclure tous les schémas XML dans le schéma de la missive ?

Un implémenteur m'a demandé pourquoi inclure tous les schémas xsd dans la missive et non seulement ceux dont on a besoin.
Pour bien comprendre de quoi on parle, je vous propose de regarder (attention à la limite mémoire de votre navigateur) ce schéma vectoriel représentant cette inclusion.

Quand un schéma est simple, la validation d'un flux xml est très rapide. Quand il est compliqué, cette validation peut être couteuse en ressource machine ou en mécanisme de cache. Le bon exemple est celui de la validation d'une missive d'acquittement qui ne nécessite aucun schéma de messages à inclure.

La question est donc licite et connue de tous les programmeurs avec l'inclusion des librairies au sein de leur programme.

Avec la solution préconisée du changement de schéma pour la missive (confère la question précédente), on peut implémenter une validation beaucoup plus efficace. C'est donc, selon moi, une réponse élégante à ce vrai problème.

Comment comprendre les espaces de noms SEPAmail ?

Ce sujet revient souvent sur le devant de la scène, notamment car le XML n'est vraiment pas human-readable.

Pour comprendre vite, disons simplement que SEPAmail définit un espace de nom principal décliné en plusieurs schémas (un pour la missive, un pour le message générique, un par type de message, quatre pour les types partagés par les schémas précédents) et fait référence aux espaces de nom de l'iso 20022 (des pain, des camt) et de la signature de xml (dsig).

Pour comprendre dans le détail, regardons la définition de la balise racine du schéma lié à la missive :

<schema
    targetNamespace="http://xsd.sepamail.eu/1206/"
    elementFormDefault="qualified"
    xmlns="http://www.w3.org/2001/XMLSchema"
    xmlns:sem="http://xsd.sepamail.eu/1206/"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

qui s'interprète comme suit :

• targetNameSpace définit l'espace de nom du schéma,
• elementFormDefault précise que tous les sous-éléments sont qualifiés par défaut au sein de l'espace de nom SEPAmail (l'équivalent n'a pas été fait pour les attributs)
• xmlns="http://www.w3.org/2001/XMLSchema" est la référence à l'espace de nom définissant les schémas XML; cette déclaration pourrait donc être en première ligne
• xmlns:sem="http://xsd.sepamail.eu/1206/" permet de définir le préfixe sem pour l'espace de nom SEPAmail
• xmlns:ds="http://www.w3.org/2000/09/xmldsig#" permet de définir le préfixe ds pour l'espace de nom lié à la signature DSIG

On a ensuite :

<import>
    namespace="http://www.w3.org/2000/09/xmldsig#"
    schemalocation="xmldsig-core-schema.xsd">
</import>
<include schemalocation="type_sepa.xsd" />
<include schemalocation="type_sepamail_general.xsd" />
<include schemalocation="type_sepamail_missive.xsd" />
<include schemalocation="sepamail_message.xsd" />


qui s'interprète comme suite :

• importation de l'espace de nom lié à XMLDSIG, qui permet la canonisation et la signature de flux XML (standard W3C)
• inclusion du fichier interne à l'espace de nom SEPAmail type_sepa qui comprend les types dérivés de l'iso20022 pour SEPAmail
• inclusion du fichier interne à l'espace de nom SEPAmail type_sepamail_missive qui comprend les types liés à la couche missive
• inclusion du fichier interne à l'espace de nom SEPAmail type_sepamail_message qui comprend les types liés à la couche message
• inclusion du fichier interne à l'espace de nom SEPAmail sepamail_message qui comprend les types de messages SEPAmail

Pour bien comprendre les entêtes des schémas et des flux xml associés, il faut donc maîtriser l'usage des attributs targetNamespace, schemalocation, namespace, elementFormDefault et avoir compris que la référence unique d'un espace de nom est une uri qui n'a pas besoin d'exister, bref une étiquette unique.

Je conseille d'installer localement un atelier xml avec les schémas et d'essayer de valider des flux pour bien comprendre les implications des espaces de noms.

Je conseille aussi d'inclure dans les flux xml la référence aux espaces de nom dans la première balise utilisant l'espace et d'utiliser des préfixes courts mais signifiants.

A la lecture de la question précédente, vous aurez compris que je conseille également une inclusion minimaliste selon les besoins réels de validation des flux.

Pourquoi RUBIS et GEMME ne font pas l'objet d'une SMIRK, comme Jade, Diamond, la missive, le message, la cryptographie etc. ?

La question m'a été posée récemment.
RUBIS et GEMME ne font pas l'objet d'une SMIRK comme JADE ou DIAMOND alors que cela pourrait (et devrait à mon sens) être le cas.


Cela serait un bon exercice de réduire la description de RUBIS et de GEMME à un ensemble de définition et de règles, comme pour JADE.

SEPAmail : utilisation des protocoles de l'internet SMTP, SMIME, HTTP, REST, SOAP, IP, DNS...

Le protocole SEPAmail peut se définir comme un ensemble de règles permettant de mettre en oeuvre une messagerie entre un expéditeur et un destinataire (appelés les utilisateurs de SEPAmail) via des relais (appelés adhérents du réseau privé SEPAmail).

Ces relais  sont des fournisseurs d'accès au réseau SEPAmail pour le compte de leurs clients.
Le rôle de ces relais est :

• de relayer les messages de leur client sur le réseau SEPAmail
• d'authentifier leurs clients quand ils émettent ou reçoivent un message SEPAmail
• d'accuser réception des messages au nom de leur client destinataire

Pour réaliser ces fonctions en se servant d'un réseau de transport public comme internet, le protocole SEPAmail met en œuvre trois couches d'abstraction :

• une enveloppe SEPAmail, qui, dans l'état de l'art du moment, est une enveloppe SMTP/S-MIME
• une missive SEPAmail qui, pour le moment, est un flux xml contenant un entête et un corps
• un message SEPAmail qui, pour le moment, est un flux xml dérivé d'un gabarit de message générique à entête et corps.

Cette double encapsulation au sein d'une messagerie à relais permet de sécuriser la messagerie et de faire transiter des messages sur le réseau public internet d'un expéditeur à un destinataire avec un bon niveau de confiance, de confidentialité, d'intégrité.

Il existe deux façons de faire transiter les enveloppes SEPAmail:

• le mode canonique qui est pour le moment un échange SMTP dans l'état de l'art
• le mode flash, voulu par les premiers adhérents qui est, pour le moment, un échange web-services de serveur à serveur à l'aide du protocole SOAP sur HTTP(S) ou REST sur HTTP(S)

On peut donc schématiser l'utilisation des couches protocolaires par le schéma suivant:

Les couches utilisées par le protocole SEPAmail

Nous retrouvons dans la colonne de gauche les couches du modèle TCP/IP, puis les couches du protocole SEPAmail et enfin les protocoles standards utilisés:

• S-MIME au sein de SMTP pour la couche enveloppe
• un échange SMTP pour l'échange SEPAMail en mode canonique (le plus naturel et le moins couteux)
• un échange SOAP sur HTTP pour l'échange SEPAmail en mode flash tel qu'implémenté pour l'expérimentation (le plus couteux et pas très naturel sauf à implémenter SEPAmail au sein d'une prise SOAP plus générale)
• un échange REST sur HTTP pour l'échange SEPAmail en mode flash et sobre (rapide, moins couteux que SOAP, naturel car SEPAmail permet d'échanger une ressource enveloppe SEPAmail)
• TCP comme couche transport quand il est mis en oeuvre sur le réseau à bas coût internet
• IP et DNS pour la couche réseau

A la lecture de ce schéma, nous voyons que SEPAmail est un protocole en couches utilisant des standards du web. SEPAmail écrit que cette utilisation doit être réalisée dans l'état de l'art, ce qui, signifie, par exemple :

• pour la couche HTTP, l'utilisation de la version 1.1 pour les possibilités de négociation de contenu et de connexion persistante,
• pour la couche S-MIME, l'utilisation de sha256 au minimum à la place de sha1 selon les recommandations récentes.

Les règles de l'état de l'art pour les protocoles utilisés par SEPAmail sont, si besoin, précisées dans des règles opérationnelles issus des travaux des adhérents SEPAmail et partagés entre eux.
Ces règles opérationnelles précisent également les restrictions de l'utilisation de certains protocoles en expliquant dans la mesure du possible les raisons afin qu'une règle ne soit pas appliquée indéfiniment si la raison a disparu.

Le standard SEPAmail n'explique donc, ni l'état de l'art des couches utilisées, ni l'utilisation de ces couches.

Prenons un exemple pour bien comprendre ce que cela peut signifier pour celui qui implémente SEPAmail au sein d'un logiciel.

Supposons que l'adhérent de l'expéditeur d'un message envoie une enveloppe SEPAmail en mode canonique avec un algorithme cryptographique non supporté par le système récepteur de l'adhérent du destinataire, alors, il est normal que ce système récepteur réponde un code de type 476 ou 576 (Cryptographic algorithm not supported) sur la couche SMTP, conformément à la RFC 3463.

Si maintenant cette même enveloppe est conforme du point de vue SMIME avec un algorithme supporté par S-MIME et l'agent smtp (MTA) mais que l'enveloppe SEPAmail utilise un algorithme non permis par le protocole SEPAmail, une bonne façon de répondre est de répondre sur la couche SEPAmail, c'est à dire d'envoyer une missive d'acquittement avec un statut NAK et un code retour 573 (Unsupported algorithm or security function ), conformément au fonctionnement proposé par la SMIRK MIS 1202.


Le principe général est ainsi, comme le veut l'usage avec les protocoles internet, de répondre sur la bonne couche des erreurs de la couche et de ne répondre sur la couche SEPAmail que pour ce qui concerne le protocole SEPAmail.

Il est important de noter que le transport d'une enveloppe SEPAmail doit s'imaginer en premier lieu par le mode canonique, c'est à dire via le protocole d'échange SMTP, puisque c'est le mode naturel de la messagerie SEPAmail.
Le mode flash doit être implémenté de façon cohérente au mode canonique, que ce soit via SOAP ou REST, sujet qui fera peut-être l'objet d'un billet.

Revue de presse : février 2014

Quelques parutions en février sur SEPAmail :

• 7/02/2014 Bfinance Observatoire de la migration SEPA
• 15/02/2014 CEGOS une formation parlant de SEPA et SEPAmail
• 28/02/2014 e-wallets, QR codes... les innovations du paiement en ligne et à distance par la société générale

 Bonne lecture

Quelques implémentations logicielles du protocole SEPAmail

La conformité des plates-formes des adhérents au protocole SEPAmail est en cours de réalisation, notamment grace à l'outil mis en oeuvre par SEPAmail.eu avec le concours des équipes de STET.

Cela se passe plutôt bien et permet de confronter les interprétations des diverses implémentations logicielles entre elles et avec le standard.

Ayant un peu suivi les questions qui se sont posées, je pense décliner quelques articles autour :

• des utilisations dans l'état de l'art des protocoles SMTP, S-MIME, HTTP etc...
• de quelques règles d'implémentation SEPAmail qui méritent d'être précisées ou discutées, notamment autour des identifiants et des dates
• des codes de retour du protocole SEPAmail au niveau de la couche Missive

Voici la liste des implémentations logicielles dont je suis au courant (à ce jour), classées par ordre alphabétique des éditeurs :

• AriadNext et son implémentation partielle d'un client Android
• Atos et son implémentation complète en cours
• Axway et son implémentation d'un passerelle SEPAmail
• deciBI et son implémentation partielle d'un client open source SMURF
• deciBI et son implémentation partielle d'un client open source SMETH
• Deny All et son implémentation SEPAmail au sein de son pare-feu applicatif
• Elcimai et son implémentation de test d'un client ebics pour SEPAmail 
• CGI/Logica et son implémentation complète en cours
• GFI/AriadNext et son implémentation complète d'un SMART/SMILE avec les applications RUBIS, TEST et DIAMOND
• IBM et son implémentation SEPAmail au sein de son pare-feu applicatif Datapower
• Lyra Networks  et son implémentation complète d'un SMART/SMILE avec les application RUBIS, TEST
• PPI et son implémentation de test d'un client ebics pour SEPAmail
• SOPRA et son implémentation d'une application mobile m-Rubis
• SpeedInfo et son implémentation partielle d'un client eCommerce RUBIS
• STET et son implémentation partielle d'un SMART/SMILE avec les applications RUBIS, GEMME, TEST et une application de conformité pour le compte de SEPAmail.eu
• StreamMind et son implémentation complète d'un SMART/SMILE avec les applications RUBIS, TEST (GEMME est obsolète, DIAMOND est en cours), en partenariat avec HP pour la partie matérielle
• TURBO et son implémentation complète d'un client créancier et débiteur pour RUBIS

Quatre des cinq adhérents actuels ont également intégré le protocole SEPAmail au sein de leur SI, multipliant donc les implémentations logicielles partielles sur des segments fonctionnels.

N'hésitez pas à rajouter toute information que vous connaitriez sur le sujet ou commenter ce billet pour toute précision sur les implémentations listées ci-dessus.

Revue de presse : janvier 2014

Le mois de janvier a connu un creux de communication de SEPAmail, qui se rattrape en février, annonçant la mise en marché au début du deuxième trimestre 2014.

• 24/01/2014 SEPAmail, la pub de natixis

Dans le cadre du workshop autour du Web Payment organisé le 24 mars 2014 au palais Brognard par le W3C,  BPCE et Cyril Vignet ont déposé un position paper mettant en avant SEPAmail.