Foire aux questions n°3

Voici les questions qui me sont posées fréquemment ces temps-ci sur SEPAmail.
Si vous avez vous-même des questions, n'hésitez pas à me contacter par la zone commentaire de ce billet ou via les réseaux sociaux viadeo ou linkedIn.

SEPAmail pour tous, c'est pour quand ?

En ce moment, le protocole SEPAmail est bien mis en oeuvre entre des particuliers, des entreprises et des professionnels dans au moins 3 des 5 banques ayant adhéré au réseau.
Par exemple, j'ai payé une facture d'un opérateur de télécom avec l'application de SEPAmail RUBIS et je rembourse l'un de mes clients quand il paie au restaurant.
Cependant, mon épouse, mes enfants et mes parents n'utilisent pas encore SEPAmail, et notamment RUBIS. Pourquoi ?
Parce que le lancement est prévu courant 2014... vers mars pour les premiers prêts, avant l'été pour les autres.
Donc, une fois le SEPA dernière nous (février 2014), SEPAmail devrait être accessible au plus grand nombre, notamment sur le sol français.

SEPAmail est un réseau de messagerie privée ou publique ?

SEPAmail est un réseau de messagerie privée, utilisable par les clients des adhérents de SEPAmail qui deviennent ainsi des fournisseurs d'accès à SEPAmail et ses applications.
SEPAmail permet de faire transiter de façon sécurisée l'information sur un réseau public comme internet, entre tous les points d'articulation de la messagerie.
Voilà pourquoi la réponse à cette question peut être ambiguë pour certains qui ne se sont pas plongés dans le standard, qui lui, est ouvert et public.

C'est quoi le règlement (via) SEPAmail ?

Le règlement (via) SEPAmail, c'est le nom générique de l'application de SEPAmail dont le nom de code entre ses concepteurs est RUBIS.

J'ai déjà écrit que SEPAmail n'était pas un nouveau moyen de paiement.
C'est une messagerie qui permet entre autres de s'envoyer entre deux entités économiques (particulier, entreprise, professionnel, institution, administration, association.... ) une demande de règlement et d'y répondre par une acceptation ou un refus, voire de ne pas y répondre.
La demande et la réponse passe par la messagerie SEPAmail. Elles sont complètement dématérialisées, automatisées, articulées.
Quand la réponse est positive, une initiation de paiement peut être articulée en même temps, ce qui est le comportement par défaut adopté par les adhérents. La réponse positive vaut donc initiation de paiement donc un règlement "dit" SEPAmail.
La plupart des banques mettant en œuvre RUBIS ont articulé un virement, ce qui permet au passage de répondre à la demande de virement de proximité.

L'application DIAMOND est-elle bien 4-coins ?

L'application de SEPAmail DIAMOND permet à un gros remettant d'ordre (prélèvement ou virement) de vérifier un identifiant bancaire avant la remise.
Par exemple, un opérateur d'énergie va vérifier avant d'envoyer un remboursement l'IBAN de son client en correspondance avec le nom et le prénom. Le score rendu avec DIAMOND par la banque de son client permet à cet opérateur de prendre une décision de virement automatique (par exemple via JADE) ou de matérialisation d'une lettre chèque.

Si le client remboursé (ou prélevé) n'est pas au courant qu'il y a des demandes de vérification de son identifiant bancaire, l'application n'est pas vraiment 4 coins.
Si le client est au courant à chaque demande, il peut ne plus se fier à cette information récurrente, voire considérer cette information comme une pollution.
Par contre, si ce client peut décider de son niveau d'information et agir en cas de suspicion d'abus de demande de de vérification, alors, nous somme bien dans un modèle 4 coins vertueux.
C'est ce troisième cas qu'est en train de finaliser le scheme SEPAmail.

 

Pourquoi il n'y a plus de billets chaque semaine sur ce blog depuis quelques mois ?

La question m'est souvent posée ;-)

Il y a plusieurs réponses à cela.

Tout d'abord, SEPAmail n'est pas généralisé et les banques ne communiquent pas beaucoup en ces temps d'urgence SEPA.

