mercredi 26 décembre 2012

Communauté SEPAmail : SpeedInfo

Nous continuons notre tour d'horizon des entreprises sachantes et contributrices de SEPAmail avec SpeedInfo.

Samuel Anzalone, son fondateur, répond à nos questions.

Quand a été créée Speedinfo, dans quel contexte ?


La société Speedinfo a été créée en 2003.
Après la phase de spéculation à outrance de l’explosion de la bulle Internet, nous nous sommes aperçus que les e-commerçants souhaitaient être plus vigilants pour ne pas revivre une nouvelle dérive d’Internet. Ils avaient besoin de sécuriser et de fiabiliser leur activité. Et cela passait par la mise en place d’outils pérennes qui n’existaient pas à l’époque.

C’est dans ce contexte que Speedinfo s’est positionnée sur ce marché, l’objectif étant de développer des solutions de gestion commerciale, de gestion financière, véritablement dédiées à l’e-commerce.

Pour ce faire, nous avons travaillé de concert avec de nombreux e-commerçants pour bien adapter nos solutions de gestion à leurs besoins quotidiens. Toujours à l’écoute des nos clients e-commerce, nous continuons aujourd’hui à développer nos solutions dans cette logique de travail collaboratif.

Combien de collaborateurs, quels profils, quelles fonctions ?


Speedinfo est composée d’une dizaine de collaborateurs, tous experts dans leur domaine de compétences : l’e-commerce, la gestion et la sécurité informatique. Bien évidemment, nos spécialistes de l’e-commerce maitrisent les technologies standards leaders du marché que sont Magento et Prestashop.

Sur des projets plus pointus, Speedinfo peut solliciter des intervenants externes pour apporter des réponses fiables et durables.

Quels sont les principaux produits ou services développés et vendus ?


Speedinfo est l’éditeur d’OpenSi, le 1er ERP dédié à l’e-commerce. La société est spécialisée dans le développement d’applicatifs de gestion de site e-commerce, autrement dit des applicatifs en gestion de stock, gestion des paiements, lettrage comptable, rapprochement bancaire…

Ces solutions logicielles se connectent à la plate-forme e-commerce des vendeurs en ligne pour leur faire bénéficier d’outils de gestion pointus par rapport à leurs besoins. Grâce à une synchronisation des données entre le module de gestion commerciale et le site e-commerce, il n’y a plus aucune ressaisie entre les deux solutions. Cette connexion évite ainsi tout risque d’erreur et de perte de temps, aspects primordiaux quand on sait que la réactivité est un leitmotiv dans l’e-commerce.

En complément de ces logiciels de gestion e-commerce, nos experts e-commerce ont bien évidemment la capacité de développer des sites marchands sous différentes technologies, notamment Magento et Prestashop.


Quel est le profil de vos clients, quelles sont vos références ?

 


Nos clients sont essentiellement des e-commerçants qui ont une ou plusieurs boutiques e-commerce pour commercialiser des articles en ligne. Nos clients e-commerçants sont de toutes tailles, générant de moins d’un million d’euros jusqu’à plusieurs dizaines de millions d’euros de chiffres d’affaires.

Nos solutions sont adaptées à tous les secteurs d’activité e-commerce. Nous pouvons citer des clients comme le groupe VDI (1001piles.com, all-batteries.fr), Made In Design.com, spécialiste du mobilier sur Internet, E-Network.fr, spécialisé dans l’informatique, Label Habitation.com, spécialiste des produits liés à la maison (alarmes, chauffages, radiateurs…).

Nous avons deux typologies de clients e-commerçants :
Nos clients sont soit en création d’entreprise. Ils souhaitent obtenir en amont des outils optimisés pour sécuriser leur activité au quotidien et ainsi pouvoir se développer.
Soit des e-commerçants qui ont déjà une activité conséquence mais se sont laissés déborder par le côté gestion. Ils éprouvent des difficultés au quotidien dans leur suivi de trésorerie, dans le suivi des achats. Ils ont des besoins très forts en gestion pour pérenniser leur activité.


Quelles sont vos spécificités ?

 


Speedinfo se positionne au croisement des cultures du e-commerce et de la gestion d’entreprise. Nous n’avons pas vocation à développer des solutions généralistes comme d’autres éditeurs connus. Notre force est véritablement d’être orientée gestion e-commerce pour proposer un produit le plus proche possible des besoins de nos clients. C’est la raison pour laquelle des acteurs comme Prestashop, spécialiste en création de boutiques e-commerce en France et en Europe, a fait appel à nous pour intégrer la solution OpenSi à l’application Prestashop. Avec OpenSi, véritable module Prestashop, Speedinfo est aujourd’hui le partenaire exclusif de Prestashop en matière de gestion commerciale et comptabilité.

Quel est votre lien à SEPAmail ?

 


Speedinfo est l’éditeur de SEPAmail Ecommerce, la 1ere offre permettant de relier une boutique e-commerce au service SEPAmail. Le module permet à des clients de souscrire à SEPAmail pour régler leurs achats sur Internet. Nous avons développé ce module avec la société deciBI, dirigée par Manfred Sherlock OLM - l’un des auteurs de la norme SEPAmail - et Cyril Vignet de la BPCE.

Nous travaillons également avec AriadNext, une société qui développe des applications pour SEPAmail.

Quel est votre implication dans la communauté SEPAmail ? Quelle évolution pour la suite ?


Speedinfo apporte toute son expertise en matière de e-commerce pour le module SEPAmail Ecommerce. Plus précisément, nous avons utilisé notre retour d’expérience et la connaissance du marché de l’e-commerce pour que le module soit le plus conforme possible aux exigences des e-commerçants et de leurs clients.

En plus de ces aspects fonctionnels, l’objectif de ce module est de pouvoir s’adapter en terme technique à des sites e-commerce. Nos connaissances pointues dans le fonctionnement d’un site et des pièges à éviter (lenteur, charge des flux…), nous ont permis de développer un module le plus avancé possible et le plus transparent en terme technique.

Pour la suite, nous envisageons de pouvoir utiliser la puissance de la technologie SEPAmail pour apporter des services complémentaires à très forte valeur ajoutée. Nous souhaitons pouvoir intégrer aux flux SEPAmail d’autres types d’informations comme des écritures comptables, des factures… Autant de données et de documents nécessaires pour l’e-commerçant mais aussi pour ses clients.

jeudi 20 décembre 2012

Communauté SEPAmail : SMOC

SMOC, c'est quoi ?


SMOC est l'acronyme de SepaMail Output Cryptographic, ce qui pourrait signifier Sortie chiffrée d'un SEPAmail.

C'est un composant open source en licence GPLv3 développé par Bishan Kumar Madhoo, société idSoft, selon une spécification réalisée par moi pour le compte du cabinet deciBI.

Qu'est-ce que cela fait ?


SMOC est un composant :
  • qui prend en entrée une missive SEPAmail et un fichier de configuration
  • qui génère une enveloppe SEPAmail, l'envoie en mode canonique (SMTP) et se synchronise avec une répertoire d'un compte imap corresponsdant au compte de l'expéditeur
C'est une librairie java que l'on peut inclure dans un projet java ou utiliser en ligne de commande.

Où peut-on le trouver ?

SMOC a été publié sur la plateforme de code google, sous le nom de code sepamail-smoc.
La page du projet se trouve ici
Le code source du projet est ici.


A-t-on le droit de l'utiliser ?

Le logiciel a été développé en langage java sous une licence d'utilisation open source (GPLv3).
Il utilise des composants et des bibliothèques qui sont toutes sous une licence open source.

Tout le monde peut donc utiliser tout ou partie de SMOC sous les conditions des licences d'utilisation, notamment en respectant le droit des auteurs.

Ce composant fait-il partie du standard de SEPAmail ?


Le standard n'a pas vocation à inclure des implémentations logicielles.
Donc ce composant ne fait pas partie du standard.

Existent-t-ils d'autres composants comme SMOC ?


Oui.
  • SMURF est un composant permettant de publiposter des missives SEPAmail depuis un système d'information d'entreprise.
  • SMIC est un composant de conversion croisée entre les deux formats missive (xml) et pdf (guide du créancier).
  • SMAC est un composant croisé entre le mode canonique et les modes flash
  • SMACK est un composant d'acquittement automatique de missive nominale
  • SMETH est une extension du client de messagerie thunderbird pour recevoir et envoyer des SEPAmail RUBIS. SMETH est utile pour concevoir de nouvelles applications, tester des applications existantes et, d'une manière générale, comme visionneuse d'un SEPAmail sur un environnement local

mardi 18 décembre 2012

Communauté SEPAmail : Solago

Nous continuons notre petit tour des entreprises de la communauté SEPAmail par SOLAGO, actuellement basée à Nantes et travaillant avec des entreprises de toute l'Europe. Olivier Jousselin répond à nos questions.

Quand a été créé Solago et dans quel contexte ?


Solago a été créée en 2003 pour assister des entreprises dans la conception et la mise en place de leur système d'information

Combien de collaborateurs, quels profils, quelles fonctions ?


