ECC's work to date and next steps for ZSAs

General
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

  1. 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.

  2. Token holders transfer their token to specified address(es) to vote (with memo if required).

Features?
Ability to airdrop X:Y ratio of tokens.
Maybe expiry (think JWT claims)

transferable signing token

  1. Issuance of a non-fungible token to be used for signing.

  2. Online attestation service signing and storing on chain somehow (e.g. linking email accounts to ZCash addresses).

  3. Attestation business is sold and signing token is transfered.

Features?
What even is a signing token anyways? Is it just the ability to issue new ZSAs (maybe non-fungible?) referencing itself (aka issuer) and the material to sign?
Issue a (non-fungible?) token referencing issuer (signing token) and material being attested (on-chain or off-chain data/hash/key/etc).
Ability to transfer signing token and original owner no longer has the ability to sign.

transferable access token - non-fungible

  1. Online service issues access token upon successful authentication. Optional on chain issuance, approved actions, expiry, etc.

  2. Transfer access token to partner to act on my behalf.

  3. Partner uses service on behalf of user.

Features?
APIs for service to service to do token based authentication and authorisation.

4 Likes