Lignus wrote:Wouldn't work. No way to validate token without using it, therefore starting the countdown. Besides, with central issue and validation, you face inflationary risks on the part of the issuing authority.
You're absolutely right as it currently stands. But...
We're in process of building a token-validator tool so folks can check tokens to confirm they're legit, and what their expiry date/duration is. This is necessary both to confirm resellers are selling good tokens, and for members to know if their token is expired or almost expired.
(down the line, probably 1.1 version, the network access widget will display the token's status during network connection)
Tokens will be able to be, in other words, independently verified. We'll wrap this in a little SOAP-y API, I'm quite sure, as soon as someone's got time to document it properly.
Down the line it's very much the intention of the team to deploy a blockchain-style version of the token "database" so it can be publicly verified/authenticated in a peer-to-peer format. This also increases the resilience of the entire cryptostorm network, as exitnodes will be able to fallback to checking the "stormchain" version of the token "database" to validate network sessions. So, even if the entire
internal mongoDB-based authentication infrastructure were to somehow vanish, exitnodes could still accept network connections. Resiliency is good.
There's still some theoretical work to do on this, as the question of adding new tokens into the "stormchain" is an open one. Since most of this theoretical work falls on my shoulders to draft, first version anyhow, due to my odd mix of academic credentials, I'm unfortunately the bottleneck in getting this fleshed-out enough to present for public review and development.
Also, it's possible to generate tokens that have other attributes in addition to the ones we've used for darknet authentication: since the entire thing is noSQL-based, there's nothing that pre-defines the data model. Just add a "column" and off you go. Thus, as need dictates, there could be non-expiring tokens, tokens of various classes, etc. It's an intrinsically, open-ended model which is intended to support not only what we're doing with it, but additional specific use-case scenarios.
Having done much of the theoretical work on tokens, I can say that it's not been the
intention for them to be a generalised currency and we've not deployed the sorts of cryptographic components necessary to support that kind of use-case model in the token architecture. However, for small-ish, limited-value transactional work - particularly when it comes to privacy-centric, subscription-style auth needs, my hope is that the token auth model might help to generate additional uses for the model. (for example, the still-stealth 'cleanphone project' is token-based from top to bottom and the design of the token architecture was done in no small part in order to facilitate cleanphone needs, down the road...)
Above all else, making tokens
portable and
identity-independent (not tied to a specific person) serves the function (in a classical structural-functionalist perspective, for fans of old-school Malinowski-style social analytics
) of improving the security of network members. Put another way: the more decoupled tokens are from purchase by a specific person with a specific financial instrument, the more secure
all cryptostorm network members are,
ceteris paribus. This is functionally analagous to the increased per-user security Tor users gain from broader usage of Tor overall (by stochastically hardening the network at a macro level against traffic-analysis-based attacks).
There's some really interesting second-order consequences of
how we've deployed tokens in our production model that we've not yet published (just lack of staff time to write them up, not some decision to retain secrecy). In particular, the use of hashing functions to decouple token minting from network authentication is, if I may say so myself, something about which we're all quite proud.
More to come...
