[moyok]

The thing that scares me about using JWT is that all security completely relies on the one secret that is used to sign tokens - any person with access to that secret has got potentially unlimited access to the app. They can now impersonate any user and do basically anything.

[wtbob]

Yes, it'd be better if JWTs were full-fledged certificates, where ultimate authority could be confined to some offline key, who delegates authority for strictly delimited period to online keys. Or ultimate authority could belong to k out of a collection of n keys: one would need to suborn k keys to suborn the authority as a whole.

RFCs 2692 & 2693 specify a really great, lightweight, way to do that. They resulting certificates needn't be a whole lot heavier than a JWT, and are much lighter-weight than and X.509 certificate. The RFCs also specify an intelligent, domain-neutral algorithm for performing calculations on tags (what JWT refers to as 'claims') and keys.

It's a pretty awesome solution, and there are a lot of good ideas in there. A streamlined version could, I think, end up being competitive with JWTs.

[iheartmemcache]

SPKI was deprecated for SDSI[1] (also done by Rivest), both of which AFAIK haven't been touched in ~20 years (which is fine by me, if the theory and implementation are solid, but SDSI has CORBA/J2EE smells all over the RFC from what I remember. Lightweight, eh...)

[1] https://people.csail.mit.edu/rivest/sdsi11.html

[wtbob]

> SPKI was deprecated for SDSI

No, it's the other way around: SDSI was deprecated for SPKI, which took a lot of its ideas about naming from SDSI.

> both of which AFAIK haven't been touched in ~20 years (which is fine by me, if the theory and implementation are solid, but SDSI has CORBA/J2EE smells all over the RFC from what I remember. Lightweight, eh...)

SPKI is indeed old, but the fundamental ideas are really good, and some of them (the cert calculus) are timeless. It needs a v2.0 to update the recommended crypto, specify some more use cases and so forth. But it's really, _really_ good, far better than XPKI and extremely capable.

And still pretty lightweight.

[iheartmemcache]

Hey, if the conceptual grounds are sound, which I'm guessing they are, since... I mean, Ron Rivest, age doesn't quite matter w/r/t the timeless elements. Rijndael is mathematically sound, and honestly I've got more trust in older algorithms than newer ones if only because there's been more time for the populace to vet it[1] presumably fortifying it with time.

All of the resources I've searched for are fairly old, do you have anything more recent that I can read up on? I see a 2006 paper, but not much other than that.

[1] Though I'm well aware that having an open-standard available for a long time doesn't mean squat, as evidenced by Heartbleed-esque bugs.

Edit: Reading the '00 "A Formal Semantics for SPKI" Howell, Katz, Dartmouth. This is what I was looking for.

[wtbob]

I wonder what you think so far.

In particular, I liked the tuple-calculus they define; it can be extended to support just about any permission I can think of (although it does require reversing DNS names, which is slightly ugly).

I have a scheme to release a v2.0 of the standard someday in my copious free time.

[jessaustin]

Sometimes it's good to use asymmetric crypto, and those RFCs could perhaps be suitable for that. My impression of the parent comment is not that of a preference for asymmetric over symmetric, however, but rather of a lament that key-based crypto is defeated when attackers learn keys. After all the complaint about secret keys applies just as well to private keys.

[jessaustin]

The thing that scares me...

You should rotate your keys often enough to alleviate your fears. You probably ought to trust your MAC a lot more than you trust other links in the key-security chain, anyway.