playground

[fimbault]

This isn't an issue, but more a contribution. We have worked on a playground equivalent to jwt.io. We've seen it was on the roadmap, so hopefully it can help.

It is available at https://www.biscuitsec.org and the code is opensource. In the readme we credited clevercloud, but please let us know if you want the wording or the display to change.

We also tried to vary the examples, and try to explain through everyday life scenarios (compared to your main use case for pulsar).

Anyway, thanks for the biscuit, we think it's a great project.

Fabien & Mohamed

[Geal]

Hey, this is cool! In the generation part, maybe it would be easier to enter the fact and rules as text and use the parser in biscuit-rust? Could you mention Clever Cloud in the pages themselves too, and provide links to the specification here and the various implementations? The attenuate and verify pages could have a button to pregenerate a token instead of having to paste a token, don't you think?

btw, I see you already worked quite a bit with Biscuit, what's your main use case for the tokens? Do you have feedback to provide? On the spec, API, etc

[fimbault]

Thanks for your feedback.

Sure we can add the links on the site directly.

We had the idea initially to pregenerate a token in attenuate and verify (as is done in the start page), but the problem is that it quickly becomes more complex to explain, because we assume a structure already (if we have a token that includes /file1 for instance, it's hard to imagine cases which relate to another field, as we've done with cars). The plan is to make a comprehensive documentation to help newcomers (for us, it took a bit of time to understand some of the semantics). We wanted to propose examples outside the field of computing, to also explain the impact to a broader audience (even if people don't grasp the details of implementation or how to write a caveat, it's not that important at least as a first step).

We have several use cases :

• we're working on a new IAM offering (opensource, with a part currently being standardized at IETF). Our main use case for biscuit is to support alternatives to JWT, when it makes sense to support delegation directly from the token (and avoid some degenerate cases). We've also implemented biscuits as opaque tokens in AuthN/AuthZ scenarii, for a few customer cases so far.
• for our internal use, we're also following what you do on pulsar (although for us NATS would be a more natural choice) and microservices. But we haven't focused on that so far, and only used the rust version (which is best for our use case).

A small comment is that the title of the readme should probably be "Biscuit authorization token" (not authentication). The spec is fairly easy to read, I have some remarks but that would require a dedicated thread (or as I'm also French and living in Rennes, we can meet some time too). Have you considered at some point to propose biscuit as a standard? (there's pros and cons).
In terms of priorities, #35 makes a lot of sense of us. We made a few changes here and there within the library just for test purposes (to check we understood the internals), so maybe we'll contribute something here (but we have no timeframe so far).

[Geal]

We had the idea initially to pregenerate a token in attenuate and verify (as is done in the start page), but the problem is that it quickly becomes more complex to explain, because we assume a structure already (if we have a token that includes /file1 for instance, it's hard to imagine cases which relate to another field, as we've done with cars). The plan is to make a comprehensive documentation to help newcomers (for us, it took a bit of time to understand some of the semantics). We wanted to propose examples outside the field of computing, to also explain the impact to a broader audience (even if people don't grasp the details of implementation or how to write a caveat, it's not that important at least as a first step).

I think the first roadblock is understanding Datalog, so a small playground for that alone would be great. Then the knowledge can extend to Biscuit.

we're working on a new IAM offering (opensource, with a part currently being standardized at IETF). Our main use case for biscuit is to support alternatives to JWT, when it makes sense to support delegation directly from the token (and avoid some degenerate cases). We've also implemented biscuits as opaque tokens in AuthN/AuthZ scenarii, for a few customer cases so far.

that's an interesting use case! A thing I'd like to explore is to have a more server oriented datalog engine to test policies for an IAM.

for our internal use, we're also following what you do on pulsar (although for us NATS would be a more natural choice) and microservices. But we haven't focused on that so far, and only used the rust version (which is best for our use case).

we're also looking at solutions like record-store for multitenant access to a database

A small comment is that the title of the readme should probably be "Biscuit authorization token" (not authentication). The spec is fairly easy to read, I have some remarks but that would require a dedicated thread (or as I'm also French and living in Rennes, we can meet some time too).

I'll welcome all remarks, I'm sure the spec can be improved :) Ideally Biscuit would become a standard, but it's a good idea to explore usage first. A lot of ideas came after trying to integrate it. After a while it would make sense to propose it somewhere, probably the IETF (although the auth token space there is heavily oriented towards JWT). I'd be happy to meet, although these days I don't move much from Nantes for family reasons.

For public key signature, you could also look at what they have done at Flynn: https://github.com/CleverCloud/biscuit/issues/46 https://github.com/flynn/biscuit-go/pull/28/files

[fimbault]

Having a storage based on FoundationDB is an interesting idea, and record-store looks nice (despite a few bold statements in the Q&A "FoundationDB’s testing is more rigorous than Jepsen", which is hard to prove). But it is indeed extremely reliable and has a deterministic simulator to quickly check its correctness under various interleaving of failure scenarios. Implementing a grpc client shouldn't be too hard. Maybe there could be a compatibility issue between proto2 and proto3, but would have to test.

Just to provide an example of what I currently use in my own use case, the type of underlying definition (even as a basis for biscuits) looks like https://casbin.org.

I'll have a look to the other items.

[divarvel]

https://github.com/biscuit-auth/biscuit-web-components now provides a series of embeddable elements:

• a token inspector, authorizer and attenuator
• a token generator
• a datalog playground