> - Signature de ce que tu as déclaré (exécuté sur ton navigateur, pas aux impôts) (bien sûr, très important)
Ca serait très important si le dit certificat était récupéré indépendamment de la déclaration aux impots, ou si il était utilisé globalement dans toutes nos communications avec l'état. Là il est donné par le même site, dans la même procédure, et n'a de valeur que dans cette procédure. En quoi est-ce important ? (comprendre : en quoi il ajoute une quelconque sécurité inexistante sinon ?)
> - Affichage de l'accusé de réception des impôts et génération du PDF associé (généré par une applet) (cet accusé de réception engage les impôts, c'est l'autre point important juridiquement)
L'affichage, un pdf suffit. La génération ça me parait totalement incohérent s'il est effectivement fait par l'applet côté client (quel valeur peut-il avoir dans ce cas ? au niveau certification/sécurité/assurance que tout s'est déroulé correctement ?)
En fait :
- affichage indépendant du navigateur : ton affichage dépendra toujours de ton lecteur, là tu as juste changé de lecteur pour dépendre de la jvm (d'où en partie le pourquoi ils vérifient la version de la jvm). Faire un code html standard et vérifier les navigateurs courants (avec une vérification du user agent comme ils le font sur la jvm) suffirait. Pour les parties vraiment critiques un doublage PDF suffit (et en plus c'est sauvegardable).
- sélection du certificat et signature de la déclaration : cf plus haut, ça n'ajoute strictement aucune sécurité vu le modèle qu'ils ont choisit. C'est joli en théorie mais la mise en application ici met totalement en échec les avantage de la signature
- affichage de l'accusé de réception : un PDF signé généré côté serveur irait très bien, je serait d'ailleurs étonné que même avec leur appli java ce n'est pas ce qu'il se passe.
Le seul point vraiment unique de l'applet par rapport à un bête html/pdf/http/ssl tu ne le listes pas : c'est l'assurance que l'application elle même (le contenu de l'applet) vient des impots sans modification (le ssl ne certifie que le fait que les impots répondent, il n'assure pas l'intégrité du contenu).
Maintenant pour ma part ce point justifie parfaitement la solution Java.
Le point qui leur a fait choisir Java est probablement bureaucratique/légal/administratif, c'est pouvoir marquer "signature électronique", même si concrêtement ça n'apporte rien. Bref, pas un point technique.
[^] # Re: Web, form et certificats...
Posté par Éric (site web personnel) . En réponse au journal Télédéclarer ses impôts et citoyenneté. Évalué à 1.
Ca serait très important si le dit certificat était récupéré indépendamment de la déclaration aux impots, ou si il était utilisé globalement dans toutes nos communications avec l'état. Là il est donné par le même site, dans la même procédure, et n'a de valeur que dans cette procédure. En quoi est-ce important ? (comprendre : en quoi il ajoute une quelconque sécurité inexistante sinon ?)
> - Affichage de l'accusé de réception des impôts et génération du PDF associé (généré par une applet) (cet accusé de réception engage les impôts, c'est l'autre point important juridiquement)
L'affichage, un pdf suffit. La génération ça me parait totalement incohérent s'il est effectivement fait par l'applet côté client (quel valeur peut-il avoir dans ce cas ? au niveau certification/sécurité/assurance que tout s'est déroulé correctement ?)
En fait :
- affichage indépendant du navigateur : ton affichage dépendra toujours de ton lecteur, là tu as juste changé de lecteur pour dépendre de la jvm (d'où en partie le pourquoi ils vérifient la version de la jvm). Faire un code html standard et vérifier les navigateurs courants (avec une vérification du user agent comme ils le font sur la jvm) suffirait. Pour les parties vraiment critiques un doublage PDF suffit (et en plus c'est sauvegardable).
- sélection du certificat et signature de la déclaration : cf plus haut, ça n'ajoute strictement aucune sécurité vu le modèle qu'ils ont choisit. C'est joli en théorie mais la mise en application ici met totalement en échec les avantage de la signature
- affichage de l'accusé de réception : un PDF signé généré côté serveur irait très bien, je serait d'ailleurs étonné que même avec leur appli java ce n'est pas ce qu'il se passe.
Le seul point vraiment unique de l'applet par rapport à un bête html/pdf/http/ssl tu ne le listes pas : c'est l'assurance que l'application elle même (le contenu de l'applet) vient des impots sans modification (le ssl ne certifie que le fait que les impots répondent, il n'assure pas l'intégrité du contenu).
Maintenant pour ma part ce point justifie parfaitement la solution Java.
Le point qui leur a fait choisir Java est probablement bureaucratique/légal/administratif, c'est pouvoir marquer "signature électronique", même si concrêtement ça n'apporte rien. Bref, pas un point technique.