quel avenir pour le projet STORK dans eIDAS ?

La commission européenne doit établir cette année pour eIDAS (electronic Identification and Trust Services) les normes et protocoles de la fédération des identités (FI) continentale. Avant de faire un tour des évolutions de STORK comme annoncé dans mon précédent billet, faisons un point d’information sur eIDAS.

Le règlement a été officiellement signé en séance et en ligne le 14 octobre. Le discours de la commissaire Neelie KROES est un véritable plaidoyer pour engager la prochaine commission dans une démarche de dématérialisation.

Hormis le fait que la Commission doit appliquer à elle-même ce qu’elle prévoit pour le continent, on notera que le besoin va au-delà de l’authentification. Il embarque aussi la signature, la fourniture de bien et la facturation.

Nos amis Estoniens ont lancé un ultimatum à la commission en promettant d’offrir, dès la fin de l’année, un titre de e-Résidents à qui en fera la demande. en effet ce titre sera associée à une eID (carte à puce) leur permettant de s’authentifier sur les services estoniens, mais sans doute dans toute l’Europe, si ce parcours d’inscription des identités est notifié.

l’enjeu en 2014

Ce sont bien les services qui tireront le système cette année, et ils le feront si l’intégration de la sécurité logique est simple et universelle. Par exemple, cette logique d’intégration de service se retrouve dans l’expérimentation d’une carte multifonction pour accéder à des services numériques et les transports. Elle est menée par L’imprimerie Nationale, Sopra et la ville de Bordeaux. C’est aussi l’enjeu cette année de Gemalto. Ce fournisseur de produit à base de carte à puce, a montré son excellence sur des modèles client / serveur et sa maîtrise du cycle de vie des documents d’identité numérique, mais aussi dans l’authentification mobile grand publique en Finlande.

Alors que les solutions foisonnent,  pourquoi s’encombrer de STORK ? C’est là qu’il faut relire les spécifications.

les évolutions depuis la v1

Les spécifications de STORK v2 sont publiées depuis septembre 2013.

Les principaux changements depuis la version 1 concernent:

• Les données personnelles
• La signature de document
• L’authentification au nom de quelqu’un d’autre
• L’anonymisation
• Le changement continue
   

les données métier

Les données personnelles qui étaient, dans la version 1, une liste figée d’attributs devient une véritable base d’information dont l’origine est multiple. C’est d’ailleurs un point qui rend incompatible la v1 et la v2 qui disposera de plusieurs sources d’informations, en plus de celles de l’IdP (National Attribute Provider = NAP).

Par exemple, mes données scolaires, mes mandats légaux et sociaux, mon dossier médical … Comme la source de ces informations ne dépend pas de l’IdP, la fonction de signature de l’AP change de sens pour simplement dire : “je sais d’où ça vient, mais je ne sais pas ce que cela dit”.

Dans l’exemple ci-dessous, une représentation du nouveau circuit d’authentification incluant deux fournisseurs d’attribut (Business Attribute Provider = BAP) en Autriche et au Portugal.

Le cas d’usage est le suivant : un Autrichien utilise un service Espagnol qui doit authentifier et collecter des données en Autriche mais aussi au Portugal.

Remarquons l’utilisation du modèle décentralisé (Middelware = MW) qui oblige le SP Espagnol à supporter l’accès aux ressources Autrichienne via le V-IdP.

Notons que chaque fournisseur d’attribut (BAP) peut demander une réauthentification. Mais pourquoi ne pas faire confiance à l’IdP de l’identité ?

Si ce n’est pas une obligation, ce serait au moins une simplification pour l’utilisateur. En fait, lier les identités contenues dans PEPS et dans le BAP n’est pas si simple.

A ma connaissance, ce mécanisme de chaînage d’information n’existe pas dans Mobile Connect, ou OpenID Connect. Avec SAML il existe un profil dédié à la recherche d’attribut, mais qui ne permet pas de chaînage.

la signature de document

La signature de document peut paraître accessoire par rapport à l’authentification et l’identification, mais si l’on met en œuvre cette fonctionnalité dans la facturation, elle devient un formidable moteur pour le système eIDAS. C’est même, à l’origine, l’une des premières motivations du projet.

De son côté, la Single Euro Payments Area (SEPA), l’espace unique de paiement en Euros, passe à la vitesse supérieure. Elle uniformise l’accès aux comptes bancaires dans la zone Euro, facilite les virements et impose aux banques des commissions équivalentes pour des actes équivalents. Il en va de même pour les factures électroniques. Toutes ces initiatives vont avoir besoin d’authentification et de signature. eIDAS est la solution commune.

D’ailleurs, les données métiers intègrent déjà les personnes morales, partie prenante dans une transaction commerciale, et ceci sous-entend l’intégration d’un nouvel identifiant : eLPidentifier (LP = Legal Person). Avec STORK v2,  signer un document à plusieurs doit devenir aussi fluide que s’authentifier à sa messagerie. L’API Mobile Connect et le standard SAML (Security assertion markup language) sont capables de prendre en charge la signature, comme de nombreux systèmes d’eID.

s’authentifier au nom de …

Cette fonction doit permettre aux personnes autorisées, d’agir au nom d’une autre personne. Par exemple, votre médecin, pourra récupérer certaines informations, en votre nom, auprès d’un organisme hospitalier. Ce principe existe déjà dans la vie courante, lorsque nous donnons une procuration pour récupérer un recommandé à La Poste, par exemple.