Ensuite, je suis sollicité sur plein de sujets par plusieurs acteurs mettant en oeuvre SEPAmail mais je suis plutôt sous Non Disclosure Agreement avec eux... donc, en ce moment, je ne partage pas avec tous mes bonnes idées, car je ne sais pas toujours si elles ne sont pas un peu issues de mes travaux confidentiels.

Enfin, je préfère attendre d'avoir du contenu intéressant pour vous et moi, plutôt que de vous abreuver de contenu en retard ou trop en avance sur le temps SEPAmail.

N'hésitez pas à me contacter ou à participer au blog si vous avez des idées.

Dans les tuyaux, il y a à venir :

• un billet sur la SMIRK JADE qui est en voie de diffusion
• un billet sur la gestion des dates dans RUBIS et notamment des précisions sur la "date souhaitée de paiement" et la "date d'expiration" de tout message
• une série de billets sur des produits dans le même champ fonctionnel : MyBank, StarMail, Zoomit...
• un billet sur la gestion de la volumétrie

Bonne lecture...

SEPAmail expliqué à mes proches

Le titre de cet article aurait pu être "SEPAmail pour les nuls" mais il traduit mal ce que sont mes proches ou le néophyte qui entre dans le sujet SEPAmail.

Voici le dialogue que j'aurais pu avoir avec mon épouse, ma maman, l'un de mes fils, ma meilleure amie etc.
Bien entendu, il est plus facile de l'écrire que rendre réel un tel échange.

SEPAmail, c'est quoi ?

SEPAmail, c'est juste un standard, c'est à dire un ensemble de règles qu'une communauté de personnes et de programmes utilisent.

C'est comme un standard en circulation routière. Un groupe de personnes définissent les largeurs des voies, les rayons de courbures des tournants, la hauteur des ponts et des tunnels, pour que les constructeurs de voitures, de camion, de route, de ponts, de rond-points etc. puissent réaliser les véhicules adaptées à ces routes.

A quoi sert SEPAmail ?

SEPAmail sert à structurer le contenu d'un courriel et sécuriser son transport.

Un courriel (email) aujourd'hui souffrent de trois gros défauts :

• c'est une carte postale que tout le monde peut lire sur internet
• rien n'affirme que l'expéditeur est celui qu'il dit être
• le contenu est libre, on peut y écrire ce que l'on veut et y  joindre n'importe quel document

Ces trois défauts font la joie de prédateurs qui cherchent à récupérer de l'argent des autres utilisateurs.

L'absence de structure dans son contenu (le troisième défaut) permet une grande liberté mais c'est difficile à interpréter par un programme. C'est pourquoi sur les sites internet, ce sont des formulaires qui remplacent les emails (même de contact).
Ainsi, il est plus facile de faire interpréter le contenu par un programme, d'automatiser les tâches (aiguillage, tri, distribution) et ainsi d'acheminer l'information au bon agent humain si besoin.

SEPAmail propose une organisation qui transforme le courriel de la façon suivante :

• il est confidentiel sur internet, donc ce n'est plus une carte postale mais une lettre scellée;
• des agents intermédiaires vont garantir que l'expéditeur est celui qu'il dit être, même si tu ne le connais pas, que tu ne l'as jamais vu, que tu ne sais pas comment le reconnaitre;
• le contenu du courriel est un formulaire d'un certain type, qui attend du destinataire une certaine réponse. Chacun de ces dialogues est du type question/réponse et défini dans une application précise de SEPAmail.
  Il y a déjà de nombreuses applications SEPAmail : une demande de paiement, une demande de signature de document, un mandat de prélèvement, un avis de réglement, une transmission de facture et même un simple courriel ou sms;
• il est toujours possible de joindre un ou plusieurs documents d'un type spécifique et sécurisé;
• il y a un accusé de réception de chaque envoi systématique, ce qui permet aux programmes et aux humains d'être sûr que le message est bien arrivé et qu'il sera acheminé vers le bon destinataire;

Qui va utiliser SEPAmail ?

Je ne sais pas, cela dépend de beaucoup de choses.

Quand une route est construite, quand le courrier pour tous a été mis en place, quand le courriel est arrivé, il y a plein de personnes qui ne voyaient pas l'intérêt car ils n'avaient pas de besoins ou ils n'étaient pas conscients du besoin.

Je me souviens que pour le courriel, au début, j'étais l'un des seuls de mon entourage à avoir une adresse mail donc je ne m'en servais pas beaucoup.