Nous privilégions la qualité à la quantité. Actuellement, nous sommes deux, et nous travaillons également avec plusieurs consultants indépendants, notamment dans le domaine du logiciel libre.

Quels sont les principaux produits ou services développés et vendus ?


Nous ne faisons, ni développement, ni formation. Nous réalisons des études, définissons des architectures, et de façon générale assistons nos clients, de la conception à la mise en place de leurs projets.

Quel est le profil de vos clients, quelles sont vos références ?


Nos clients sont principalement des moyennes à grandes sociétés, même s'il nous arrive, sur des projets complexes, de travailler pour des PME, voire des TPE, ainsi que des acteurs publics.
Nous avons notamment travaillé pour Swisscom, l'OTAN, la Caisse Nationale d'Assurance Vieillesse, Orange, l'AFNIC ... mais aussi pour Nantes Métropole Développement et la mairie d'Ancenis -- et bien sûr pour SEPAmail.eu !

Quelles sont vos spécificités ?


Nous essayons de privilégier avant tout l'écoute du client, et la recherche d'une solution en termes de système d'information et non en termes purement techniques. Les projets complexes, que nous privilégions, nécessitent une solution complexe également, souvent multi-forme, qui ne peut jamais se ramener à un simple développement logiciel. La solution doit en outre être complétée par une prise en compte humaine et organisationnelle, que nous intégrons dans nos services..

Quel est votre lien à SEPAmail ?


Nous avons réalisé une étude de cadrage de ce système dès 2009. Très rapidement après cette étude, Cyril Vignet nous a demandé d'assurer une fonction d'expertise technique sur le projet, qui nous a amené à rédiger une grande partie de la documentation et à formaliser beaucoup de schémas XML. Nous jouons le rôle de committer de la norme depuis début 2011, et nous avons donc participé de très près, d'une part à la définition de RUBIS et de DIAMOND, d'autre part à la publication des versions 1202 et 1206.

Quel est votre implication dans la communauté SEPAmail ? Quelle évolution pour la suite ?


Depuis quelques mois, nous présentons SEPAmail à tous nos clients et partenaires, afin de leur montrer la richesse et la puissance de ce système. Nous écrivons (un peu occasionnellement il est vrai) sur ce blog, et surtout nous essayons d'imaginer et de définir de nouveaux usages pour SEPAmail, avec les applications existantes ou avec de nouvelles applications.

Nous jouons donc un rôle d'évangéliste, avec quelques autres personnes.

mardi 11 décembre 2012

Communauté SEPAmail : deciBI

DeciBI faisant partie des entreprises de la communauté SEPAmail, je me suis prété au jeu proposé à chacun des dirigeants et j'ai répondu à mes propres questions ;-)

Quand a été créé deciBI, dans quel contexte ?


L'entreprise deciBI est une sarl créée en 2007. Fondée par moi-même, deciBI est un cabinet de conseil en ingénierie de la donnée et en systèmes décisionnels.

L'ingénierie de la donnée, ce sont des compétences pour :
  • modéliser des objets métiers
  • optimiser des méthodes de calcul
  • évaluer la qualité d'informations
  • réaliser des traitements complexes autour de données
  • organiser le transport, l'archivage, l'accès à des données

Combien de collaborateurs, quels profils, quelles fonctions ?


Soucieux de la qualité des interventions de deciBI, j'ai regroupé autour de mon entreprise quelques spécialistes des systèmes d'information, pour la plupart indépendants.

 

Quels sont les principaux produits ou services développés et vendus ?


DeciBI ne développe pas de logiciels ou de produits. Elle participe à quelques projets libres, comme la traduction de l'interface de Pentaho Data Integration et elle suit les évolutions d'un produit innovant de modélisation de chaînes rédactionnelles : scenarii platform.

DeciBI répond à des besoins exprimés par des clients ou des prospects, généralement par de courtes missions d'analyse et de réalisation au forfait, avec le souci constant que ses clients soient satisfaits des livrables de la mission et ne soient pas dépendants de deciBI pour "l'après-mission".

Quels est le profil de vos clients, quelles sont vos références ?


Nous travaillons essentiellement avec des petites et moyennes entreprises ayant une forte croissance interne.
La plupart font de l'intermédiation entre des producteurs et des consommateurs et ont des usines de services web.

Nous cherchons à travailler au plus proche des hommes et de leurs projets.

Nous avons travaillé notamment pour eat on line (alloresto), royal first travel, le cneh, le guide des sensations, speedinfo (logiciel opensi), interpneu, spectaculaire, sipeo, l'acoms, solago, ...

Sur SEPAmail, deciBI accompagne les grandes banques du marché: BPCE, BNP Paribas, Crédit agricole et notamment les coordinateurs SEPAmail de chacune de ces banques.

Quelles sont vos spécificités ?


Nos intervenants travaillent à distance la plupart du temps.
Nous nous déplaçons dès que nécessaire mais nous ne croyons pas à la consultance en régie
DeciBI ne cherche, ni la croissance, ni les dividendes et, s'il y avait des salariés, deciBI serait certainement une coopérative.


Quel est votre lien à SEPAmail ?


Cyril Vignet a fait appel dès le début de l'idée SEPAmail au cabinet deciBI (avril 2008) pour travailler sur l'architecture fonctionnelle du standard et produire les premiers modèle de données.

DeciBI a mis en relation la CNCE avec Olivier Jousselin, société SOLAGO, pour assurer la fonction de commiter.

BPCE a demandé en juillet 2011 à deciBI de mettre en place un wiki pour la documentation puis assurer un contrôle de cohérence des diverses expérimentations et démonstrateurs qui avaient été réalisés.

DeciBI a proposé à l'automne 2011 l'idée d'un standard et une organisation autour de demandes de commentaires pour alimenter le groupe fonctionnel. C'était le début des SMIRKs qui permettent à tout un chacun de faire une proposition d'évolution du standard, notamment une nouvelle application ou une évolution de l'organisation.

SEPAmail.eu a demandé à deciBI d'animer deux groupes de travail :
  • un groupe sur l'application RUBIS en eCommerce
  • un groupe sur le mode canonique en relation avec la Banque de France

Quel est votre implication dans la communauté SEPAmail ?


Au printemps 2012, j'ai fait le tour de mes clients et de quelques uns de leurs fournisseurs pour présenter SEPAmail et apprécier leur intérêt pour ce type de fonctionnalité.

J'ai constaté qu'il manquait une formation et quelques petits composants pour que les chaînes SEPAmail se mettent en place rapidement et permettent à chacun de gagner en productivité.

J'ai donc monté quelques formations plutôt orientées fonctionnels (initiation à SEPAmail, exploration de SEPAmail, revue détaillée de SEPAmail) qui rencontrent pour le moment un très bon accueil.

J'ai aussi, en accord avec SEPAmail.eu, proposé ce blog et de développer quelques intergiciels sous licence opensource :
  • SMETH, une extension pour thunderbird permettant de lire et d'écrire des messages sepamail
  • SMURF, une publi-posteuse SEPAmail avec une prise canonique, ebics et fichier
  • SMIC, une prise croisée entre les formats SEPAmail pdf et xml
  • SMOC, une librairie permettant de construire une enveloppe SEPAmail, l'envoyer et se synchroniser avec un compte IMAP

Je fais ainsi partie des quelques évangélistes SEPAmail.

Quelle évolution pour la suite ?


D'autres composants sont en préparation : SMACK (un composant d'acquittement automatique), SMAC (une prise croisée falsh/canonique)

DeciBI souhaite continuer d'aider les entreprises qui souhaitent monter en puissance sur SEPAmail ou implémenter une solution.

samedi 8 décembre 2012

Revue de presse: novembre 2012

Voici les quelques articles que j'ai trouvés en novembre 2012 sur SEPAmail :
Sinon, la version 1206 du standard SEPAmail a été validée dans une version finalisée et récupérable ici.

vendredi 16 novembre 2012

L'horodatage et SEPAmail

Qu'est-ce que l'horodatage ?

L'horodatage consiste à associer une date et une heure à un événement, généralement dans le but de conserver l'information sur l'instant auquel une opération a été réalisée.

A quoi sert l'horodatage ?


L'horodatage peut servir à prouver l'existence d'une donnée avant une certaine date/heure.
L'horodatage permet aussi de réaliser des contrôles d'intégrité et de synchronisation des automates/agents d'un réseau.

Dans le réseau des adhérents de SEPAmail, l'horodatage des missives fait l'objet d'un article (août 2012) permettant de préciser les mécanismes de synchronisation et de contrôle des applications émettant et recevant des missives (composant fonctionnel SMART ou/et SMILE).
Il n'y a pas à ce jour de demande de commentaires (SMIRK) spécifique sur ce point.

Comment l'horodatage est mis en œuvre avec SEPAmail ?


