yral-dapp / hot-or-not-auth

Other
1 stars 0 forks source link

Design using canister signature #67

Open rosarp-gobazzinga opened 7 months ago

saikatdas0790 commented 7 months ago

@rosarp-gobazzinga Does this have the changes that we discussed today morning?

rosarp-gobazzinga commented 7 months ago

@saikatdas0790 Yes. I have updated this as per our discussion.

saikatdas0790 commented 7 months ago

@rosarp-gobazzinga Can we add more details to these steps in a separate diagram in the same document?

image

I am unclear on the following:

rosarp-gobazzinga commented 7 months ago
  1. Currently i'm using below code to generate random seed. We can do the same to generate for this usecase. https://github.com/go-bazzinga/hot-or-not-auth/blob/1caa1050e1d9af20bafb3d81bab1c845d3974cd2/src/auth/generate.rs#L45
  2. I will update the steps on diagram. (WIP)
  3. get_signed_delegation will be available on canister signer.
  4. I will update the steps on diagram or subsequently here. (WIP)
  5. As per what @rupansh-gob mentioned in last discussion, SignedDelegation can be used directly by frontend.
saikatdas0790 commented 7 months ago

@rosarp-gobazzinga @rupansh Hypothetical question, could we do the canister signature off chain if required? Imagine, for whatever reason, the on chain canister signer shuts off. With the random seed that we will have stored, could we rewrite the logic in canister signers to issue the signature ourselves from the auth server to ultimately generate a delegation that we can pass to the browser and that the user's canister can recognize as the same principal when the frontend calls into the canister?

rosarp-gobazzinga commented 7 months ago

Main premice here is that, canisters have root certificates which are being used to sign the delegations. This key part is not available off chain or anywhere else. We are considering this solution so that we dont have to store private key by ourselves. Its being part of on-chain certificates. What we are currently doing is off-chain and we will have to store private keys for users in such case.

saikatdas0790 commented 7 months ago

Let's discuss during a subsequent meeting

saikatdas0790 commented 6 months ago

@rosarp-gobazzinga Ideally a good idea to push code implementation as part of a separate pull request. I'm a big fan of frequent pull requests with small set of changes

saikatdas0790 commented 6 months ago

@rupansh can review code

rosarp-gobazzinga commented 6 months ago

I generally do separate changes. Will separate out these two changes. In this PR, only workflow diagram was pushed.