A SignCryption Token Proposal about libsodium-signcryption HOT 3 CLOSED

SCT's great and I like its simplicity!

Have you looked at Biscuit?

The choice of protobuf for serialization may not always be ideal, but Biscuit has some nice properties.

from libsodium-signcryption.

Thanks for the comment Frank!

Yes, Biscuit does appear to have some great properties, and there is definitely overlap in the bearer token aspect, and doesn't suffer from confusion attacks, but there are some challenges in my opinion (that I could be wrong about but here's my interpretation):

• The Biscuit spec is complex, SCTs are just four high-level libsodium function calls.
• Attenuation is very cool, but requires datalog interpretation.
• Attenuation also seems to drive the need for a complex format (protobuf).
• Most simple bearer token uses don't need attenuation.
• From my reading it does not support encrypted blocks.
• Biscuit implementations in as large an ecosystem of languages that already support libsodium would be a huge effort.

I think SCTs could be a basis on top of which one could implement Biscuit or PASERK like features, but my personal preference is to not mix layers like this. This is one concern I have with JWT and PASETO vis a vis JSON encoding, I feel like that's mixing a higher layer function with a transport, like saying a TCP stream required JSON. I think an SCT token can definitely transport attenuation claims, but I don't see the need to complicate this layer by requiring it.

from libsodium-signcryption.

I'm going to go ahead an close this issue here and open it up in a new repo for discussion as it's only tangentially related to this repo.

https://github.com/michelp/signcryption-token-spec/

from libsodium-signcryption.