Ce qui n’est pas tout à fait clair c’est la forme du mandat qui sera accepté par le service devant agir au nom d’un autre. En effet, s’il existe un mandat dans les données métier, il n’est pas explicitement mentionné comme étant universel d’une délégation de pouvoir pour toutes les applications.

Avec la solution Mobile Connect vous pourrez toujours prêter votre mobile ;-), En revanche,  OpenID Connect et SAML ne permettent pas cette fonctionnalité.

un système anonyme - cas d’usage : le vote

Pourquoi s’authentifier pour rester anonyme ? Nous frôlons le paradoxe.

Je dois être identifié et authentifié pour voter (une voix = un vote), pour autant mon choix doit rester anonyme. C’est ce type de système que permet STORK v2. La remise d’un document, bien que faite dans un cadre authentifié, ne permet pas de remonter à l’identité.

Le document est découpé en paquets circulants sur le réseau des PEPS à différentes vitesses, avant d’être reconstitué. Avec ce principe, on dissocie l’identité et les paquets constituant le document original en les envoyant à des moments différents, c’est la technique du Latency Controlled Network (LCN).

mais pas d’accès anonyme ou neutre

De nombreux sites ne justifient pas forcément un suivi complet de l’identité.

Une solution serait d’identifié côté IdP, mais présenter au SP un identifiant neutre qui associerait l’utilisateur, non pas à une identité, mais à un profil.

Prenons l’exemple d’une publication par abonnement qui nécessite de savoir qui est l’abonné. La publication est neutre car identique pour tous les abonnés. Dans ce cas le numéro d’abonné suffit. Autre exemple, l’âge de l’utilisateur doit suffire pour pouvoir se connecter à un site pour adulte. L’adresse ou le sexe ne sont pas nécessaires.

Ceci étant, il est possible d’utiliser une authentification d’un service pour accéder à un autre sans qu’aucune information personnelle ne soit échangée. Exemple : le service de concierge canadien, SecureKey.

version Control

Première remarque le système n’est ni événementiel, ni basé sur le changement. Le PEPS lance, à intervalle régulier, des requêtes auprès de ces homologues ou des SP. Ces derniers répondent en donnant leur configuration, le PEPS calcul la différence et applique le cas échéant les changements.

Les spécifications ne sont pas vraiment précises sur les données de configuration échangées (c’est un fichier XML mais sous quel schéma ?). J’avais déjà signalé ce défaut dans mon précédent blog, mentionnant que, de son côté, SAML avait bien normalisé ces informations.

A mon sens, ce processus, considéré comme “sensible”, devrait bénéficier d’un meilleur traitement et utiliser les technologies multi-agents (que l’on devrait étendre, d’ailleurs selon moi, à la totalité du système).

Avec Mobile Connect c’est aux opérateurs de prendre en charge cette problématique. Pour SAML elle se fait entre chaque partie via le MetaData. Pour OpenID c’est une inscription chez le fournisseur de ressource.

pour un système multi-agent (SMA)

Les spécifications de STORK v2 caractérisent des agents de différentes natures et des protocoles. Elles ne préjugent pas de l’écosystème réel des agents.

Dans la première version du projet, une implémentation basée sur Java EE avait été réalisée pour supporter les pilotes (Large Scale Pilot).

Le compromis était sans doute acceptable pour des expérimentations limitées en nombre de transactions et d’agents. Il ne pourra pas en être de même pour la version définitive.

En effet, le réseau des PEPS et des SP va rapidement devenir une autoroute d’échange d’informations. Sans doute avec un maillage redondant pour supporter la charge et la robustesse. Une simple définition statique des nœuds du réseau se montrera donc insuffisante.

La technologie multi-agent (SMA) basée sur des agent cognitifs pourrait être une solution élégante à ce besoin. On trouve déjà ces solutions dans les réseaux de distribution d’énergie comme pour le projet WinPower. Le principe serait de donner de l’autonomie aux agents afin:

• de trouver les chemins les plus efficaces
• se dépanner les uns les autres en cas d’engorgement des C-PEPS
• faire des demandes de prestation dans un système d’enchère (acheter des certificats, des liens réseaux rapides et sécurisés, …)

En fait, de nombreuses tâches d’administration réalisées de bout en bout par des opérateurs humains pourraient avoir une place dans un SMA.

retour du RNIS

Nous disposons d’un réseau mondial de transport d’information Internet, avec des millions de services basés sur les technologies Web disponibles. Mais nous appliquons le même principe qui nous fait courir les rayons des supermarchés : trouver par nous même le produit qui satisfait nos exigences.

un navigateur ne suffit plus

Il faut passer à une autre échelle, ou nous devrons confier à un assistant le soin de faire les recherches et les négociations en notre nom. D’où l’intérêt d’un système de confiance comme STORK associé à des agents cognitifs capables d'interagir. Ce sont les briques élémentaires d’un nouveau réseau. Ce Réseau Numérique à Intégration de Service (RNIS) est la prochaine frontière. Ce que nous demandons à ces agents, c’est de comprendre la technologie actuelle et de nous aider à l’utiliser. Interagir en notre nom et suivant nos règles dans cette foire qu’est le Web.

Stéphane