En marge de SEPAmail : SAPPhire, prometteur

Au fil du projet SEPAmail, il y a des idées (portées par des hommes) qui sont simples et réalisables... moins brillantes peut-être que les dogmes de quelques experts mais elles m'ont séduit car je crois en leur potentiel de métamorphose du sujet qu'elle traite.

Je démarre avec une idée conjointe d'Alain Mazieras et Cyril Vignet : SAPPhire pour Standard pour une Authentification des Personnes et des Programmes, Haute interopérabilité et ré-utilisation en Extension (en français) ou Standard Authentication Persons & Programs High Interoperability and ReUse Extension (en anglais).


Le constat vient de le la nature même de l'authentification des êtres humains à distance.
Difficile, elle fait beaucoup parler les experts mais reste obscure pour les utilisateurs. Elle est notamment dangereuse car incomprise.

SAPPhire amène deux idées simples :

• idée 1 : on ne traite pas tous les cas mais seulement les trois principaux, ceux les plus utilisés et on les classe en trois niveaux
• idée 2 : on met en avant un fondamental de sécurité : l'authentification par rebond

Détaillons un peu ces deux idées.

Les niveaux SAPPhire orientés usages

Les usages nécessitant une authentification à distance déclarée sont :

• la consultation
• l'action
• la signature
• les autres cas (pour ne pas oublier !)

SAPPhire propose trois niveaux correspondant aux trois premiers cas:

• SAPPhire 1 : les conditons de la consultation
• SAPPhire 2 : les conditions de l'action
• SAPPhire 3 : les conditions de la signature numérique

auxquels on pourrait rajouter, pour être clair :

• SAPPhire 0 : les conditions de la non authentification

Pour prendre un exemple concret : quand vous vous connectez à votre webmail favori:

• pour consulter vos mail, vous êtes en SAPPhire 1
• pour écrire un mail, vous êtes en SAPPhire 2
• pour signer un contrat, vous êtes en SAPPhire 3

On voit que ce genre d'approche tient pour les usages courants depuis quelques dizaines d'années et peut durer encore quelques dizaines d'années.

Comment se décline techniquement ces niveaux ?

C'est bien entendu la question de SAPPhire. SAPPhire répond en fonction de l'état de l'art du moment. En ce moment, nos experts parleront de scoring et de cryptographie... jusqu'à ce que ces technologies soient dépassées ou passées de mode.

Les niveaux SAPPhire résisteront aux changements de mode puisqu'ils sont orientés usages et non techno.

L'authentification par rebond

Pour faire simple, l'authentification (en présence ou à distance) repose toujours sur un rapprochement entre des identifiants connus et des identifiants présentés.
Pour authentifier sereinement, il faut sécuriser ces trois points :

• les identifiants connus
• le rapprochement
• la présentation des identifiants à rapprocher

On en vient vite à un problème qui boucle sur lui-même, ce qui n'aide pas la sérénité.

Il est d'usage, pour éviter ces bouclages, de rebondir sur du connu :

