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

vendredi 28 février 2014

Quelques implémentations logicielles du protocole SEPAmail

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

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

Ayant un peu suivi les questions qui se sont posées, je pense décliner quelques articles autour :
  • des utilisations dans l'état de l'art des protocoles SMTP, S-MIME, HTTP etc...
  • de quelques règles d'implémentation SEPAmail qui méritent d'être précisées ou discutées, notamment autour des identifiants et des dates
  • des codes de retour du protocole SEPAmail au niveau de la couche Missive
Voici la liste des implémentations logicielles dont je suis au courant (à ce jour), classées par ordre alphabétique des éditeurs :
  • AriadNext et son implémentation partielle d'un client Android
  • Atos et son implémentation complète en cours
  • Axway et son implémentation d'un passerelle SEPAmail
  • deciBI et son implémentation partielle d'un client open source SMURF
  • deciBI et son implémentation partielle d'un client open source SMETH
  • Deny All et son implémentation SEPAmail au sein de son pare-feu applicatif
  • Elcimai et son implémentation de test d'un client ebics pour SEPAmail 
  • CGI/Logica et son implémentation complète en cours
  • GFI/AriadNext et son implémentation complète d'un SMART/SMILE avec les applications RUBIS, TEST et DIAMOND
  • IBM et son implémentation SEPAmail au sein de son pare-feu applicatif Datapower
  • Lyra Networks  et son implémentation complète d'un SMART/SMILE avec les application RUBIS, TEST
  • PPI et son implémentation de test d'un client ebics pour SEPAmail
  • SOPRA et son implémentation d'une application mobile m-Rubis
  • SpeedInfo et son implémentation partielle d'un client eCommerce RUBIS
  • STET et son implémentation partielle d'un SMART/SMILE avec les applications RUBIS, GEMME, TEST et une application de conformité pour le compte de SEPAmail.eu
  • StreamMind et son implémentation complète d'un SMART/SMILE avec les applications RUBIS, TEST (GEMME est obsolète, DIAMOND est en cours), en partenariat avec HP pour la partie matérielle
  • TURBO et son implémentation complète d'un client créancier et débiteur pour RUBIS
Quatre des cinq adhérents actuels ont également intégré le protocole SEPAmail au sein de leur SI, multipliant donc les implémentations logicielles partielles sur des segments fonctionnels.

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

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

vendredi 8 juin 2012

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 

mercredi 6 juin 2012

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