Rapport sur les résultats

Annexe 8

1.2 TOE Overview

OFAC observe que LDEP a été traduit en anglais par « FLEHR », mais qu’ODEP n’a pas été traduit. Soit l’on s’en tient à la règle stricte de traduire en anglais la terminologie spécifique à la LDEP, soit l’on traduit tous les textes dans nos langues officielles. De plus, les logos et traductions de la Confédération, du DFI et de l’OFSP ne sont pas présents de manière constante dans tout le document. Logos et traductions doivent être homogènes et idéalement traduits dans la langue du document. En ce qui concerne le ch. 1.2.1, La Poste fait remarquer que la TOE Definition ne permet d’authentifier ni les procédés biométriques, ni les procédés comportementaux. Or, on ne pourra pas appliquer mTAN sans une adaptation appropriée. La Poste demande donc que l’on reprenne les définitions de la norme ISO 29115, chap. 3.3 au lieu d’introduire une définition de « device ». Elle signale en outre, au sujet du ch. 1.2.2, que le choix du terme « identification means » est impropre. Il faut parler d’« authentication means » pour les moyens d’accomplir le processus d’authentification, alors que le terme d’« identification means » désigne les moyens d’identifier une personne. Cette erreur est à corriger. En outre, le terme « holder of the token » implique que les procédés qui se passent de « token » (jeton) sont interdits de facto. Le terme de « token » doit être remplacé par celui d’« authentication factor », issu de la norme ISO 29115. D’autre part, la description du TOE indique que seuls les procédés fondés sur le NIP sont admis, ce qui soulève le problème des procédés qui n’utilisent pas de NIP. Le TOE doit être reformulé de manière à décrire à la fois la procédure d’authentification et celle faisant appel au NIP. Enfin, on note l’introduction du terme de « context ». Celui-ci n’a pourtant rien à faire dans la thématique de l’authentification. L’authentification vise à vérifier si l’identité affirmée par l’usager est correcte. La question du contexte relève plutôt de la procédure d’autorisation. Que l’éditeur du moyen d’identification ait ou non besoin de ce contexte pour sélectionner le procédé d’authentification approprié est une question « hors champ » (out of scope) pour ce document. Les références à ce contexte doivent donc être effacées ou marquées comme facultatives. SCH déclare au sujet du ch. 1.2.2 que les explications relatives au workflow d’authentification sont certes très détaillées, mais ne décrivent que la « IdP-Initated Approach ». Le choix du workflow préféré pour l’authentification (IdP-/RP-initiated approach) pour le dossier électronique du patient doit être laissé aux fabricants d’applications. En outre, les protocoles entre Relying Party et NIP, ainsi que les procédures d’authentification, doivent être réglés par le marché. Enfin, il serait plus simple de guider l’utilisateur en l’invitant à se rendre sur le portail du dossier électronique du patient et à s’y connecter avec ses paramètres. C’est en tout cas l’expérience faite par de nombreux utilisateurs. L’acceptation du dossier électronique du patient s’en trouve aussi améliorée. SCH demande que l’on supprime l’option de s’authentifier par l’IdP-initiated Workflow. Il faut se contenter de fixer les conditions et les résultats de l’authentification sans prescrire les démarches pour y parvenir. SCH fait en outre les propositions suivantes : Electronic identification means comprises one or more token that are secured by a device. Each token may hold a credential, that is used by the IdP to authenticate the user’s identity based on possession and control of the corresponding token. An IdP-initiated or SP-initiated approach may be used.

1.5 Assets

Au sujet du tableau 1, La Poste signale que les descriptions sont énoncées de telle manière que seules des procédures utilisant la smart card sont possibles. Il faut les modifier pour permettre l’utilisation du mTAN ou d’autres moyens sans recours à une smart card. La Poste demande que l’on reprenne les définitions de la norme ISO 29115, chap. 3.3. Elle observe en outre, à propos du ch. 1.5 :

- Public keys by definition are public and they need to protection. Si on comprend bien ce que la phrase est censée vouloir dire, la formulation est cependant fautive. Demande : Term to be used here is "private keys".

- The expectation in the example of "identification data" is not tenable. Using a combination of attributes to uniquely identify a user seems like a bad choice. Please note that GLN is an extremely dan-