• quelques personnes connues se portent garant de vous
• vous présentez une identification standard pour vous authentifier (par exemple une pièce d'identité)

SAPPhire propose un mécanisme d'inscription au service reposant :

• soit sur un rebond après, en validant une inscription a posteriori sur un canal sécurisé (par exemple un distributeur automatique de billet)
• soit sur un rebond avant, en validant une inscription a priori avec un authentifieur sécurisé (par exemple une clé ebics)
• soit sur un rebond réseau, en validant une inscription à l'aide de personnes authentifiées d'un réseau validant l'authentification avec leur propres critères et s'engageant sur cette authentification

Que faut-il a SAPPhire pour devenir un standard ?

SEPAmail fait la promotion de SAPPhire pour l'inscription au service sur le canal courriel sécurisé ou application mobile.

Cependant, SEPAmail ne suffira pas à généraliser SAPPhire. Il faudrait que les concepteurs de SAPPhire ou des volontaires, proposent une formalisation de ces deux principes au sein d'une RFC pour l'ietf par exemple ou encore qu'une institution comme l'Europe décide d'inclure ce type d'approche dans son référentiel de sécurité.

Avec l'avènement de sociétés gigantesques auto-proclamées tiers de confiance et de la cacophonie qu'elles proposent autour de l'indexation des populations, gageons que cette normalisation (ou une équivalente) va devenir nécessaire rapidement.

Pour aller plus loin

• mon billet sur la cryptographie, sujet complexe
• mon billet sur le démonstrateur SAPPhire utilisé par SEPAmail

SEPAmail et les wallets : comment est-ce que cela s'articule ?

Le wallet

Un porte-feuille électronique (ou wallet) est un stockage virtuel d'identifiants bancaires permettant d'initier des paiements de type électronique.

Le wallet est donc une fonctionnalité orientée stockage.

Plutôt que d'avoir sur vous votre chéquier, un porte-feuille contenant des billets et des pièces ou un porte-carte contenant de nombreuses cartes bancaires ou autre, le wallet vous propose de dématérialiser tout cela en un seul stockage virtuel pouvant être accédé par une application de votre téléphone portable ou votre ordinateur.

L'intérêt est évident car cela évite d'avoir toutes ses cartes dans son portefeuille physique, voir d'avoir un portefeuille... Le wallet peut en interface avec certains sites douteux générer un code de carte (PAN) unique afin de ne pas corrompre les identifiants bancaires... On peut même imaginer qu'il n'y ait plus de cartes bancaires physiques.

La sécurité de ce stockage et de votre authentification sont garantis, la plupart du temps par des techniques de cryptographie et une bonne assurance de l'éditeur de la solution.
Il faut en effet sécuriser :

• votre authentification sur votre terminal (smartphone ou pc)
• votre espace virtuel dans le cloud, hébergé par votre éditeur, contenant vos identifiants bancaires et les fonctions pour les transmettre à un tiers
• votre terminal (smartphone ou pc), dit environnement local de confiance qui réalise les opérations de cryptographie et qui est souvent le point faible du dispositif
• la liaison entre votre smartphone et le terminal de paiement, souvent sans contact

Toutes les techniques nécessaires sont connues pour cette sécurisation ainsi que de nombreuses failles. Peu d'acteurs communiquent dessus. Je vous renvoie à mon billet sur la cryptographie pour comprendre comment certains experts plutôt dogmatiques mettent en avant des systèmes qui seraient ultimes. Cela rassure et cela s'assure...
Le portefeuille électronique est donc la combinaison de deux modules

• le cœur du métier d'une application de paiement et de consultation
• un espace de stockage numérique (on pourrait dire dématérialisé pour l'utilisateur)http://sepamail.blogspot.fr/2012/07/sapphire.html

Entre les deux, les flux sont le plus souvent propriétaires en mode client/serveur sans interopérabilité annoncée entre les différentes solutions
du marché.

SEPAmail

SEPAmail est un standard d'échange de données sécurisé, ouvert et structuré.

SEPAmail codifie des fonctionnalités orientées flux.

SEPAmail permet le transport de toutes sortes de messages et de réaliser toutes formes de dialogues, du moment que le contenu du message et la séquence du dialogue sont structurés et prédéfinis.

Par exemple, SEPAmail permet d'échanger une demande de paiement et son refus/acceptation entre deux personnes, quelques soient les applications utilisées, les canaux d'initiation du paiement, les banques, les supports sécurisés des identifiants bancaire etc.
Les banquiers expérimentent une application utilisant SEPAmail qui s'appelle RUBIS. Elle permet cet échange d'information d'une demande de règlement entre leur clients, qu'ils soient particuliers, entreprises ou institutions.

SEPAmail permet d'inventer des dialogues divers. Plusieurs ont déjà été proposés à la communauté :

• autour de la demande de règlement (application RUBIS),
• autour de la signature de document (application JASPE)
• autour du mandat de prélèvement (application GEMME)
• autour de l'avis de règlement (application JADE)
• autour de la transmission de facture complexe (application IOLITE)
• autour du simple courriel ou du sms (application AGATE)
• autour de la vérification d'identifiant bancaire (application DIAMOND)

SEPAmail n'est donc pas un moyen de paiement; Il dit comment codifier un échange d'information qui permet éventuellement d'articuler une initiation de paiement et donc un paiement.

SEPAmail et les wallets

SEPAmail étant orienté flux, il permet de rendre interopérables des modules fonctionnels entre eux, relevant d'authentification différentes.

Cela pourrait être notamment :

• un wallet et un coffre-fort électronique,
• un wallet et un site eCommerce,
• un wallet et un système d'information bancaire
• un wallet et un DAB (Distributeur automatique de billet)
• un wallet et une caisse/tpe

Le site eCommerce est un bon candidat pour mettre en oeuvre SEPAmail avec les wallets car aujourd'hui l'éditeur du site est innondé d'offres de paiements diverses qui lui demandent de gérer une page de paiement illisible pour son client, des connexions concurrentes à d’innombrables interfaces propriétaires (API).

Si on prend le parallèle avec le point de vente physique, on est à l'époque où chacun proposait un terminal de paiement électronique (tpe) différent.
Imaginez le commerçant avec un TPE différent pour visa, mastercard, l'american express etc...

Il est vrai que, dans le domaine domestique, les téléspectateurs ont bien accepté depuis plus de 10 ans d'avoir 2 à cinq télécommandes dans les mains.

L'avenir nous dira si les éditeurs de boutiques e-Commerce acceptent de développer N prises de paiement à des wallets ou, comme beaucoup d'entre eux, s'ils préfèrent faire faire le travail par un intermédiant comme ogone, system-pay, paybox, etc... et les réactions de ces intermédiants à la multiplication des prises de paiement.

SEPAmail permet-il de sécuriser l'authentification des personnes  pour le wallet ?

Oui et Non.

Oui, car SEPAmail ne peut être mis en œuvre que dans des conditions d'authentification des personnes garanties par le fournisseur de l'accès à SEPAmail (adhérent du réseau).

Oui, car SEPAmail permet de transporter les éléments sécurisés nécessaires aux techniques de cryptographie.

Non, car SEPAmail ne codifie rien sur la nature de cette authentification, laissant l'adhérent mettre en œuvre sa solution vis à vis de ces clients.

Par contre, SEPAmail propose de généraliser un autre protocole qui pourrait faire référence dans ce domaine s'il venait à être généralisé: SAPPhire.

Avec SAPPhire + SEPAmail, n'importe quel wallet est interopérable avec application mobile, boutique e-commerce et module fonctionnel en général.

Gageons que les quelques acteurs monopolistiques qui essaient d'occuper 80% du marché vont se faire tirer l'oreille par les nombreux utilisateurs des moyens de paiements électroniques.