RICM5 2018 2019 - UGAChain - Choix de conception et programmation

Cette page est destinée à rassembler tous les choix de conception et de programmation qui ont été fait lors du projet UGAChain 2018-2019.

= Choix de conception = Cette partie est à adosser à la page dédiée à la description de la conception du projet.

Diplômant

 * Le diplômant conserve la version numérique ou le numéro de transaction de tous les diplômes (pour pouvoir les invalider)
 * Le diplômant assure la non reproductibilité d'un diplôme à partir des informations qu'il contient (afin d'éviter une attaque du type construction du diplôme puis requête à UGAChain)

Vérification de diplôme
Pour des questions de performance, il est intéressant de conserver la fonctionnalité de vérification de diplôme à partir du diplôme sous format numérique et du N° de transaction, sans vérifier une éventuelle transaction d'invalidation qui impliquerait un parcours total de la blockchain. On appelle cela la recherche "légère". Avec cette fonctionnalité vient la question de la réintroduction de la fonctionnalité de récupération du numéro de transaction à partir d'un diplôme, et donc de l'acteur "diplômé".

La deuxième fonctionnalité de vérification à partir du diplôme seulement (qu'on appellerait recherche "profonde"), impliquerait le parcours de la channel d'ajout pour vérifier la présence du diplôme dans la base de données, puis une recherche dans la seconde channel pour en vérifier l'état : valide/invalide.

On a ainsi 2 channels, dans le premier sont stockés uniquement les transactions d'ajout, et dans la deuxième les transactions de changement d'état (invalidation et éventuellement les nouvelles-validations).

Hashage
On ne hache pas les métadonnées du diplôme (sa validité par exemple) :
 * afin de pouvoir invalider un diplôme inséré frauduleusement dans la chaîne de blocs, à partir du hash du diplôme uniquement (récupération du hash du diplôme de la transaction frauduleuse, insertion d'une transaction contenant ce hash avec des métadonnées d'invalidation)
 * afin de pouvoir créer des transactions d'anciens diplômes avec de nouvelles métadonnées sans avoir à hacher de nouveau le diplôme (cas d'usage : ajouter une métadonnée à tous les diplômes précédemment insérés dans la chaîne de blocs)

= Choix de programmation =

API frontend-backend
On passe dans un premier temps les paramètres de l'API dans l’URL, par facilité.

Objets transitant
Vont être communiquées via cette API les informations suivantes :

Du frontend au backend, passé par le endpoint auquel on accède (en frontend et backend résulte en un enum : ADDITION, INVALIDATION, REVALIDATION, FRAUD_REPORT)
 *  Type de requête

Entre le backend et le frontend, string
 * Hash

Du backend au frontend, un enum VALID, INVALID, FRAUDULENT donc string : "VALID", "INVALID", "FRAUDULENT"
 * État d'un diplôme :

Entre le backend et le frontend, string (imposé par Hyperledger)
 * Identifiant de transaction