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.

Prérequis

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)

Fonctionnalités implémentées

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).

Fonctionnement du système

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 :

• Type de requête

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)

• Hash

Entre le backend et le frontend, string

• État d'un diplôme :

Du backend au frontend, un enum VALID, INVALID, FRAUDULENT donc string : "VALID", "INVALID", "FRAUDULENT"

• Identifiant de transaction

Entre le backend et le frontend, string (imposé par Hyperledger)

Endpoints

Type	Méthode http	Endpoint	Retour
Ajout		/requests/add?login={login}&hash={hash} login : string hash : string	✘ Erreur côté client : HTTPStatus→EXCEPTION_FAILED (417) ✘ Erreur côté serveur : HTTPStatus→INTERNAL_SERVER_ERROR (500) ✔ {transactionID : string, HTTPStatus→OK (200)}
Invalidation		/requests/invByHash?login={login}&hash={hash} login : string hash : string /requests/invById?login={login}&transactionID={transactionID} login : string identifiant de transaction : string	✘ Erreur côté client : HTTPStatus→EXCEPTION_FAILED (417) ✘ Erreur côté serveur : HTTPStatus→INTERNAL_SERVER_ERROR (500) ✔ {transactionID : string, HTTPStatus→OK (200)}
Revalidation		/requests/revByHash?login={login}&hash={hash} login : string hash : string /requests/revById?login={login}&transactionID={identifiant de transaction} login : string identifiant de transaction : string	✘ Erreur côté client : HTTPStatus→EXCEPTION_FAILED (417) ✘ Erreur côté serveur : HTTPStatus→INTERNAL_SERVER_ERROR (500) ✔ {transactionID : string, HTTPStatus→OK (200)}
Fraude		/requests/fraByHash?login={login}&hash={hash} login : string hash : string /requests/fraById?login={login}&transactionID={identifiant de transaction} login : string identifiant de transaction : string	✘ Erreur côté client : HTTPStatus→EXCEPTION_FAILED (417) ✘ Erreur côté serveur : HTTPStatus→INTERNAL_SERVER_ERROR (500) ✔ {transactionID : string, HTTPStatus→OK (200)}
Check		/requests/checkByHash?&hash={hash} hash : string /requests/checkByID?&transactionId={transactionId} transactionId : string	✘ Erreur côté client : HTTPStatus→EXCEPTION_FAILED (417) ✘ Erreur côté serveur : HTTPStatus→INTERNAL_SERVER_ERROR (500) ✔ {DiplomaState : string, HTTPStatus→OK (200)} où DiplomaState : string = enum { "VALID", "INVALID", "FRAUDULENT"}