# ZSAs - Sign in with ZCash **URL:** \ **Category:** General\ **Created:** [October 6, 2021, 7:19pm UTC](https://forum.zcashcommunity.com/t/zsas-sign-in-with-zcash/40264 "2021-10-06T19:19:39Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![GGuy](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/gguy/32/19036_2.png) [@GGuy](https://forum.zcashcommunity.com/u/GGuy)\ **Post date:** [October 6, 2021, 7:19pm UTC](https://forum.zcashcommunity.com/t/zsas-sign-in-with-zcash/40264/1 "2021-10-06T19:19:39Z")
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. > [@ECC's work to date and next steps for ZSAs](https://forum.zcashcommunity.com/t/eccs-work-to-date-and-next-steps-for-zsas/39974/13): > > Thanks @tokidoki, With that in mind I’ll detail some of the scenarios I imagine a ZSA might play a part in (some of these might be a few versions down the line). TLDR; ZSAs should allow us to support any use case JOSE (JWTs, JWSs, etc) are used for. Only on chain we get the benefit of being transferable. voting token ECC airdrops 1:1 voting tokens to all holder of an asset (e.g. ZCash). Optional feature to allow setting an expiry/lock/destroy date. Token holders transfer their token to s… Can we discuss the feasibility of this happening, and if feasible is it something that should be a focus area? ---
**Author:** ![GGuy](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/gguy/32/19036_2.png) [@GGuy](https://forum.zcashcommunity.com/u/GGuy)\ **Post date:** [October 6, 2021, 7:44pm UTC](https://forum.zcashcommunity.com/t/zsas-sign-in-with-zcash/40264/2 "2021-10-06T19:44:56Z")
## problem - enterprise feasibility 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. ---
**Author:** ![GGuy](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/gguy/32/19036_2.png) [@GGuy](https://forum.zcashcommunity.com/u/GGuy)\ **Post date:** [October 8, 2021, 8:46pm UTC](https://forum.zcashcommunity.com/t/zsas-sign-in-with-zcash/40264/3 "2021-10-08T20:46:48Z")
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? ---
**Author:** ![tallship](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/tallship/32/19050_2.png) [@tallship](https://forum.zcashcommunity.com/u/tallship)\ **Post date:** [October 12, 2021, 12:37am UTC](https://forum.zcashcommunity.com/t/zsas-sign-in-with-zcash/40264/4 "2021-10-12T00:37:06Z")
## Quelle bonne idée! Sign me up for the alpha, I’ll be happy to implement it on at least a couple of dozen sites! 🤘 💀 🤘 . ---
**Author:** ![AustinChris](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/austinchris/32/45332_2.png) [@AustinChris](https://forum.zcashcommunity.com/u/AustinChris)\ **Post date:** [June 9, 2026, 3:07pm UTC](https://forum.zcashcommunity.com/t/zsas-sign-in-with-zcash/40264/5 "2026-06-09T15:07:08Z")
![IMG_20260609_160409_982](https://global.discourse-cdn.com/zcash/original/3X/e/6/e61acbbf879ca342257b2e608d4ed5569a61de22.jpeg) Just wanted to share some progress on this idea. I recently built SIWZ (Sign in with Zcash) — a practical implementation of the original concept. It currently supports three flows: - Memo-challenge (works with any shielded wallet: Zodl, YWallet, Zingo etc.) - Signed message paste - MetaMask + Zcash Snap (still experimental) npm packages: **@siwz/co_re_** , **@siwz/next-auth** , **@siwz/react** Still polishing some parts, but I’d really appreciate any feedback, especially on the memo-challenge approach. ---
**Author:** ![AustinChris](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/austinchris/32/45332_2.png) [@AustinChris](https://forum.zcashcommunity.com/u/AustinChris)\ **Post date:** [June 10, 2026, 3:05pm UTC](https://forum.zcashcommunity.com/t/zsas-sign-in-with-zcash/40264/6 "2026-06-10T15:05:53Z")
Quick follow-up since I can post links now. Repo: [https://github.com/AustinChris1/SIWZ](https://github.com/AustinChris1/SIWZ) Landing: [https://siwz.vercel.app](https://siwz.vercel.app/) 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.