HN user

ZoneGhost

9 karma

[ my public key: https://keybase.io/zoneghost; my proof: https://keybase.io/zoneghost/sigs/U5ekzbgYGE2jewDOtZYOB_wfDZdgZMCBT_KViljOJmM ]

Posts0
Comments5
View on HN
No posts found.

There's nothing a library can add to make things "safer" when it comes to application-specific constraints. If I'm checking to make sure I only accept a specific algorithm, I'm not going to blame a crypto library for validating something that is technically accurate (short of maybe disabling the "none" algorithm by default). You should also be in possession of at least the public key beforehand, and rely on that for authentication, rather than anything in the claim.

For the record, JWT is a payload and format spec for JWS/JOSE, which is really what you're complaining about. JWT is merely a claims set and an optional dot-notation serialization of a single signature.

JWT/JWS libraries that handle all the validation alone are treacherous. You should ALWAYS parse the JSON before hand, perform your claims and header(s) validation, and then pass the payload/header/signature. If anything, it's computationally less risky than running the signature blindly through a signature validation function and then checking the header.

Eventually, these models have to change. Someone is going to start writing open data layers that replace key value points in these businesses. The companies that operate on these "gig" models do a few things that sum to a greater whole:

  1) Marketed web front-end for consumers
  2) Confidence aggregation / metrics for both parties
  3) Payment gateway / escrow service
  4) Insurance and (sometimes) materials
I think we'll see blockchain tech replace the (2) and (3)'s here. With a decentralized ledger and some form of third party "notary", you can verify ratings for an incredibly small fee. Payment gateways and automated three-party escrow services are easy with multisig transactions, and can be converted to any other currency through coinbase, circle, or whatever.

The (1) point could be replaced by an indirect revenue model, or by open aggregation apps.

(4) would then be put back in the hands of the actual service provider, where contractual liability belongs. A new business model could be born, where "Uber" simply has a nice phone app that references public blockchains to get you a driver, and sells insurance packages to drivers themselves. They wouldn't be locked down to just being an "Uber" driver, however.

iojs is definitely not the "standard" by any means... It's accelerating at a quick pace, but I haven't heard of any major sites making the switch yet. Many native modules (node-gyp compiled) aren't functioning yet, and the streams module was a bit finicky as of a couple weeks back. I'm looking forward to the market competition actually. Can't go wrong with having two standards battle to be the best.