Ce sont les entreprises qui s'y sont mises en premier, car pour elle, cela réduisait beaucoup leur charge (papier, stockage) et permettait des délais que seul le fax autorisait (sans grande qualité). La notion de pièce jointe du courriel avec la possibilité d'échanger de façon simple et désynchronisé des fichiers sources (document, image etc...) a vite conquis la plupart des employés. Puis, comme souvent, ces employés ayant compris l'intérêt, ont commencé à utiliser le mail dans leurs usages domestiques.

Pour la conversation instantanée (chat) et le sms, c'est plutôt allé dans le sens contraire. Les particuliers, surtout les jeunes, s'y sont mis très vite et ont emportés les parents qui ont amenés l'usage dans leur entreprise.

Pour reprendre ta question, ceux qui vont utiliser SEPAmail sont ceux qui en ont le plus besoin si une masse critique d'utilisateurs est atteinte.

Les visions des uns et des autres sont différentes sur ce sujet; certains pensent que ce sont les usages domestiques qui vont inciter l'usage professionnel; d'autres pensent que cela va être le contraire.

Pour ma part, c'est la masse critique qui me semble être l'objectif premier.

Un autre objectif est que SEPAmail reste ouvert à tous et réalisé par de nombreux opérateurs (comme pour le courriel) et non un seul.

Pourquoi tu parles toujours de banque avec SEPAmail ?

Je t'ai parlé d'agents intermédiaires qui garantissent que l'expéditeur est celui qu'il dit être.

Cette organisation de proche en proche permet de ne pas avoir à rencontrer tous tes interlocuteurs à chaque échange.