L'horodatage est essentiellement mis en œuvre autour de deux idées :
  • les équipements doivent être synchronisés quotidiennement sur un serveur de temps reconnu
  • en réception, un contrôle des missives est réalisé. Si la missive reçue a été émise dans le futur pour le récepteur, alors un traitement spécifique est réalisé. Un écart de 3 seconde est autorisé avec un avertissement au sein de l'acquittement. Au delà de ces trois secondes, la missive n'est pas transmise et l'acquittement est négatif en donnant la raison de cette non transmission.
Le groupe "Norme SEPAMail" n'est pas allé plus loin dans ses recommandations de mise en œuvre car le sujet de l'horodatage évolue rapidement actuellement et il est plus simple de faire référence à l'état de l'art pour ne pas être rapidement désuet dans ses écrits.

Pour aller plus loin


Le sujet évolue rapidement et on peut, pour aller plus loin explorer les sujets ci-dessous :
  • la spécification de SNTP (Secure Network Time Protocol)
  • la différence entre une horloge matérielle et une horloge système
  • les différences entre les mécanismes de synchronisation d'horloge (avec ou sans dérive de l'horloge)
  • les services d'horodatage par huissier de justice
  • les travaux sur l'horodatage de la FNTC (fédération nationale des tiers de confiance)

mardi 13 novembre 2012

Vocabulaire SEPAmail : noms de code en "SMxxx"

Que sont donc ces noms de codes en quelques lettres commençant par SM ?
La question m'est souvent posée.

L'idée est venue naturellement du mot SEPAmail et du premier implémenteur de SEPAmail, la société StreamMind.
Les deux noms étaient composés de deux mots commençant par S et M.

Pourquoi donc ne pas prendre des mots courts en anglais commençant par SM pour nommer des concepts ou des composants logiciels de la communauté SEPAmail.

L'idée était lancée.
Cela a commencé avec SMART et SMILE qui sont des concepts ayant permis de distinguer la même fonction au sein du réseau d'adhérents et en dehors du réseau d'adhérents.
Puis, de façon un peu narquoise, la SMIRK a été baptisée afin de répondre à quelques remarques sur la confusion entre les RFC de l'IETF et les RFC de SEPAmail.

La liste des codes 


Voici la liste des codes que je connais à ce jour, classée par ordre alphabétique:
  • SMART, terme générique pour désigner, dans le standard, un composant implémentant le protocole d'émission et de réception des enveloppes SEPAmail au sein du réseau des adhérents. C'est l'acronyme de SepaMail Acknowledgment, Routing and Transfer et le mot peut signifier en anglais chic ou élégant.
  • SMETH, implémentation d'une extension pour le client de messagerie thunderbird couvrant une partie du protocole SEPAmail. C'est l'acronyme de SepaMail Extension THunderbird et le mot peut signifier suée ou bruine en anglais
  • SMITE, jeux de test pour mettre en commun des jeux de données à des fins de déboguage des implémentation. C'est l'acronyme de SepaMail, I want TEst et le mot peut signifier frapper ou châtier en anglais.
  • SMILE, terme générique pour désigner dans le standard, un composant implémentant le protocole d'émission et de réception des enveloppes SEPAmail en dehors du réseau des adhérents (par exemple entre un adhérent et son client utilisateur). Le SMILE et le SMART sont deux instances fonctionnelles assez similaires sauf pour l'authentification des acteurs. Il n'y a pas d'acronyme validé actuellement et cela ferait sourire que je donne ici son sens en anglais
  • SMIRK, demande de commentaires soumise à la communauté pour discussion et validation. C'est l'acronyme de SepaMail Internal Request for Komment et le mot peut signifier narquois en anglais.
  • SMUDGE, implémentation d'une synchronisation entre un gestionnaire de version et la documentation SEPAmail en ligne. C'est l'acronyme de SepaMail UpDate GEnerator et le mot peut signifier bavure ou tâche en anglais.
  • SMURF, implémentation d'un publiposteur SEPAmail/RUBIS (JADE en cours de spécification) en sortie d'un ERP. C'est l'acronyme de Sepa Mail Universal Resource Formater et le mot peut signifier Stroumpf en anglais
Il existe aussi, qui ne correspondent pas à des mots anglais :
  • SMAPI, un type de missive d'interfaçage. C'est l'acronyme de SepaMail Application Programming Interface.
  • SMIC, implémentation d'une prise croisée entre les deux formats pdf et xml de la missive (guide SEPAmail de l'entreprise). C'est l'acronnyme de SepaMail Interface Cross.
  • SMOC, implémentation de l'enveloppe SEPAmail, de l'envoi et de la synchronisation avec un compte IMA. C'est l'acronyme de SepaMail Output Cryptographic
  • SMAC, implémentation d'une prise croisée entre le mode flash et le mode canonique
  • SMACK, implémentation d'un composant d'acquittement automatisé

Je suis preneur de tout code que j'aurais oublié ou que je ne connaîtrais pas pour l'ajouter à la liste ci-dessus.
Il reste d'autres mots en anglais commençant par SM: smash, smala, small, smear, smell, smelt, smith, smock, smog, smoke, smooth, smug, smut...

mardi 6 novembre 2012

SEPAmail : revue de presse octobre 2012

SEPAmail a fait l'objet d'un communiqué de presse jeudi 25 octobre.

Pour information et mémoire, voici ce communiqué et les réactions dans quelques médias numériques :



jeudi 11 octobre 2012

Foire aux questions n°2

Voici quelques unes des questions posées fréquemment lors de cette rentrée.

Que signifie la mention 1206 concernant le standard SEPAmail ?


Quand vous consultez la documentation de SEPAmail, vous trouvez une mention 1206 ou 1202 pour le standard/norme.
Sans m'étendre sur les différences d'interprétation possibles entre les termes standard et norme, la mention 1206, elle, est un numéro de version de la forme YYMM où YY est l'année et MM le mois.
Le standard 1206 est donc la version publiée en juin 2012 et le standard 1202 celui publié en février 2012.
La version 1202 était le premier standard officiel émis par le groupe de travail études et norme de l'organisation SEPAmail.
Il est publié depuis février 2012 sous licence creatives commons paternité, partage des conditions initiales à l'identique et on retrouve l'ensemble des auteurs et contributeurs sur cette page.

Quelles sont les changements entre la version 1202 et la version 1206 du standard SEPAmail ?

La version 1206 décrit les changements ci-dessous:
  • ajout d'une carte de visite SEPAmail au format retravaillé et unifié, la qxCard
  • ajout d'un message dans RUBIS pour l'inscription au service, ne dépendant plus de l'écosystème secure (message activation.enroll)
  •  ré-écriture de la demande de commentaire SMIRK autour de la missive (SMIRK MIS1202)
  • écriture d'une SMIRK autour de l'identifiant des grands créanciers SEPAmail, l'ICQX (SMIRK REF1201)
  • des règles précisant l'horodatage des systèmes et son importance dans le standard
 et cette version a permis d'apporter une contribution applicative:
  • DIAMOND, la vérification d'identité bancaire (en cours de validation)

Quelles sont les implémentations logicielles de SEPAmail ?

Selon mon niveau d'information, le standard SEPAmail est implémenté (en partie) :
  • dans la suite logicielle éditée par la société StreamMind, autour du composant SEPAplug
  • dans l'application mobile sepamail pour Android éditée par la société AriadNext, en client d'un serveur SEPAplug
  • dans le composant opensource SMURF, sorte de publiposteur de missive contenant une demande de réglement RUBIS
  • dans le composant opensource SMIC, convertisseur entre les deux formats xml et pdf du guide créancier
  • dans un composant en cours de développement par la société Lyra Networks

Est-il possible d'utiliser le standard SEPAmail en dehors du réseau SEPAmail ?


On entend par réseau SEPAmail la communauté des adhérents SEPAmail se conformant à la charte de l'adhérent.
Ces adhérents permettent à leur client d'utiliser SEPAmail pour échanger des messages standardisés.

Ces adhérents jouent le rôle de :
  • relai d'acheminement du message en émission et en réception
  • relai d'authentification de leur client
  • articulation vers un paiement si le client le demande et le message permet l'initiation

Il est tout à fait possible d'utiliser le standard SEPAmail en dehors du réseau SEPAmail pour un adhérent ou un non adhérent, c'est à dire les règles de structuration de l'information et d'organisation des échanges.

Cependant, c'est au sein d'une communauté organisée avec un juge arbitre et des intérêts à ne pas tricher sur l'acheminement et l'authentification que SEPAmail prend tout son sens.

Pourquoi utiliser le standard SEPAmail dans les échanges d'information ?


Le standard SEPAmail permet de valoriser l'échange d'information de plusieurs manières :
  • il assure une chaîne d'authentification mutuelle qui assure une authentification distante de bout en bout par relai
  • il permet la confidentialité de l'échange sur le réseau Internet (confidentialité du contenu mais aussi de l'adressage)
  • il permet l'articulation avec un paiement
  • il permet l'automatisation (et dématérialisation), par la structuration de tous les flux
  • il permet aussi l'articulation avec des êtres humains organisés , par l'adjonction d'une pièce jointe lisible par l'homme (principe du HUman ReadAble HURA)
  • il s'adosse à des relations commerciales existantes entre des adhérents et des utilisateurs et ajoute un accord entre les adhérents avec l'adhésion au réseau et à la charte de l'adhérent

