Etat d'avancement du projet (mai 2018)

1.    FSI Broker 1.0 : Le FSI Broker a été développé en étroite collaboration entre la Confédération et les cantons. Il répond aux exigences fédérales d’un système de gestion des identités. Les services web (Relying Parties) reconnaissent les identités numériques des services de connexion externes (Identity Provider) et transmettent donc les tâches d’identification et d’authentification à un système tiers.

2.    Mise en oeuvre du concept de domaines : les domaines sont des infrastructures indépendantes de type FSI Broker, développées et configurées pour des groupes prédéfinis d’utilisateurs. Les domaines fonctionnent de manière autonome, ils ont chacun leur propre FSI Broker. Cet outil flexible est indispensable pour que les groupes concernés puissent établir le lien avec la fédération d’identités, notamment lorsqu’ils sont soumis à des dispositions légales spécifiques, applicables dans ce seul contexte. Niveaux de sécurité et de qualité, conditions d’accès pour les services web et de connexion, règles de transmission des identités et bien d’autres particularités sont propres à chaque domaine. Deux domaines ont été développés à ce jour : le domaine G2C (relation entre particulier et autorité) et le domaine G2G (autorités entre elles). La FSI peut en tout temps être élargie à d’autres domaines.

3.    Spécifications de l’interface FSI Broker 1.0 : c’est l’interface qui relie techniquement les fournisseurs de services d’identification (Identity Provider) et les services web (Relying Parties) avec la FSI.

4.    Plateforme d’intégration : c’est techniquement une plateforme d’exploitation, qui offre les services de FSI Broker 1.0 aux services d’identification et aux services web impliqués dans la phase pilote. Cette plateforme est opérationnelle depuis le premier trimestre 2018.

5.    Trust Framework : créer un espace de confiance représente un des principaux défis pour exploiter une fédération (un domaine FSI). Les Baseline Requirements définissent les exigences en matière de sécurité ainsi que les relations de confiance réciproques en fonction de règles contractuelles. Grâce aux Practice Statements, chaque partenaire de la fédération peut démontrer qu’il remplit les conditions des Baseline Requirements. Baseline Requirements et Practice Statements sont des termes empruntés au monde de l’ICP (infrastructure à clés publiques) et qui visent à renforcer la confiance dans une fédération d’identités. Les cantons ont cité ce trust framework comme condition préalable indispensable à une reconnaissance des identités fournies par une autorité externe.

6.    Trust model for G2G : le projet a défini ces Baseline Requirements pour le domaine G2G en concertation avec les experts de KPMG. Ou plus exactement : une description détaillée des conditions préalables techniques et organisationnelles que doit remplir un Identity Provider (IdP) s’il entend utiliser des identités avec un deuxième niveau de qualité (LOA 2) selon la norme eCH-0170 dans le domaine G2G.

 


HERMES

    Concept: 01.01.2016 - 30.04.2017
    Réalisation: 01.05.2017 - 31.08.2018
    Introduction: 01.09.2018 - 31.12.2019