Aujourd'hui, les circuits de l'argent dans la plupart des pays (qui ne sont pas des paradis fiscaux) sont opérés par un réseau assez important pour laisser le choix à l'utilisateur et assez petit pour contraindre ce réseau à des règles strictes. Ce sont les banques qui orchestrent ce réseau.
Parmi ces règles, il y a celle de connaître leur client et pouvoir les identifier (qui ils sont) et les authentifier (la personne en face d'eux, au téléphone, sur le site internet est bien son client).

Les banques sont donc de bons candidats pour être ces agents intermédiaires.

De plus, elles savent articuler un paiement si besoin.

Par exemple, tu me demandes de te rembourser un billet de train par SEPAmail, je te dis d'accord et alors, ma banque peut te faire le virement de façon automatique.

Par contre, les banques ne sont pas nécessaires et d'autres acteurs peuvent très bien jouer ce rôle de tiers de confiance.

Ce qui est important, c'est que nos deux tiers de confiance (le tien et le mien) se fassent confiance et mettre en oeuvre l'organisation SEPAmail car une grande partie de la sécurité est portée par eux deux.

Dans SEPAmail, on appelle ces tiers de confiance des adhérents SEPAmail et nous deux des utilisateurs SEPAmail.

Et pourquoi le nom SEPAmail alors ?

Le SEPA, c'est le paiement européen standardisé qui se généralise en Europe en 2014 avec un virement et un prélèvement codifié par des règles communes pour tous.

Le SEPA n'a pas prévu de sécuriser les échanges d'information avant ou après un paiement SEPA.

SEPAmail, c'est donc initialement le standard du mail autour du SEPA.

Mais SEPAmail permet de structurer et sécuriser n'importe quel échange d'information qui tiendrait dans un courriel classique.

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...

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.

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.

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.

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,4x10²⁹ 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.

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.

Le modèle 4 coins

Le dispositif SEPAmail repose sur un modèle mettant en jeu quatre acteurs :

• un utilisateur A, client du fournisseur de services SEPAmail FSA
• FSA, adhérent du réseau SEPAmail
• FSB, adhérent du réseau SEPAmail
• un utilisateur B, client du fournisseur de services SEPAmail FSB

les acteurs et les espaces de confiance

FSA et FSB sont liés au réseau SEPAmail par un contrat d'adhésion.
Ce contrat d'adhésion comprend notamment l'acceptation d'une charte d'adhérent.
Cette charte fixe les règles communes que chaque adhérent s'engage à respecter.
Elle est publiée, publique et connue de tous, utilisateurs compris.

En 2012, FSA et FSB sont des banques tenues au secret bancaire.
Si des entités non bancaires demandaient leur adhésion, il faudrait préciser quel serait le cadre du secret minimal entre cette entité et son client.

A et FSA d'un côté, et B et FSB d'un autre côté, sont liés deux à deux par un contrat de service autour de SEPAmail.
Ce contrat précise les conditions d'utilisation du service, notamment les termes de la protection des données, du mandat de transmission de l'information, les bonnes règles à respecter pour chacun des acteurs afin de garantir la sécurité proposée dans le cadre de la messagerie SEPAmail.
Chaque fournisseur de service possède avec son client des espaces de confiance dans lesquels les parties sont mutuellement authentifiées et grâce auxquels l'échange d'information peut se faire en toute sécurité.

Les vertus du modèle 4 coins

Le modèle 4 coins SEPAmail présente les avantages suivants:

• les acteurs sont tous sous contrat commercial pair à pair
• c'est le réseau d'adhérents avec des règles partagées et contrôlées lors de chaque échange qui fait office de tiers de confiance et non une seule entité
• la confiance vient d'espaces de confiance pré-existants mis bout à bout, il n'y a pas de nouvel espace à créer mais une chaîne de confiance à articuler
• il permet des canaux de communication différents entre chacune des parties
• il permet à chaque fournisseur de service de proposer des services à valeurs ajoutées différents pour son client
• il permet d'inscrire l'échange d'information sécurisée dans une vision flux (articulation, structuration partagée, enrichissement par les relais) et non pas seulement comme des transferts de blocs authentifiés entre pairs.

Quand la sécurité est en jeu, le modèle 4 coins apporte les preuves de son efficacité.

On peut citer, par exemple, l'organisation de l'arbitrage des conflits en justice.
Les parties confient leur défense à des avocats différents.
Ils sont soumis à des règles communes de secret, de communication, de devoir de représentation des intérêts de leur client, un engagement à servir la justice.
Dans la plupart des cas, il y a un juge-arbitre désintéressé représentant les règles sociales et l'avocat est un relais pour la défense.
Il connaît les règles et apporte une forte valeur ajoutée dans la relation, notamment car il a la capacité à discuter sous secret avec l'avocat de l'autre partie.

On retrouve aussi des cas de figure similaires avec

• les notaires et l'ordre des notaires,
• les médecins et l'ordre des médecins.

On peut prendre un exemple de modèle 3 coins ayant montré ses limites : le cas de la distribution postale recommandée avec accusé de réception.
Le transporteur fait office de tiers certifiant unique.
La plupart du temps, les véritables règles de cette certification ne sont pas connues du public et il n'y a pas de contrat(s) entre les parties.
Le transporteur est le juge-arbitre en cas de litige.

Mais SEPAmail est-il toujours 4 coins ?

Cas où deux clients partagent le même fournisseur de service

Si A et B ont le même fournisseur de service, alors le modèle 4 coins semble devenir un modèle 3 coins car il n'y a que trois acteurs.
Qu'est-ce qui garantit que A et B ne perdent pas les vertus du modèle 4 coins ?
L'adhérent s'est engagé à mettre en œuvre le standard SEPAmail. Or le standard ne fait aucune différence sur ce sujet.
Dans tous les cas, l'échange d'information doit mettre en œuvre :

• le dispositif de messagerie sécurisée avec l'authentification, l'acquittement, l'horodatage, la journalisation
• la couverture des garanties à l'utilisateur selon le niveau de service souscrit

La conséquence, c'est que le fournisseur de service assume donc les rôles des deux relais d'acheminement.
Il doit donc nécessairement s'envoyer à lui-même une enveloppe SEPAmail contenant une signature de la missive, comme pour les autres cas.

Cas d'un client s'envoyant un message à lui-même

Supposons ce cas possible avec une application SEPAmail.
Dans le cas où un client utilisateur d'un fournisseur de service désire s'envoyer à lui même un message SEPAmail, alors, le modèle 4 coins est mis en œuvre de la même façon, même si il ne met en jeu que deux acteurs.
On considère successivement les 4 coins : l'expéditeur, le relais de l'expéditeur, le relais du destinataire et le destinataire.
Les trois échanges sur les trois espaces de confiance sont mis en œuvre en respectant scrupuleusement les règles du standard SEPAmail.

SEPAmail met donc toujours en jeu un modèle avec au moins 4 coins

Dans les cas où seuls deux ou trois acteurs interagissent dans le dispositif SEPAmail, il y a toujours au moins 4 coins, les 4 rôles toujours mis en action:

• l'expéditeur
• le relais de l'expéditeur
• le relais du destinataire
• le destinataire 

Vocabulaire SEPAmail : la missive nominale

La missive

Une missive SEPAmail est un contenant regroupant un message et des propriétés d'adressage et de priorité au sein du réseau des utilisateurs SEPAmail, comme précisé dans un précédent billet.
Cette couche intermédiaire entre l'enveloppe et le message permet de rendre confidentielles ces propriétés et de ne conserver sur l'enveloppe que les seules informations nécessaire au bon acheminement sur le réseau IP de l'ensemble {enveloppe>missive>message}

La missive nominale

Une missive est dite nominale lorsqu'elle transporte un message émis par un utilisateur SEPAmail destiné à un autre utilisateur SEPAmail (ou lui-même).

Le cœur de métier du dispositif SEPAmail est donc de transporter ces missives nominales.

Pourquoi distinguer des missives nominales ?

Si on veut garantir la bonne distribution d'un message, il faut que le destinataire puisse accuser de façon certaine la bonne réception et sa capacité à traiter le message.
Il faut donc un mécanisme pour distinguer le message initial et l'accusé de réception afin d'appliquer les bonnes règles (priorité, émission, réception, contrôle).

Comment cela fonctionne ?

La missive est structurée en xml, ce qui permet:

• en exploitation une validation rapide et simple
• une évolution plus facile et la possibilité de gérer plusieurs versions

La missive est orientée adressage et routage dans le réseau (privé) SEPAmail.
Elle est exclusivement dédiée à ces fonctions.

Le type nominal de la missive signifie qu'elle contient un message à relayer.

Les autres missives

Il y a dans la norme d'autres types de missives:

• la missive d'acquittement, permettant l'acquittement des missives nominales
• la missive de service, permettant d'encapsuler un dialogue client/serveur dans l'espace de confiance de l'adhérent avec son utilisateur
• la missive d'interfaçage (SMAPI), permettant d'encapsuler des accesseurs/constructeurs API avec un SMart ou un SMile

Vocabulaire SEPAmail : SMART et SMILE

SMART

SMART est l'acronyme de SepaMail Acknowledgment, Routing and Transfer.

Il s'agit du nom de code d'un composant que chaque adhérent SEPAmail met en œuvre au sein de son système d'information afin de pouvoir échanger des messages/missives/enveloppes SEPAmail selon le protocole SEPAmail.

Ce composant s'occupe de l'acheminement (transmission en émission et réception) des messages SEPAmail au sein de missives nominales ainsi que du bon acquittement de ces missives nominales.

le SMART dans le réseau des adhérents SEPAmail

La documentation propose ce schéma d'architecture (licence creatives commons)

C'est lui qui met en œuvre (ou délègue) les fonctions suivantes du protocole entre les adhérents :

• vérifications en réception  ecosystem, adresse, signature, adressage, intégrité, xml, typage du contenu...
• authentification du pair
• déchiffrement, chiffrement
• acquittement des missives nominales
• renvoi des missives si non acquittement dans les temps impartis et escalade si nécessaire
• transmission des messages au SI
• génération des missives
• génération/émission des enveloppes (délégation conseillée)
• envoi/réception sur le réseau IP (délégation conseillée à un MTA)
• horodatage (délégation conseillée)
• journalisation (délégation conseillée)

Il existe actuellement une implémentation logicielle de SMART, utilisé pour l'expérimentation, éditée par la société StreamMind. Le logiciel s'appelle SEPAplug^®; il embarque d'autres fonctions que celles du SMART et il est utilisé dans un contexte plus large au sein du système d'information pour la plupart des adhérents de l'expérimentation.

On peut imaginer que d'autres implémentations de SMART vont voir le jour, soit développées directement par les directions d'études des adhérents, soit par des éditeurs externes.

Une implémentation (de référence ?) pourrait également être développée autour de serveurs d'échange de courriel (Mail Transfert Agent) du marché comme MS Exchange ou VMWare Zimbra.

SMILE

SMILE est un acronyme à trouver.
Je relate dans ce billet sur le SMIRK l'idée de baptiser des composants fonctionnels de cette manière mais je ne connais pas encore la signification de cet acronyme et il n'y a rien dans la documentation sur ce sujet à ce jour.
On peut imaginer le I d'Interface et le E d'Enterprise... reste le L ?

L'idée était de réserver le sourire pour les clients des adhérents SEPAmail, les gros utilisateurs.

SMILE est un composant similaire au SMART dans ces fonctions mais il est orienté extension de la norme dans l'espace entre l'adhérent et son client, l'utilisateur final SEPAmail qui a souscrit un service utilisant SEPAmail.

SMILE diffère dans son implémentation du SMART pour la partie authentification du pair car l'authentification d'un utilisateur dépend de l'adhérent et du canal avec son client.
SEPAmail propose une simplification partagée utilisant elle-même le dispositif de messagerie SEPAmail autour du sujet de l'authentification: SAPPhire.
SAPPhire fera l'objet d'un prochain billet.
Il existe actuellement une implémentation logicielle de SMILE, utilisé pour l'expérimentation. Il s'agit également du logiciel SEPAplug^®.

Pour aller plus loin

• le protocole autour de la missive
• un schéma d'architecture et de présentation de la norme

Vocabulaire SEPAmail : l'acquittement

Qu'est-ce que l'acquittement dans SEPAmail ?

L'acquittement SEPAmail permet de mettre en place une chaîne d'accusés de réception pair à pair depuis l'expéditeur du message jusqu'au destinataire du message en passant par les relais d'acheminement (les adhérents SEPAmail).

L'accusé de réception SEPAmail est réalisé sous la forme d'une missive de type acquittement, en réponse à une missive nominale qui contient l'information initiale à transmettre.

Cet accusé possède les propriétés suivantes :

• rien ne distingue une enveloppe SEPAmail contenant une missive d'acquittement
• l'acquittement est désynchronisé de la réception, avec une garantie d'acquittement selon la priorité de l'envoi
• l'acquittement est garanti grâce à un engagement des parties, ainsi qu'un mécanisme de renvoi et d'escalade
• l'acquittement est horodaté pour la partie réception du message initial et pour son envoi
• l'acquittement garantit la vérification des signatures, la vérification de l'intégrité du message initial

Certains parlent de cet acquittement comme un acquittement technique, ce qui amène de la confusion car cela induit que c'est un accusé de type infrastructure et automate, comme ceux des protocoles réseau, ce qui n'est pas du tout le cas.

Cet acquittement est fondamental dans le protocole SEPAmail car c'est lui qui va permettre à chacun des adhérents de proposer du service à son client, notamment des services juridiques, d'huissier, de qualité, de relance automatique etc...
Cet acquittement est un acquittement non technique, automate dans la plupart des cas, et enfin fonctionnel pour le métier de messagerie électronique. Il est partagé par toutes les applications SEPAmail et fait partie des composants de sécurité de la messagerie SEPAmail.

Les comparaisons avec l'accusé de réception postal.

Le mécanisme de recommandé avec accusé/réception souffre de défauts connus :

• il faut noter le numéro de lettre recommandée sur le courrier ce qui confond la couche message et la couche enveloppe
• n'importe qui peut envoyer un recommandé au nom de quelqu'un d'autre car il n'y a pas vérification de l'identité à l'envoi
• si le recommandé n'est pas accepté, il faut envoyer une lettre simple en même temps pour garantir que le destinataire a bien reçu le courrier
• le facteur, en remettant le courrier, attend une signature pour générer l'accusé de réception, ce qui provoque une attente due à une synchronisation nécessaire pour garantir l'accusé réception et souvent une délégation de signature au service courrier
• le transporteur est en même temps relais d'acheminement pour les deux parties, sans contrat commercial clairement établi entre les parties et le transporteur

L'acquittement SEPAmail a été pensé pour dépasser tous ces défauts.
Nous y reviendrons peut-être dans un prochain billet.

Pour aller plus loin

On trouvera sur la documentation de SEPAmail:

• les règles protocolaires sur l'acquittement.
• les règles protocolaires sur le renvoi de missive nominale.

Vocabulaire SEPAmail : l'écosystème

Définition

Un écosystème SEPAmail est un ensemble de types de message ayant le même sujet.
Par exemple, les messages autour du mandat de prélèvement sont regroupés au sein de l'écosystème direct.debit.

Un type de message SEPAmail doit et ne peut appartenir qu'à un seul écosystème.

L'ensemble des écosystèmes SEPAmail forme donc une partition des messages SEPAmail.

Utilité

Les écosystèmes sont utilisés pour l'organisation de la messagerie :

• le routage avec un aiguillage des enveloppes SEPAmail, d'après une adresse de courriel liée à l'écosystème selon le masque [ecosystem]@[bic].sepamail.eu
• la sécurité avec des bi-clés liées à l'adresse de courriel de l'écosystème
• les interfaces avec les systèmes d'information des adhérents SEPAmail et des utilisateurs SEPAmail selon l'écosystème
• le classement des types de messages et des schémas selon l'écosystème

Les écosystèmes SEPAmail

Il a été défini à ce jour dix écosystèmes :

• credit.activation, autour de l'avis de virement
• digital.signature, autour de la signature numérique
• direct.debit, autour du prélèvement
• generic, autour du message générique
• identification.verification, la vérification d'identité bancaire
• payment.activation, autour de la demande de règlement
• scheme, tout ce qui concerne l'organisation, notamment les référentiels
• secure, tout ce qui concerne la sécurité, notamment l'inscription aux services et la mise en place des espaces de confiance
• test , pour réaliser des tests
• trade.service, autour des services commerciaux, dont la transmission de la facture

Le nom d'un écosystème est toujours en langue anglaise et les mots le composant sont séparés par le délimiteur point [.].

L'écosystème s'appelait de 2008 à 2011 la famille, ce qui n'avait pas d'équivalent naturel en anglais, d'où le changement de vocabulaire fin 2011, proposé par le groupe de travail "fonctionnel et études" de la communauté SEPAmail.

Lien avec les applications SEPAmail.

Trois écosystèmes correspondent à des fonctions transverses : scheme, test et secure.
Les autres sont liés chacun à une application SEPAmail selon la correspondance :

• credit.activation ~ JADE
  
• digital.signature ~ JASPE
  
• direct.debit ~ GEMME
  
• generic ~ AGATE
  
• identification.verification ~ DIAMOND
  
• payment.activation ~ RUBIS
  
• trade.service ~ IOLITE

Il est possible que plusieurs applications utilisent des messages du même écosystème mais ce n'est pas le cas pour le moment.

Par nature, un écosystème regroupe les messages autour du même sujet alors que plusieurs applications peuvent voir le jour selon les besoins de la communauté.

Le concept de l'application SEPAmail est donc orienté "besoin métier" alors que le concept de l'écosystème est orienté "organisation de la messagerie".

Vocabulaire SEPAmail : SMIRK ou la demande de commentaires

Historique de l'acronyme

SMIRK est l'acronyme de SEPAMail Internal Request for Komment, ce qui pourrait signifier en français  "demande interne de commentaires SEPAmail".

Cet acronyme a été trouvé par Olivier Jousselin lors d'une réunion en novembre 2011 à la Banque de France.
Ces documents -en cours de rédaction- étaient appelés depuis quelques semaines RFC pour "Request for Comment" mais ce nom ne plaisait pas à tous les membres de la communauté SEPAmail  au motif qu'il était trop lié aux RFC de l'IETF et donc pouvait amener de l’ambiguïté.

Dans le même temps, nous étions quelques uns à baptiser des composants fonctionnels par des noms de code étant des mots anglais commençant par SM (pour SEPAmail) de 5 ou 6 lettres : smart, smile, smurf, smog, smite, smoothy, smoke...

Il fallait l'idée de la demande de commentaire et internaliser le concept dans SEPAmail sans ambiguïté pour l'IETF.

C'est donc avec un petit sourire satisfait qu'Olivier nous a suggéré à voix basse SMIRK.

Le nom s'est vite imposé, le genre un peu moins vite et certains considèrent encore le SMIRK comme un acronyme féminin.

Où peut-on trouver les SMIRKs ?

Les SMIRKS se retrouvent sur l'espace documentaire de SEPAMail à l'adresse http://documentation.sepamail.org/wiki/Standards:Demandes_de_commentaires.

Elles font partie des standards ouverts de la communauté et sont généralement une œuvre collective publiée sous une licence creatives commons avec utilisation commerciale paternité à l'identique.

Il y a actuellement sept SMIRKs publiées dont les deux premières en statut "validé" et les cinq suivantes en statut "discussion":

• SMIRK la missive dans le réseau interbancaire
• SMIRK le message SEPAmail
• SMIRK l'application SEPAmail
• SMIRK les référentiels
• SMIRK l'annuaire
• SMIRK la journalisation
• SMIRK la cryptographie

Quatre autres SMIRKs ont été prévues mais ne sont pas encore soumises à la communauté:

• SMIRK la qualité de service
• SMIRK l'escalade
• SMIRK le pilotage
• SMIRK l'organisation

Utilité

Les SMIRKs définissent les concepts utilisés et les règles à respecter par la communauté SEPAmail. Elles contribuent donc au standard SEPAmail.

Comme autres documents  du standard, on trouve également :

• les règles métier (BR pour Businness Rules) pour chacune des applications SEPAmail
• les directives d'implémentation (IG pour Implementation Guidelines) pour chacun des types de messages SEPAmail
• un schéma d'architecture fonctionnelle décrivant les couches utilisées et/ou définies par SEPAmail.

Organisation

Les SMIRK font d'abord l'objet d'un brouillon (draft).

Tout le monde peut écrire un brouillon. Ils n'ont donc aucune valeur, notamment normative.

Après avoir écrit un brouillon, on peut le soumettre au SCHEME (ou son bureau opérationnel, le QXOO).
Tous les brouillons n'étant pas dignes d'intérêt, ils ont une date de péremption. Si le brouillon attire l'intérêt de la communauté, un groupe de travail peut être créé pour la rédaction d'un SMIRK.

Quelques SMIRK finissent par devenir des standards de SEPAmail.

Vocabulaire SEPAmail : enveloppe, missive et message

La double encapsulation

SEPAmail met en œuvre une double encapsulation :

• le message SEPAmail est encapsulé dans une missive SEPAmail
• la missive SEPAmail est encapsulée dans une enveloppe SEPAmail

Le message SEPAmail

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

La missive SEPAmail

La missive SEPAmail sert à :

• l'adressage,
• l'identification des destinataire et expéditeur
• l'acheminement du message et notamment son horodatage

La missive est aussi construite dans un format XML.

La missive respecte toujours la structure suivante :

• un identifiant
• un type
• un ordre
• une priorité
• un entête contenant lui même l'adressage
• l'information à échanger (le message, l'acquittement, la commande, le résultat...) et une signature facultative de cette information si besoin

