search

GAIA-X4PLC-AAD / gx-credentials

TP 1: Create portable verified credentials on Tezos with public accounts
Apache License 2.0
8 stars 4 forks source link

Smart Contract #11

Closed jdsika closed 7 months ago

jdsika commented 1 year ago

Hi team,

I had a look at the smart contract.

1) I would suggest to remove the PKH of normal users. The key in the map searching for the entry should be the hash of the VC. 2) In order to be consistent we could also remove the pkh of the companies. The issuer can be identified by the hash of the VC. 3) multiple VCs can be presented at once and I suggest to transfer the VC of the company also to every individual vault (in altme) of users. 4) A user could then always present both VCs at the same time and the verifier backend could then just search using the VC hash not leaking pkh information. 5) The company VC could be stored in the gx credentials DB 6) The user VC should be deleted after the download in the alte vault AND the approval of the company admin 7) Please have a look at this example FA2 contract to figure out if we could handle the log entries as tokens? here

Those are my thoughts to be discussed.

Best regards Carlo

jfelixh commented 1 year ago

quick thoughts on this:

  1. Yes, that was always intended. That is a mistake made in the hurry to implement the design. The comment in the contract code still indicates this. Good catch.
  2. If you mean removing it from the index, then yes. But we cannot remove it from the log entry right now. We do not have access control on writing log entries and rely on checking that the person issuing the log transaction is the same as the issuer (when verifying a VC or when updating the log entry). Also, anyone datamining the chain could keep track of what address issued what log transaction anyway.
  3. Would potentially make sense.
  4. Yes, this would be a better option in terms of privacy. On the other hand, it does degrade user experience. Especially with plans to potentially have more intermediate issuers, such as departments, every employee might now need to keep track of a hand full of VCs in his trust chain and needs to remember to manually choose all of them for every presentation process.
  5. At least some info on the company VC needs to be stored so the GX Credentials operator knows what credential to revoke in case of trouble. So keeping the full credential might be the easiest and also a reasonable solution.
  6. Removing every trace of issuances for Employees through the system should be doable and is worth pursuing.
  7. Generally, we could. I am interested in pursuing this at a later time. Making log entries transferable might be a solution for employees leaving a company and handing over the right to revoke to their successor.
jdsika commented 1 year ago

@jfelixh I think the contract in the repo is different then the one on better call dev? https://better-call.dev/ghostnet/KT1AgNNsgQRigNTmLcQrhGPZafvdmvnLXXAZ/storage

jfelixh commented 1 year ago

The contract code on this repo is up to date. The contract you linked is a very early test deployment of an unfinished contract, if iirc. The specific deployment I use for testing is here for reference: https://better-call.dev/ghostnet/KT1KHhpL9Pk9DVh5GDnikH4Gx1kQ6NMb3GmC/storage

jdsika commented 11 months ago

Did you see this here? https://spherity.github.io/vc-ethr-revocation-registry/

jfelixh commented 7 months ago

Outdated in light of the coming architecture changes for improved revocation.