Est-ce que SAPPhire est une application SEPAmail ?


Les applications SEPAmail ont, pour le moment, toutes un nom de pierre précieuse.
Cependant, toutes les pierres précieuses ne sont pas des applications SEPAmail.
SAPPhire n'est pas une application SEPAmail mais un travail autour de l'authentification et notamment une proposition fonctionnelle de simplification du paradigme pour pouvoir le partager à plusieurs adhérents.
On trouve une présentation sur ce billet.

Qui rédige le standard SEPAmail ?

Le standard SEPAmail est validé par un comité de pilotage sur proposition du groupe de travail études et norme.
Ce groupe de travail relit les propositions émanant de la communauté sous la forme de demandes de commentaires, appelées au sein de la communauté SMIRK (SepaMail Internal Request for Komment).

Le standard est donc une œuvre collective, coopérative sur l'organisation permettant une messagerie articulée.

Qui utilise aujourd'hui SEPAmail ?

SEPAmail est utilisé actuellement par des banques françaises pour expérimenter le concept avec des collaborateurs, des clients professionnels et particuliers sur l'application RUBIS.
Il est prévu d'expérimenter GEMME et DIAMOND rapidement.


vendredi 5 octobre 2012

Communauté SEPAmail : SMIC

SMIC est l'acronyme de Sepa Mail Interface Cross.

A quoi cela sert ?