La missive peut être vue comme le support de toutes les indications d'acheminement de l'information.

L'enveloppe SEPAmail

L'enveloppe SEPAmail garantit :

• l'authentification du relais d'acheminement,
• la confidentialité de la missive,
• le transport de la missive sans révéler son adressage.

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

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

Pour aller plus loin

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

• la SMIRK missive
• la SMIRK message

Vocabulaire SEPAmail : la messagerie SEPAmail, les applications SEPAmail

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

 

La messagerie SEPAmail

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

 

Les applications SEPAmail

Les applications SEPAmail ont des noms de pierres précieuses.
A ce jour, on compte 7 applications :

• AGATE, la pièce jointe générique
• DIAMOND, la vérification d'identifiant bancaire
• GEMME, le mandat de prélèvement
• IOLITE, la transmission de facture
• JADE, l'avis de virement
• JASPE, la signature de document
• RUBIS, la demande de règlement

Une application SEPAmail utilise la messagerie SEPAmail pour échanger des messages structurés entre les parties dans un dialogue de type question/réponse avec la possibilité de joindre des documents. Comme la banque est un relais de cet échange, elle peut, si le contrat avec son client le précise, enrichir les flux et automatiser des opérations, notamment de paiement (carte, virement, prélèvement).

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

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

 

Pour aller plus loin :

• présentation de la messagerie SEPAmail
• présentation de la notion d'application (SMIRK APP1103 en discussion)