Imagine going to a website and alongside the “sign in with Facebook” and “sign in with Google” there was also a “sign in with ZCash”. That’s the world I want to live in.
I discussed the idea of using ZSAs as a pseudo cryptographic token in the post below. But in short if done right ZSAs should be able to be used as “signing tokens”, and “access tokens”. We should also be able to use these tokens to allow 3rd parties to attest and link zcash addresses with emails and other accounts.
Can we discuss the feasibility of this happening, and if feasible is it something that should be a focus area?
The first issue I see is cost. Provisioning users might be a multi ZDA approach per users to provision all the appropriate user tokens, attestations, acls, etc. While spending $1000(?) to provision 100,000users might be reasonable, spending $1000 a day to provision on-chain access tokens might not.
solution 1 - off chain access tokens
We could just create an off chain access token e.g. JWT.
solution 2 - create a proof
We could use a combination of ZCash technology and traditional access tokens. Maybe embedding a proof into a JWT? Are there any real world benefits to this though?
solution 3 - fork zcash
To clarify I don’t mean a permanent fork. I’m referring to a temporary private chain which only contains the access token. This would allow some more “zcash” applications to be feasible like transfering access tokens to others etc. The only issue there is the access token becomes “all the blocks” that make up the side chain.
I guess the first practical step towards this goal would be adding supporting non-fungible asset (?) types. What’s the likelihood ZCash can support non-fungible assets in ZSA v1?
Packages on npm: @siwz/core, @siwz/react, @siwz/next-auth
For context on why memo-challenge rather than something requiring ZSAs: I noticed the pattern when buying a name a few months back from zcashnames. They use a tiny shielded payment as proof of address control, and that pattern generalizes into auth. It works on mainnet today, doesn’t depend on a protocol upgrade, and the cost per sign-in is dust paid by the user, so the enterprise-feasibility concern from the original post doesn’t really apply here. ZSAs would unlock a fourth flow (membership-by-asset-ownership) when they ship, but the basic auth primitive doesn’t need them.