Le standard SEPAmail propose un format appelé missive, contenant un signifiant pour les automates au format (APU ou Automate Programmable doué d'Ubiquité, selon Michel Volle), lui-même contenant un document lisible par un être humain au format pdf (EHO ou Être Humain Organisé, selon Michel Volle).

Pour permettre à des logiciels d'entreprises de produire un document contenant la missive, donc, en quelque sorte, le contraire du format précédent, le standard SEPAmail définité dans le guide de l'éditeur de logiciel un format pdf contenant une missive xml.

SMIC est un composant de conversion croisée entre les deux formats missive (xml) et pdf (guide du créancier).

Où le trouver ?


SMIC a été publié sur la plateforme de code google, sous le nom de code sepamail-smic.
La page du projet se trouve ici.

Les spécifications fonctionnelles sont ici.
Le code source du projet est ici.

A-t-on le droit de l'utiliser ?


Le logiciel a été développé en langage java sous une licence d'utilisation open source (GPLv3).
Il utilise des composants et des bibliothèques qui sont toutes sous une licence open source.

Tout le monde peut donc utiliser tout ou partie de SMIC sous les conditions des licences d'utilisation, notamment en respectant le droit des auteurs.

Ce composant fait-il partie du standard de SEPAmail ?


Le standard n'a pas vocation à inclure des implémentations logicielles.
Donc ce composant ne fait pas partie du standard.

Existent-t-ils d'autres composants comme SMIC ?


Oui.
  • SMURF est un composant permettant de publiposter des missives SEPAmail depuis un système d'information d'entreprise.
  • SMOC est un composant qui constitue une enveloppe SEPAmail, l'envoie et se synchronise avec un compte IMAP


mardi 18 septembre 2012

SEPAmail: onze principes


Voici quelques principes qui, à mon sens, fondent l'approche SEPAmail et structurent le standard:
  • SEPAmail est une messagerie au minimum 4 coins, 2 utilisateurs, 2 adhérents, couverts par au moins trois contrats
  • SEPAmail permet des échanges de dialogues structurés formalisés au sein d'applications, qui, lorsqu'elles sont éditées par la norme, ont une portée globale (à tous les adhérents)
  • SEPAmail met en œuvre un procédé d’accusé de réception systématique (l'acquittement) qui est garanti par les adhérents. Cet accusé de réception induit l'authentification des adhérents et l'intégrité des messages échangés
  • SEPAmail permet de garantir l'authentification des personnes physiques liés à un identifiant (le qxban). Le transcodage entre un IBAN et un QXBAN est toujours assuré par l'adhérent émetteur du QXBAN. L'IBAN est ainsi protégé dans le dialogue entre les utilisateurs, même lorsque un message articule un paiement
  • SEPAmail permet, par la vertu du modèle 4 coins et de la chaîne contractuelle, à un adhérent de proposer à son client, l'utilisateur SEPAmail, des services autour du flux quand ce flux est vu par l’adhérent : enrichissement du flux, vérification, articulation d'un paiement (le rôle des établissements de paiement est un plus pour l'utilisateur)
  • SEPAmail garantit à l'utilisateur que l'adhérent doit respecter des règles et qu'il y a un juge arbitre de ces règles quand le protocole ne permet pas d'exclure intrinsèquement les tricheurs. Le juge arbitre est la Banque de France quand on parle de la loi française et c'est le scheme quand on parle de la charte des adhérents SEPAmail.
  • tous les messages constitutifs d'une application sont autoporteurs de l'information pour qu'une partie du dialogue permette de réaliser l'action suivante
  • SEPAmail ne présume pas le canal d'échange de l'information entre un adhérent et son client, l'utilisateur et notamment le moyen de l'authentification de l'utilisateur par l'adhérent
  • l'extension de norme à la relation "pair à pair" doit être possible
  • le modèle 4 coins peut devenir un modèle 5,6 coins ou plus mais pas un modèle 2 ou 3 coins dans le cadre communautaire, car c'est lui qui garantit beaucoup des principes ci-dessus et ces modèles qui rendent la confiance à l'utilisateur (les avocats, les médecins, les notaires) et oblige à un juge arbitre clair protégeant les utilisateurs
  • sepamail doit pouvoir fonctionner nativement en mode canonique avec les infrastructures et les protocoles de messageries électroniques standards

jeudi 13 septembre 2012

Communauté SEPAmail : SMURF

SMURF est l'acronyme de Sepa Mail Universal Resource Formater.

A quoi cela sert ?

Supposons qu'un utilisateur SEPAmail, client créancier, dispose d'un logiciel ERP qui lui permet de consulter la fiche de chacun de ses clients. Pour utiliser le service RUBIS, il a besoin de pouvoir envoyer ses demandes de règlement au format RUBIS sur la prise SMILE de sa banque.
Le composant SMURF va lui permettre de générer automatiquement le document pdf au format SEPAmail qu'il peut ensuite envoyer sur la prise bancaire SEPAmail SMILE, soit directement (canal web service), soit via un client de messagerie S/Mime (canal messagerie).

Où le trouver ?

Smurf a été publié sur la plate-forme google code sous le nom de code sepamail-smurf.
La page du projet se trouve ici.

Comment le tester ?

Pour tester SMURF, le plus simple est de télécharger la dernière version exécutable ici puis de décompresser l'archive quelque part sur votre système puis de lancer Smurf.sh (pour MacOs ou GNU/Linux) ou Smurf.exe (pour WinOS).

Pour le tester depuis les sources, il faut récupérer le projet sur le gestionnaire de version de la plate-forme google, puis exécuter avec ant (par exemple) le fichier build à la racine du projet. Un environnement java 1.7+ est requis.
Remarque : la visualisation des pdf dans SMURF ne fonctionne qu'avec un environnement d'exécution sun/oracle 1.7 (incompatibilité de la visionneuse jpeg dans le projet icedtea avec openjdk, en cours d'analyse pour résolution)

A-t-on le droit de l'utiliser ?

Le logiciel a été développé dans le cadre d'une mission autour de SEPAmail en langage java sous une licence d'utilisation open source (GPLv3).
Il utilise des composants et des bibliothèques qui sont toutes sous une licence open source comme décrit dans ce fichier.
Les créanciers peuvent donc utiliser tout ou partie de SMURF sous les conditions des licences d'utilisation, notamment en respectant le droit des auteurs

Où peut-on trouver de la documentation ?

Plusieurs documents se trouvent dans l'espace google code :
  • une documentation orientée intégrateur
  • une documentation orientée développeur
  • les spécifications des différentes versions du composant

Ce composant fait-il partie du standard de SEPAmail ?

Le standard n'a pas vocation à inclure des implémentations logicielles.
Donc ce composant ne fait pas partie du standard.
Cependant, c'est une implémentation au code source ouvert et ré-utilisable, faisant référence pour la communauté des adhérents et utilisateurs de SEPAmail.

Existent-t-ils d'autres composants comme SMURF ?


Oui.
  • SMIC est un composant de conversion croisée entre les deux formats missive (xml) et pdf (guide du créancier)
  • SMOC est un composant qui constitue une enveloppe SEPAmail, l'envoie et se synchronise avec un compte IMAP



vendredi 17 août 2012

Application SEPAmail : JADE

JADE permet pour un utilisateur SEPAmail d'envoyer un avis de virement à un autre utilisateur SEPAmail.
Ces utilisateurs pourraient être appelés :
  • l'aviseur (ou le donneur d'ordre)
  • l'avisé (ou le bénéficiaire)
JADE permet à l'avisé de refuser ou d'accepter le virement si l'aviseur le propose.

Qu'est-ce qu'un avis de virement ?

Un avis de virement est une information :
  • qu'un virement (SEPA credit transfert)
  • d'un montant précisé (sans limite de montant)
  • dans une devise précisée
  • va être émis
  • à une date précise
  • avec un motif précisé
  • et une référence précisée ou non à la main de l'aviseur

Le virement est-il automatique ?

D'une part, l'aviseur peut automatiser l'enclenchement du virement.

Ensuite, l'aviseur peut conditionner le virement, s'il le souhaite, à l'acceptation de l'avisé, condition transmise à l'avisé.

Enfin, le virement est conditionné par les conditions du compte de l'aviseur au moment de l'enclenchement du virement. En cas d'insuffisance sur le compte, le virement peut ne pas être émis.


Dans la majorité des cas, le virement sera donc automatique mais cela n'est pas garanti pour tous les cas.

Quel est l'intérêt de JADE ?

JADE permet de dématérialiser en toute sécurité les avis de virement en joignant à cet avis une pièce justificative de la raison du virement.

Dans la vie de tous les jours, il y a beaucoup de cas d'usage de ce besoin, par exemple en relation entité économique à particulier :
  • la transmission sécurisée et confidentielle des fiches de salaires par un employeur à ses employés
  • la transmission sécurisée et confidentielle des avis de remboursement de la CPAM à ses assurés ou les professionnels de santé
  • la transmission sécurisée et confidentielle des indemnités de chômage aux allocataires
  • la transmission sécurisée et confidentielle des allocations familiales à ses allocataires ou aux partenaires (centres de vacances et de loisirs pour les bons cafs)
mais aussi dans le sens particulier à entité économique tout paiement par virement sur sollicitation autre que SEPAmail, notamment les sollicitations directes.

On peut imaginer, par exemple, le paiement d'une contravention au tarif réduit (sans contestation) par virement.


L'intérêt de JADE est de laisser la main à l'aviseur (payeur) tout en rassurant l'avisé (le futur payé) sur l'authenticité des conditions de virement que l'aviseur met en œuvre.

Comment cela fonctionne ?

Simplement, comme beaucoup de chose avec SEPAmail...

JADE utilise l'écosystème credit.activation et deux messages :
  • CreditAdvise, avertissement d'une opération de virement au crédit du destinataire à venir à date fixe
  • CreditReply, réponse facultative selon les cas au message précédent, avec l'action suivante pour la banque de l'émetteur du message


Est-ce déjà standardisé et expérimenté ?

Non.
Cette application est en cours de discussion (donc de standardisation) et il n'est pas prévu de l'expérimenter dans la phase actuelle entre les 5 premiers adhérents SEPAmail.

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 30 juillet 2012

SAPPhire

SAPPhire n'est pas une application SEPAmail malgré son nom de pierre précieuse.
SAPPhire est une proposition fonctionnelle simplifiée autour de l'authentification.
SAPPhire dépasse donc largement le projet SEPAmail même si :
  • SAPPhire utilise dans son échange d'information des messages SEPAmail,
  • SEPAmail peut utiliser SAPPhire (plutôt en extension de norme) pour permettre l'authentification à distance d'un utilisateur sur une interface, par exemple depuis son smartphone.

SAPPhire concrètement, ce sont des niveaux pour simplifier la compréhension

SAPPhire propose trois niveaux différents :
  • SAPPhire 1 est une authentification simple à un facteur SAPPhire
  • SAPPhire 2 est une authentification forte à deux facteurs SAPPhire
  • SAPPhire 3 permet les conditions de la signature numérique présumée fiable
Ainsi :
  • SAPPhire 1 permet la consultation de messages
  • SAPPhire 2 permet des actions qui engage le client (par exemple un virement ou l'envoi d'un courriel)
  • SAPPhire 3 permet de signer un document
Les facteurs SAPPhire ne sont pas nombreux  mais pourront dans le futur augmenter en nombre :
  • un certificat logiciel installé sur l'environnement local de confiance protégé par un PIN
  • un certificat matériel en présence de l'environnement local de confiance
  • un certificat matériel protégé par un PIN
Bref, l'idée derrière SAPPhire, c'est qu'au delà de la complexité portée par la cryptographie et l'authentification, une ergonomie utilisateur est possible tout en respectant l'état de l'art, les directives nationales et européennes.
Il devient possible, en adoptant SAPPhire massivement, de dire le niveau SAPPhire de chacune des fonctions demandées par un service métier.
L'infrastructure, la sécurité et, plus généralement, les services informatiques des entités économiques pourraient alors proposer le support des niveaux SAPPhire plutôt que de devoir inventer à chaque nouveau projet le cadre d'intervention de l'authentification.

La petite histoire

Voici la petite histoire, celle qui explique la confusion pour certains autour de SAPPhire.
SAPPhire a été décrit au début comme l'application SEPAmail permettant d'échanger des éléments de sécurité, notamment des clés publiques.
L'eco-système secure a été inventé et associé à SAPPhire puisqu'il contient les messages d'échange d’éléments de sécurité.

Le premier démonstrateur

Dans le cadre de SEPAmail, un premier démonstrateur smartphone a été mis en œuvre par le groupe BPCE et les sociétés AriadNext et StreamMind démontrant qu'un utilisateur de smartphone pouvait s'authentifier à un service bancaire sans à avoir à passer par l'agence et sans forcément devoir recevoir un certificat matériel personnalisé.
Ce démonstrateur repose sur une application Android téléchargeable depuis son dépôt certifié. L'application :
  1. s'installe
  2. génère un biclé logiciel,
  3. génère un code PIN protégeant l'accès et le stockage de ce certificat
  4. envoie la clé publique à un serveur bancaire à l'aide d'un message SEPAmail sur le réseau IP (non sécurisé)
  5. cette clé n'est activée que lorsque l'utilisateur demande cette action sur un DAB/GAB avec une authentification forte grace à sa carte de retrait ou sa carte bancaire et elle ne l'est que pour le téléphone enregistré
  6. le biclé peut alors être utilisé dans le cadre d'une authentification à distance
SAPPhire 1 était ainsi né et une idée assez originale et élégante est venu de la rencontre entre les différents métiers de la banque (juridique, flux, authentification, moyens de paiement : utiliser le DAB et son authentification pour valider, par rebond et sur un autre canal, le niveau d'authentification de la carte bancaire.

Le deuxième démonstrateur

Les possibilités de trouver sur le marché des jetons cryptographiques matériels se connectant facilement à un smartphone et peu cher ont donné l'idée du deuxième démonstrateur, réalisé par le groupe BPCE et la société AriadNext : connecter l'application déjà développée avec un certificat matériel pour augmenter le niveau de sécurité et permettre deux nouveaux niveaux : SAPPhire 2 et SAPPhire 3.
Le démonstrateur a été réalisé avec des cartes NFC dont une de paiement et à démontré l'ergonomie possible pour l'utilisateur final des niveaux SAPPhire.
Les trois premières étapes du démonstrateur précédent ont donc été adaptées à un biclé matériel.

SAPPhire : quel avenir ?

SAPPhire est une simplification réelle d'un domaine devenu trop technique et trop complexe pour être réellement utilisé correctement par les éditeurs, les développeurs et les concepteurs de solutions logicielles utilisant largement de l'authentification à distance.
Si SAPPhire est compris et adopté comme un standard fonctionnel de spécification de l'authentification, alors les discussions vont aussi devenir plus simples autour de tous les standards utilisant l'authentification.
Gageons qu'un des géants du web ou une communauté amenée à s'imposer internationalement comme SEPAmail comprendra et utilisera SAPPhire.

mardi 24 juillet 2012

Vocabulaire SEPAmail : l'ICQX

A partir de la version 1206, SEPAmail utilise un nouvel identifiant dénommé ICQX, pour "Identifiant Créancier QX" -- rappelons que QX est le pseudo-code pays identifiant le Scheme SEPAmail, utilisé notamment dans les QXBAN.

Voici quelques éléments répondant aux principales questions se rapportant à cet identifiant.

1. Qui peut disposer d'un ICQX ?

Toute personne morale. Toutefois, cet identifiant n'a réellement de sens que si cette personne morale intervient comme créancier dans l'une des applications de SEPAmail.
Bien que l'ICQX soit inspiré de l'ICS (Identifiant Créancier SEPA), il ne lui est aucunement relié. Il n'est d'ailleurs pas nécessaire d'avoir un ICS pour demander un ICQX, ni inversement.

2. Que contient un ICQX ?

Techniquement, c'est un identifiant de 35 caractères alphanumériques, contenant une référence au pays d'appartenance (légale) du créancier. Sémantiquement, il ne contient rien d'autre. Toutefois, en son rôle d'identifiant (cf. l'intéressant point de vue de Michel Volle à ce sujet dans un autre article), il permet d'accéder à toutes les informations significatives pour un créancier personne morale : identification de la personne morale, éléments bancaires ....

3. Comment obtenir un ICQX ?

Seul le Scheme, ou sa déclinaison locale, le QXOO, peut attribuer un ICQX. Toutefois, le créancier souhaitant en obtenir un doit obligatoirement passer par sa banque -- ou l'une de ses banques, qui jouera le rôle d'intermédiaire avec le Scheme ou le QXOO. Pour obtenir un ICQX, l'entreprise doit fournir des éléments d'identification légaux (RCS, adresse du siège ...), dont la banque a la responsabilité de vérifier l'exactitude (authentification), et qui constituent une ICQXCard.
La création de l'ICQX entraîne l'inscription du créancier dans le référentiel ICQX@SCHEME de SEPAmail, à partir duquel le Scheme fournira, à leur demande, les informations nécessaires aux membres du réseau.

4. J'ai un ICQX -- et maintenant ?

Maintenant, cet ICQX sert d'identifiant unique dans l'ensemble du système SEPAmail. Il est sûr, puisqu'il ne correspond à rien en-dehors de SEPAmail. Il est fiable, puisque votre banque a validé votre identité. Il vous permet donc de transmettre, grâce à un seul identifiant, une "carte d'identité" complète. Vous pouvez maintenant vous abonner aux services proposés par SEPAmail (inscription RUBIS, GEMME émission ...) en fournissant simplement cet ICQX. Pour chaque service, vous disposerez d'une ServiceCard, strictement interne à SEPAmail, qui servira à vous mettre en relation avec les autres utilisateurs de ce service.

5. J'ai plusieurs banques. Dois-je avoir plusieurs ICQX ? Puis-je en avoir plusieurs ?

Non. L'ICQX est unique, et vous devez donc choisir la banque par le biais de laquelle vous le demandez. Si vous changez de banque, vous devrez demander une mise à jour à la nouvelle banque.
En revanche, lorsque vous vous inscrivez à un nouveau service, vous pouvez choisir le QXBAN associé, qui peut donc ne pas correspondre à la même banque.

6. Mon ICQX est-il éternel ? Puis-je le supprimer ?

L'ICQX a une durée de validité, prévue contractuellement entre votre banque et vous. A l'issue de cette durée, il devra être prorogé, ce qui implique notamment une nouvelle vérification des éléments d'identité.
Il n'est pas possible de supprimer un ICQX. En revanche, vous pouvez désactiver tous les services associés, ce qui, dans la pratique, reviendra au même.

7. Mon ICQX va-t-il être revendu à d'autres sociétés ?

Non, l'ICQX sert uniquement de façon interne à SEPAmail, et n'a pas vocation à être fourni ou vendu à qui que ce soit.

vendredi 20 juillet 2012

Le dispositif SEPAmail au cœur d'une architecture de messagerie

Le dispositif SEPAmail au cœur d'une architecture de messagerie


L'architecture schématisée ci-dessus s'articule autour du mode canonique :
  • un composant recevant et envoyant les courriels (MTA)
  • un composant chiffrant et déchiffrant, relié à un composant d'authentification et une infrastructure à clé publique (PKI)
  • un composant SMART mettant en œuvre le protocole SEPAmail autour de la missive (décrit dans le document SMIRK MIS1101, remplacé par SMIRK MIS1202 fin juillet 2012)
La liaison avec le système d'information se fait par le SMART.
La liaison avec le reste du monde via des équipements de protection, type pare-feu.

Le mode flash est sobre et ne s'occupe que d'interfacer entre le reste du monde et le composant MTA une chaîne de type web-service.

Charge à la chaîne canonique de savoir traiter en priorité les flux reçu ou émis en mode flash.

Des liaisons facultatives sont à prévoir entre le SMART et :
  • un module d'horodatage externe et certifié si besoin
  • un module de contrôle de type juridique si besoin

 

L'information échangée de composants à composants

Dans cette architecture, l'information échangée est, tout au long de la chaîne :
  • une enveloppe SEPAmail, c'est à dire une enveloppe SMTP
    • SMIME entre le composant crypto et le reste du monde (composant MTA compris)
    • SMTP déchiffrée entre le composant crypto et le SMART
  • Et entre le SI et le SMART :
    • une missive SEPAmail, c'est à dire un flux xml au standard missive de SEPAmail.
L'enveloppe SEPAmail et la missive SEPAmail sont des blocs d'information dotés d'un entête.
On peut donc passer les arguments au sein de ces entêtes.

Le bloc d'information est ainsi porteur de toute l'information utile et il n'y a pas d'API compliqué à prévoir entre ces composants autres que la spécification des entêtes et leur utilisation au sein du Système d'information cible des spécifications d'intégration de SEPAmail.

Quelques éléments de sécurité

Le composant SMART et le composant CRYPTO sont certainement à protéger au sein d'un segment de réseau spécifique à SEPAmail.

Cette organisation ne remet pas en questions les règles de sécurité autour du composant MTA, notamment son emplacement et le filtrage associé au flux SMTP.
Si un responsable de la sécurité du système d'information cible désire associer des règles spécifiques au flux SEPAmail, il pourra le réaliser sans souci sur l'adresse de courriel qui est spécifique :
  • nom de domaine sepamail.eu, 
  • sous-domaine pouvant être authentifié en DKIM et soumis à des règles SPF, 
  • adresses de courriel définies et spécifiques à SEPAmail
Le mode flash est associé au mode canonique et la sécurité spécifique du transactionnel à temps court peut ainsi reposer sur quelques règles communes.

Des anti-virus peuvent être habilement utilisés à plusieurs endroits et notamment sur le flux chiffré avec le reste du flux SMTP en entrée de SI puis après (et avant) le déchiffrement.

Le cœur du système d'information n'est exposé qu'à un flux xml filtré, authentifié (signature), intègre (signature), valide (schéma xml) et vérifié (anti-virus).

L'exploitation du dispositif

Le dispositif décrit peut être exploité de la façon habituelle pour l'entreprise, charge à l'intégrateur de la solution d'ajouter les prises (ou sondes) entre les nouveaux composants et le composant d'exploitation pour alerte d'une défaillance opérationnelle.

Les fonctions du composant SMART

Que fait donc le SMART dans cette configuration ?

Il implémente les fonctions non encore réalisées autour de la missive :
  • gestion du flux de travaux (workflow) en émission de missive nominale, incluant :
    • l'attente de l'acquittement
    • le renvoi éventuel de la missive
    • l'escalade si la missive n'est pas acquittée dans les temps prévus
  • gestion de l'acquittement en réception de missive nominale
    • directement si c'est possible
    • en délégation de l'application métier cible du message sinon
  • dépôt des missives en direction des applications métiers
  • récupération des missives provenant des applications métiers
  • pilotage des commandes autour de la missive

Ceci est décrit plus spécifiquement ici dans le document SMIRK MIS1101 remplacé par SMIRK MIS1202 fin juillet 2012.

mardi 10 juillet 2012

Vocabulaire SEPAmail : le QXBAN

Le qxBAN est l'identifiant de l'utilisateur SEPAmail.
Cet identifiant répond à la norme des IBANs (iso 13616) avec un code pays "QX", code pays que l'iso 3166-2 a assigné pour des usages privés.

Sa génération est décrite dans la documentation de SEPAmail. Elle est réalisée par l'adhérent SEPAmail pour le compte de son client. C'est l'adhérent qui conserve le transcodage QXBAN<->IBAN.

Le standard SEPAmail propose donc nativement de protéger l'IBAN ou les autres identifiants bancaires (PAN) en généralisant l'utilisation d'un alias qui n'est pas utilisable directement dans les circuits monétiques.
un exemple de RIS2D
image issue de la documentation
sous licence CC-BY-SA

Le qxBAN est repris dans une forme graphique, un code barre 2D de type datamatrix qui s'appelle le RIS2D (Relevé d'Identité SEPAmail 2D).

Ce RIS2D évolue pour se conformer à la norme 2D-DOC, une norme d'authentification statique des documents.

Les avantages du qxBAN

Le qxBAN présente les avantages suivants :
  • le qxBAN peut être échangé entre tous les acteurs sans risque de fraude monétique puisque le transcodage qxBAN/iBAN est toujours réalisé par le producteur du qxBAN avec une source authentifiée pour son propre usage de l'iBAN
  • il n'est pas possible de déduire un iBAN depuis un qxBAN, par construction aléatoire du qxBAN
  • le BIC est inclus dans le qxBAN, le qxBAN est donc autoporteur de toute l'information de routage.
  • le qxBAN est un identifiant international, puisqu'il n'inclut pas le pays dans sa définition
  • le qxBAN peut être lié à plusieurs comptes bancaires, voire à aucun compte si l'adhérent n'est pas une banque

Les ambiguïtés autour du qxBAN

Le qxBAN est une notion importante de SEPAmail car il permet la protection de l'IBAN qui s'expose de plus en plus avec la généralisation de SEPA.
Cependant, le qxBAN ne lève pas les ambiguïtés suivantes :
  • il ne faut pas confondre l'identifiant de l'utilisateur SEPAmail au sein du réseau SEPAmail avec la personne physique (authentifiée par les adhérents SEPAmail comme l'utilisateur SEPAmail)
    • pourra-t-il y avoir plusieurs personnes physiques ayant le droit d'utiliser un même qxBAN ?
    • pourra-t-il y avoir un qxban sans compte IBAN ou sans carte PAN associés ?
  • il ne faut surtout pas que le qxBAN, qui sera largement diffusé, soit utilisable dans un réseau de paiement tel quel ou en compensation. C'est son principe qui serait remis en question. Or, la tentation est forte pour certains qui ne veulent pas du modèle 4 coins
  • le qxBAN n'est pas un identifiant unique que l'on conserve quand on change d'adhérent SEPAmail
  • le qxBAN, dans sa forme actuelle, présente une limite d'utilisation par le nombre de qxBAN possibles par BIC. Il y a, pour chacun des BIC, 3,4x1029 possibilités pour le moment, ce qui laisse venir mais il ne faut pas que l'adhérent en profite pour générer autre chose que de l'aléatoire. Certains adhérents  ont déjà pensé générer le qxBAN par une fonction de hachage à sens unique de l'IBAN ou encore segmenter leur clientèle en réservant quelques caractères parmi ces 19 positions. Toutes ces idées vont à l'encontre du principe premier du QXBAN. C'est un identifiant ne portant aucun sens autre que le BIC.
Pour finir ce billet, citons Michel Volle qui dans son livre "de l'informatique" parle de l'identifiant en ces termes :
"Il importe [...] de définir correctement la population dont il s'agit d'identifier les individus: il ne faut pas confondre le client avec le service qui lui est rendu, avec le produit qui lui est fourni ni avec le contrat que l'on a passé avec lui. Il faut aussi construire des identifiants pérennes, qui resteront affectés à l'individu pendant tout son cycle de vie, et s'interdire de ré-utiliser un identifiant après la fin du cycle de vie. Mieux vaut enfin ne pas confondre le rôle des identifiants et le rôle des attributs: l'identifiant ne doit être porteur d'aucune information."
 Michel Volle, de l'informatique, chapitre 7, page 268.

jeudi 28 juin 2012

La cryptographie, un sujet complexe

« Authentifier, c'est vérifier l'authenticité de l'identité présentée. »
Présentée ainsi, l'authentification peut paraître simple.
Cependant :
  • que signifie vérifier ?
  • de quelle identité parle-t-on ?
  • Que veut bien vouloir dire « présenter » une identité ?
La cryptographie est un procédé mathématique qui permet de s'affranchir de mettre en présence l'authentifiant et l'authentifié. Elle ne permet pas de simplifier les autres aspects de l'authentification, même si elle résout d'autres problèmes de façon assez élégante, comme la confidentialité ou l'anonymisation.
Autour du projet SEPAmail, nous avons rencontré des experts « authentification », « cryptographie », « sécurité », ce qui m'a permis de me rendre compte que :
  • le sujet est complexe,
  • le sens du vocable fondamental n'est pas toujours partagé,
  • il manque un modèle d'authentification partagé,
  • les couches permettant la simplification locale ne sont pas toujours valorisées
  • il y a réellement un besoin de simplicité pour l'utilisateur
Je détaille tout cela dans ce billet un peu long (pour une fois).

Les mots valise

Le sujet comprend beaucoup de mots valises qui sont structurants.
J'en précise certains en donnant quelques uns des sens différents utilisés et les confusions possibles.

Identification

« L'identification, c'est vérifier qu'un identifiant est présent dans une liste. » 
Par exemple, on identifie la chaîne de caractères que lit un lecteur de badge comme appartenant à la liste des identifiants de badges autorisés à passer un portique. Il peut être également identifié comme appartenant à une liste d'identifiants de badges non autorisés à passer le portique.
Ici, la chaîne de caractères est l'identifiant du badge.
Le badge est considéré comme non identifié si son identifiant n'appartient à aucune des listes.
Par extension, nombreux sont ceux qui induisent l'identifiant comme l'identité d'une personne physique. Ils considèrent alors l'identification, non pas comme la vérification que l’identité de la personne ramené à des identifiants (nom, prénom, visage, empreinte digitale, adresse) appartient à une liste d'identifiants connus, mais comme la vérification que la personne est bien celle associés aux identifiants présentés.
Cette approximation usuelle amène deux remarques :
  • un identifiant n'est pas une identité
  • identifier dans le sens télévisuel de la série policière est plutôt de l'authentification d'identité de personnes physiques dans une société les recensant en ayant associé un identifiant unique.

Authentification


« L'authentification, c'est vérifier l'authenticité. »
Ceci n'est pas simple et repose généralement sur le croisement de plusieurs critères.
Par exemple, l'authenticité d'un billet de banque repose sur de nombreux procédés de fabrication secrets ou connus mais difficiles à reproduire.
Par extension encore, la plupart parle d'authentification de personnes physiques à l'aide de procédé cryptographique alors même que l'authentification concerne une chaîne de caractères appelée « clé privée » au sein d'un système applicatif et/ou matériel déverrouillé par la personne physique en question.
Deux questions intéressantes sont :
  1. que veut-on authentifier ?
  2. Pourquoi veut-on authentifier ?
En y répondant, on simplifie généralement le problème.
L'authentification d'une personne vis-à-vis d'un système d'information est délicate à réaliser de façon directe. En effet, du point de vue de la machine, seul un procédé de nature cryptographique s'avère sûr, tandis que la personne, quant à elle, ne peut directement employer un tel mécanisme.
Les procédés d'authentification directe d'une personne se caractérisent tous par la possibilité de rejeu.
Pour bien distinguer les procédés d'authentification directe d'une personne, nous qualifions ces procédés de déverrouillage.
La robustesse est la capacité d'un mécanisme d'authentification à résister à une méthode de contournement ou de falsification.
Actuellement, il n'existe pas de mécanisme d'authentification que l'on ne peut pas contourner ou falsifier. Par contre, il en existe avec une robustesse très élevée. On distingue souvent trois niveaux de robustesse : standard, renforcé et élevé.

Sécurité

« La sécurité, c'est, entre autres, l'absence ou la limitation des risques dans un domaine précis. »
Dès que l'on parle de sécurité, il y a de gros écarts de compréhension, notamment :
  • entre ceux qui croient au système ultime et ceux qui croient qu'un tel système n'existent pas,
  • entre ceux qui « font la preuve » et ceux qui « s'engagent » en s'assurant contre le risque.
De plus, pour rendre plus compréhensible la notion de sécurité d'un système, beaucoup utilisent la notion de niveaux.
Or, sur ces sujets, on trouve de nombreux qualificatifs pour de nombreux concepts, par exemple :
  • des niveaux d'authentification (simple, forte)
  • des niveaux de robustesse cryptographique (standard, renforcé, élevé) [Référentiel Général de Sécurité]
  • deux niveaux européens de signature électronique (simple et avancée) [Directive 1999/93/CE article 2]
  • plusieurs niveaux français de signature électronique (simple, présumée fiable, avancée) [Memento sur la signature électronique de l'agence nationale de sécurité des système d'information ANSSI]
  • différents niveaux de sécurité d'un système informatique (logique, physique, réseau, utilisateurs)
  • deux états d'insécurité (passif et actif)
  • des certificats électroniques (qualifiés ou « dits » conformes en attente de qualification)
  • des autorités de certifications (racines, intermédiaires, qualifiées)
  • différentes instances édictant différentes normes de sécurité dans le domaine du traitement de l'information, des systèmes d'information, des données de paiements (EPC, RGS, PCI DSS).
Nous voyons bien qu'un même adjectif peut être utilisé dans un sens différent, ce qui augmente les possibilités de confusion et d'incompréhension, même auprès d'un public averti.

Cryptographie

« La cryptographie est une des disciplines de la cryptologie s'attachant à protéger des messages. »
D'un abord mathématique et rigoureux, cette science a été vulgarisée par l'utilisation en sécurité informatique et en droit.
Cette vulgarisation conduit à de nombreuses confusions.

 

Une confusion possible : Décrypter et déchiffrer

Notons les définitions suivantes :
  • chiffrer : transformer à l'aide d'une clé de chiffrement un message en clair (dit texte clair) en un message incompréhensible (dit texte chiffré) pour celui qui ne dispose pas de la clé de déchiffrement (en anglais encryption)
  • déchiffrer :  retrouver le message clair correspondant à un message chiffré avec la clé de déchiffrement
  • décrypter : retrouver le message clair correspondant à un message chiffré sans posséder la clé de déchiffrement (terme que ne possèdent pas les anglophones, qui eux « cassent » des codes secrets)
Le mot « crypter » n'a pas raison d'être ; il n'existe donc pas et il est absent du dictionnaire de l'académie française.

Déchiffrer et décrypter ne signifient pas du tout la même chose en langue française alors que les traductions anglicistes les confondent allègrement.

Une confusion possible : le procédé de cryptographie asymétrique utilise largement le procédé de cryptographie symétrique


Il y a plusieurs procédés de cryptographie dont deux permettent de nombreuses fonctionnalités :
  • le système de chiffrement symétrique, quand il utilise la même clé pour chiffrer et déchiffrer.
  • le système de chiffrement asymétrique, quand il utilise des clés différentes : une paire composée d'une clé publique, servant au chiffrement, et d'une clé privée, servant à déchiffrer (Le point fondamental soutenant cette décomposition publique/privée est l'impossibilité calculatoire de déduire la clé privée de la clé publique)
L'utilisation d'un système symétrique ou asymétrique dépend des tâches à accomplir. La cryptographie asymétrique présente deux intérêts majeurs : elle supprime le problème de transmission sécurisée de la clé, et elle permet la signature électronique.
Elle ne remplace cependant pas les systèmes symétriques car les temps de calcul sont nettement plus longs. La plupart du temps, le système asymétrique sera utilisé pour échanger une clé de session (courte) qui servira ensuite de clé partagée pour un échange symétrique plus rapide.
Les deux procédés ne s'opposent donc pas ; ils se complètent. 

Une confusion possible : le procédé de cryptographie asymétrique est accessible aux automates de calcul et non directement aux humains

D'aucuns parlent d'authentification de personne au moyen de procédé de cryptographie asymétriques alors même que ce type de procédé n'est pas accessibles directement à l'être humain non outillé d'un calculateur.
L'humain déverrouille un environnement local de confiance à l'aide d'un mécanisme de rejeu (une combinaison plus ou moins compliquée de plusieurs facteurs entre ce qu'il possède, qu'il sait, qu'il est...) laissant alors la charge à cet environnement local de confiance automatisé de s'authentifier à l'aide d'un procédé de cryptographique asymétrique sans rejeu.

Une confusion possible : déverrouillage local et authentification à distance

Seule l'utilisation de protocoles cryptographiques d'authentification permet de garantir à deux machines qu'elles communiquent bien l'une avec l'autre et non avec une machine usurpatrice.
Pour authentifier une personne, on utilise des mécanismes de déverrouillage (mot de passe, biométrie, support personnel) dont l'esprit est qu'ils doivent demeurer locaux.
L'utilisation d'un déverrouillage dans une procédure à distance ne constitue pas véritablement une authentification car dans le monde numérique, le rejeu est rendu très facile par les possibilités de copie numérique.
Le périmètre dans lequel le mécanisme de déverrouillage est employé doit être bien identifié car c'est un environnement qui doit être local et de confiance.

Non répudiation

« La non-répudiation est l’impossibilité de nier la participation au traitement d’une information. »

La non-répudiation de quoi ?

Selon le contexte, la non répudiation ne se limite pas au seul auteur d'un processus ou d'une action.
Par exemple, pour l'échange de messages, on peut considérer de façon distincte :
  • la répudiation par l'émetteur du message ("je nie avoir envoyé le message")
  • la répudiation par le destinataire ("je nie avoir reçu le message")
  • la répudiation sur le contenu du message de l'un ou de l'autre (« je nie avoir envoyé le contenu de ce message » ou « je nie avoir reçu le contenu de ce message »)
  • la répudiation sur les données liées au temps, l'horodatage de l'un ou de l'autre(« je nie avoir envoyé à cette date et cette heure le message », « je nie avoir reçu ce message à cette date et heure »)

Le contexte juridique de la non-répudiation

La non-répudiation est souvent associée au contexte juridique du « renversement de la charge de la preuve » dans le cadre de la signature électronique, preuve préconstituée.
Le coût économique de cette charge de la preuve étant dans certaines situations non négligeable, cette caractéristique de « non répudiation » peut devenir un sujet clé.
Pour éviter de se poser cette question, il est possible d'insérer dans le contrat initial entre une banque et son client l'obligation de preuve pour celui qui dénonce une signature.
Ainsi, le cadre de la répudiation devient contractuel.

Le contexte technique de la non-répudiation

Les systèmes de cryptographie asymétriques consacrent la notion de certificat et d'autorité de certification avec un usage garanti de non répudiation dans le cadre de la norme X.509 et sa spécialisation pour les application internet.
Attention, là encore, on utilise deux expressions voisines anglaises, souvent confondues et associées toutes les deux à la non-répudiation. Nous détaillons pour une bonne compréhension ces deux expressions et l'usage technique.
  • « key usage extensions », ou extension du protocole sur l'usage de la clé est un champ renseignant sur l'utilisation qui doit être faite de la clé. Si ce champ est défini comme critique, alors la clé ne doit être utilisée que pour l'usage spécifié. Si le champ n'est pas positionné à critique, alors le champ Key usage est là à titre indicatif.
  • « extended key usage extension », ou extension du protocole sur l'usage étendu de la clé, permet de définir de façon plus étendue les usages, notamment par une fonction globale attendue de la clé, comme la protection des courriels ou l'authentification d'un serveur. Voici quelques uns des usages étendus possibles, pour bien comprendre. 

En guise de conclusion

Il me semble qu'au vu de :
  • la complexité du sujet,
  • du manque de compréhension partagée parmi les différents experts,
  • du vocabulaire ambigu ou mal traduit largement utilisé, surtout du côté des adjectifs de la graduation,
  • de l'évolution des technologies avec les capacités de calcul des processeurs et des failles découvertes,
Il est temps de partager un référentiel simple et compréhensible pour l'utilisateur qui soit orienté sur les grandes fonctions qu'apporte la cryptographie en sécurité.

C'est l'objet de SAPPhire, un standard de simplification pour l'authentification sécurisé orienté utilisateur.
SAPPhire a été développé pour SEPAmail mais dépasse largement le cadre de SEPAmail.
J'en développerai peut-être dans un prochain billet en quoi SAPPhire répond à ces différentes problématiques.

jeudi 21 juin 2012

Application SEPAmail : RUBIS

RUBIS permet pour un utilisateur de SEPAmail d'envoyer une demande de règlement à un autre utilisateur SEPAmail.
Ces utilisateurs sont appelés demandeur et interlocuteur payeur.
RUBIS permet aussi au payeur de répondre "oui", "non", "oui mais", voire de ne rien répondre.

Qu'est-ce qu'une demande de règlement ?

Assez simplement, on peut résumer la demande de règlement à :
  • une requête
  • pour être payé
  • de la part de quelqu'un
  • une somme d'argent définie
  • dans une devise précise
  • à une date définie
Il y a un message iso 20022 pour réaliser ce genre de demande, le pain.013.
Il permet de préciser et de typer ce que sont les dates, les devises, le moyen de paiement demandé.

Comment évite-t-on les demandes non sollicitées ?

Cela est un vrai problème et cela dépend du contexte et du demandeur.
SEPAmail prévient et prévoit ces cas.

Supposons que le demandeur est un créancier de particuliers. Il s'inscrit dans l'annuaire RUBIS, diffusé entre les adhérents.
Dans ce cas, le particulier peut choisir d'autoriser ou non le créancier à lui envoyer des demandes de règlement au travers de SEPAmail. Il utilise pour cela un message spécifique de SEPAmail ActivationEnroll.

Selon les adhérents, les règles utilisées pour ne pas importuner leur client avec des messages sans autorisation préalable seront différentes. Certains ont prévu d'avertir qu'il y a une demande de règlement de la part d'un nouveau créancier enregistré dans l'annuaire. D'autres ont prévu de ne pas distribuer le message. Enfin, certains préfèrent implémenter un système de opt-in opt-out extensible à toute paire d'interlocuteurs.
Supposons que le demandeur soit un particulier qui fasse des demandes non sollicitées, alors, comme il authentifié, il pourra être bloqué par sa banque sur déclaration d'abus.

Les principes sont assez simples :
  • pour s'échanger un premier message, il faut demander d'abord à l'autre et être deux d'accord pour l'échange. Il y a donc une phase préalable d'inscription ou de connexion (enroll).
  • il n'est pas nécessaire de demander avant chaque échange car, après acceptation initiale, les deux interlocuteurs sont considérés comme d'accord ou connectés, tant que l'un des deux ne demande pas l'arrêt.
  • pour ne plus recevoir de message de l'autre partie, il faut l'expliciter par un message de déconnexion (enroll)

Ainsi, on est bien sur un fonctionnement optin/optout classique, sachant qu'il y authentification de toutes les parties et entente entre les adhérents pour ne pas relayer les messages SEPAmail non sollicités de part et d'autre.

Est-on obligé de répondre à une demande de règlement ?

L'interlocuteur payeur n'est pas obligé de répondre au demandeur.
Sa seule obligation est la suivante:
  • s'il a répondu OUI
  • puis qu'il ne peut ou ne veut honorer le règlement,
  • il ne peut empêcher l'adhérent SEPAmail dont il le client de diffuser l'information du non règlement (notamment en arguant du secret bancaire ou de son contrat)

Si on répond oui à une demande de règlement, que se passe-t-il ?

Si on répond OUI à une demande de règlement, alors, selon le contrat passé entre l'adhérent et son client, l'adhérent peut enclencher un paiement, comme un virement, un paiement par carte ou tout autre dispositif contractuel.
Mais il n'est pas obligé de le faire.
Dans l'absolu, RUBIS peut déboucher sur un paiement par chèque de la part de l'utilisateur.