It's worst when you're publishing an API and you need to support web clients, plus android, IOS and ideally not make things super difficult for customers using say, erlang.
As someone who used to regularly recommend things like "Use a high level / simplified library - try keyczar! Or crypto_box! etc" it has been disheartening to see how almost any even slightly niche choice will quickly devolve to developers having to pull in a bunch of dodgy looking objective-c code written say, 3 years ago by a single unknown developer.
It's usually worked out better from a whole-system perspective to stick with very widely supported standards (flawed as they are) and maintain a checklist of known footguns. It makes me sad.
Of course if your crypto is opaque to clients / not part of your integration surface then you've got a lot more wiggle room.
Perhaps what I've taken the long-winded route to getting to is, for anything where interop is important, I believe that popularity is absolutely valuable due to network effects and momentum.
- supporting public LAMP apps
- database servers that have public IP addresses that are barely filtered
- boxes not getting updates
- under-secured Linux boxes with almost every option recompiled to on
- chmod 777 developers
- substituting signatures of checksums for signatures of data
- not using HMAC and opening themselves up to length-extension and chosen plaintext attacks
- storing SSL/SSH private keys unencrypted on unencrypted laptops
- downloading HR data to a laptop and leaving it
I actually was fired once from a big name university in the SF Bay Area for refusing to haphazardly ruin the network security of a credit card processing private campus network to facilitate a new vendor remoting into terminals.
Integrity through awareness/caution, processes and standard components.
Bringing in a bunch of random dependencies, regardless of license or support status, is inviting all sorts of gaping attack surfaces.
In the context of security, popularity has the added benefit that there's enough eyeballs, so all bugs are shallow.
Every single company has no choice but to support JWT in some capacity. Whenever one has to use social auth (Google/Facebook/twitter), or Microsoft products (ADFS/Office365), or third party authentication solutions (Okta/auth0), they're de facto dealing with OpenID Connect + JWT (or SAML but that's a different topic).
We'll see about that. :)
> Every single company has no choice but to support JWT in some capacity.
This will change soon.
> Whenever one has to use social auth (Google/Facebook/twitter), or Microsoft products (ADFS/Office365), or third party authentication solutions (Okta/auth0), they're de facto dealing with OpenID Connect + JWT (or SAML but that's a different topic).
The plan for PASETO has always been to make it a JWT alternative for OIDC.
First comes the XChaCha RFC.
Second comes the PASETO RFC.
Finally, the OIDC-PASETO RFC.
1. https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03
2. https://github.com/paragonie/paseto/blob/master/docs/RFC/pas...
If they agree it's a good idea, it should pick up quickly.
