search

Quintor / StudyBits

Apache License 2.0
6 stars 5 forks source link

Refactor Onboarding functionality in Wrapper #95

Closed PJUllrich closed 5 years ago

PJUllrich commented 6 years ago

We have onboarding functions in 2 different classes. createConnectionRequest and acceptConnectionResponse are in TrustAnchor acceptConnectionRequest is in WalletOwner

In the University backend code, the createConnectionRequest and acceptConnectionResponse functions are called via the Issuer class, which is a child class of TrustAnchor. In the Student backend, the acceptConnectionRequest is called via the Prover class, which is a child class of WalletOwner.

Should we maybe streamline the functions and the calls so that it becomes more clear where to find the onboarding functionality? Since TrustAnchor inherits form WalletOwner, maybe we can give the onboarding functionality to WalletOwner?

pimotte commented 6 years ago

The point of this is that in the way we've currently set it up, all DIDs go to the ledger, which means that a TrustAnchor needs to write them, this is we have the distinction.

pimotte commented 6 years ago

This issue also includes updating the roles to be proper (currently, onboarding allows for TRUST_ANCHOR, whereas only verinym should have this. This would allow simplifying the code as well.

pimotte commented 5 years ago

Was refactored.