Salut tout le monde,

Je viens de finir une première version d'un module de signature électronique (format XML-Dsig) en javascript pur, qui utilise les modules eid Estoniens (https://github.com/open-eid, http://www.id.ee) pour servir d'intermédiaire entre le lecteur de cartes et la page web:

https://github.com/RvS-CdE/xmldsig_js


Le module nécessite l'installation du middleware estonien:
https://installer.id.ee/media/win/Eesti_ID_kaart-3.10.3.1575_x86.msi
https://installer.id.ee/media/win/Eesti_ID_kaart-3.10.3.1575_x64.msi

Ainsi que de l'addon nécessaire a votre navigateur (à moins que l'installateur ne l'ait déjà fait).

L'installateur est malheureusement en Estonien, mais comme il est lui aussi disponible sur github, rien ne m’empêcherait de faire un fork et de le traduire.


Le projet est encore expérimental, bien que je compte l'utiliser d'ici peu, et bien qu'il présuppose pas mal de choses, il devrait être fonctionnel.


Commentaires et questions sont les bienvenus, et si vous êtes tenté de l'utiliser, n’hésitez pas à me faire part des difficultés rencontrées


PS: la page de vérification XML-Dsig online n'a qu'un seul défaut, c'est qu'elle est encodée en ISO-8859-1: Si vous y collez de l'UTF-8, il sera converti automatiquement. Le seul moyen de vérifier une signature avec des caractères non-ASCII sur cette page est de modifier la page dans le navigateur pour ajouter un accept-charset="UTF-8" au formulare...

Hellow!

Ce n'est pas du javascript pur si il y a besoin d'un middleware, il y a un plugin côté client.

Et pourquoi se casser la tête avec un truc en estonien alors qu'il existe une applet belge? (et un middleware belge): https://code.google.com/p/eid-applet/

C'est pas faux

Disons que je préfère éviter java, pour un tas de raisons (valides et moins valides), et que j'ai une vague impression que le fedict fonce dans le mur.

L'emploi du middleware est effectivement un frein, mais un moyen temporaire efficace le temps que les lecteurs de cartes soient nativement reconnus par les navigateurs. L'addon estonien s'intègre très bien avec le standard WebCrypto actuellement mis en place dans les navigateurs, et est bien plus proche de ce que pourrait être un futur (et éventuel) standard que l'applet d'e-contract (qui n'est pas le fedict, c'est une société commerciale désormais, une sprl).

Désormais oui, mais le code a été écrit quand il bossait pour le fedict, c'est une applet du Fedict, pas de lui. Lui l'exploite commercialement, c'est une autre histoire

Mais si tu veux une solution sans Java, il te reste toujours la solution du reverse proxy, aucun besoin de java.

Je connais la solution du reverse proxy pour l'authentification, mais pour une signature électronique, j'avoue ne jamais en avoir entendu parler.


C'est dommage pour notre structure eID nationale, de voir qu'elle est au point mort depuis 2012. Il y a bien le fuameux service DSS, ou l'utilisateur quitte complètement le contexte de l'application pour y revenir par la suite, mais pour un développeur, c'est franchement moyen.

J'avais utilisé le SDK (qui n'a pas changé depuis) pour un add-on IE en C#, mais la gestion devenait trop encombrante (alors que Firefox proposait à l'époque nativement une signature #PKCS7).


Par ailleurs, Chrome va cesser le support des NPAPI, et donc par extension de Java. Dans les faits, l'applet EID cessera de fonctionner. e-Contract.be semble quant a lui proposer une solution payante... (et les estoniens vont réviser leur add-on pour chrome).

Ah non mais oui, j'ai dit signature en reverse proxy? Non, bien sûr, ça on sait pas

Un jour ce sera peut être enfin supporté en standard, mais j'ai comme un doute

Je ne suis qu'un simple utilisateur mais le middleware belge (ou l'applet) sont vachement buggués.

Je les ai déja testé avec différents lecteurs, et différentes applis et parfois faut insister fort beaucoup longtemps pour que la carte soit lue.

Par exemple (même si ca n'arrive qu'une fois par an) pour remplir ses contributions via tax-on-web.

Et de plus, cette solution est loin d'être a la portée du premier venu (Mr et Mme tout le monde) car elle ne fonctionne jamais correctement du premier coup !!!

Une alternative est donc toujours la bienviendue

Le W3C avait organisé un workshop en 2014. Le rapport final à conclu que "eh, ce serait vachement bien en fait !"... et donc il suffirait d'attendre un temps incertain...

Le groupe de l'API WebCrypto s'est formé en 2012, pour une implémentation dans les navigateurs en 2015 (ce qui est encore assez rapide pour le W3C). Avec un peu de chance, d'ici 2020 ...

On aurait pu aussi rêver de pouvoir utiliser l'USB en JS ( https://developer.chrome.com/apps/app_usb ), mais malheureusement, c'est mort pour du web pur, faut "une application"