mirror of
https://github.com/biscuit-auth/biscuit.git
synced 2024-09-11 06:15:30 +03:00
Update readme & remove mentions to caveats
This commit is contained in:
parent
736bf73e26
commit
705ce44a5f
17
README.md
17
README.md
@ -16,41 +16,45 @@ architectures with the following properties:
|
|||||||
- **offline delegation**: a new, valid token can be created from another one by
|
- **offline delegation**: a new, valid token can be created from another one by
|
||||||
attenuating its rights, by its holder, without communicating with anyone;
|
attenuating its rights, by its holder, without communicating with anyone;
|
||||||
- **capabilities based**: authorization in microservices should be tied to rights
|
- **capabilities based**: authorization in microservices should be tied to rights
|
||||||
related to the request, instead of relying to an identity that might not make
|
related to the request, instead of relying on an identity that might not make
|
||||||
sense to the verifier;
|
sense to the verifier;
|
||||||
- **flexible rights managements**: the token uses a logic language to specify attenuation
|
- **flexible rights managements**: the token uses a logic language to specify attenuation
|
||||||
and add bounds on ambient data, it can model from small rules like expiration dates,
|
and add bounds on ambient data, what it can model ranges from small rules like expiration dates,
|
||||||
to more flexible architectures like hierarchical roles and user delegation;
|
to more flexible architectures like hierarchical roles and user delegation;
|
||||||
- **small** enough to fit anywhere (cookies, etc).
|
- **small** enough to fit anywhere (cookies, etc).
|
||||||
|
|
||||||
## Non goals
|
## Non goals
|
||||||
|
|
||||||
- This is not a new authentication protocol. Biscuit tokens can be used as
|
- This is not a new authentication protocol. Biscuit tokens can be used as
|
||||||
opaque tokens delivered by other systems such as OAuth.
|
opaque tokens delivered by other systems such as OAuth.
|
||||||
- Revocation: Biscuit generates unique revocation identifiers for each token,
|
- Revocation: Biscuit generates unique revocation identifiers for each token,
|
||||||
and can provide expiration dates as well, but revocation requires external
|
and can provide expiration dates as well, but revocation requires external
|
||||||
state management (revocation lists, databases, etc) that is outside of this
|
state management (revocation lists, databases, etc) that is outside of this
|
||||||
specification.
|
specification. See the [revocation guide](https://www.biscuitsec.org/docs/guides/revocation/)
|
||||||
|
for more information.
|
||||||
|
|
||||||
## Roadmap
|
## Roadmap
|
||||||
|
|
||||||
You can follow the next steps on the [roadmap](https://github.com/biscuit-auth/biscuit/issues/12).
|
You can follow the next steps on the [roadmap](https://github.com/biscuit-auth/biscuit/issues/12).
|
||||||
|
|
||||||
Current status:
|
Current status:
|
||||||
|
|
||||||
- the credentials language, cryptographic primitives and serialization format are done
|
- the credentials language, cryptographic primitives and serialization format are done
|
||||||
- we have implementations for biscuits v2 in
|
- we have implementations for biscuits v2 in
|
||||||
- [Rust](https://github.com/biscuit-auth/biscuit-rust)
|
- [Rust](https://github.com/biscuit-auth/biscuit-rust)
|
||||||
- [Web Assembly](https://github.com/biscuit-auth/biscuit-wasm) (based on the Rust version)
|
- [Web Assembly](https://github.com/biscuit-auth/biscuit-wasm) (based on the Rust version)
|
||||||
- [Haskell](https://github.com/divarvel/biscuit-haskell)
|
- [Python](https://github.com/biscuit-auth/biscuit-python) (based on the Rust version)
|
||||||
|
- [Haskell](https://github.com/biscuit-auth/biscuit-haskell)
|
||||||
- we have implementations for biscuits v1 in
|
- we have implementations for biscuits v1 in
|
||||||
- [Java](https://github.com/clevercloud/biscuit-java) (migration to v2 is in progress)
|
- [Java](https://github.com/clevercloud/biscuit-java) (migration to v2 is in progress)
|
||||||
- [Go](https://github.com/flynn/biscuit-go)
|
- [Go](https://github.com/biscuit-auth/biscuit-go)
|
||||||
- a website with documentation and an interactive playground is live at <https://biscuitsec.org>
|
- a website with documentation and an interactive playground is live at <https://biscuitsec.org>
|
||||||
- Currently deploying to real world use cases such as [Apache Pulsar](https://github.com/clevercloud/biscuit-pulsar) at [Clever Cloud](https://www.clever-cloud.com/)
|
- Currently deploying to real world use cases such as [Apache Pulsar](https://github.com/clevercloud/biscuit-pulsar) at [Clever Cloud](https://www.clever-cloud.com/)
|
||||||
- looking for an audit of the token's design, cryptographic primitives and implementations
|
- looking for an audit of the token's design, cryptographic primitives and implementations
|
||||||
|
|
||||||
## How to help us?
|
## How to help us?
|
||||||
|
|
||||||
- provide use cases that we can test the token on (some specific kind of caveats, auth delegation, etc)
|
- provide use cases that we can test the token on (some specific kind of checks, auth delegation, etc)
|
||||||
- cryptographic design audit: we need reviews of algorithms, their usage and implementation in various languages
|
- cryptographic design audit: we need reviews of algorithms, their usage and implementation in various languages
|
||||||
- add support for biscuit v2 to java and go implementations
|
- add support for biscuit v2 to java and go implementations
|
||||||
|
|
||||||
@ -58,6 +62,7 @@ Current status:
|
|||||||
|
|
||||||
- `SUMMARY.md`: introduction to Biscuit from a user's perspective
|
- `SUMMARY.md`: introduction to Biscuit from a user's perspective
|
||||||
- `SPECIFICATIONS.md` is the description of Biscuit, its format and behaviour
|
- `SPECIFICATIONS.md` is the description of Biscuit, its format and behaviour
|
||||||
|
- `biscuit-web-key/` is a specification for publishing biscuit public keys
|
||||||
- `DESIGN.md` holds the initial ideas about what Biscuit should be
|
- `DESIGN.md` holds the initial ideas about what Biscuit should be
|
||||||
- `experimentations/` holds initial code examples for the crypographic schemes and caveat language. `code/biscuit-poc/` contains an experimental version of Biscuit, built to explore API issues
|
- `experimentations/` holds initial code examples for the crypographic schemes and caveat language. `code/biscuit-poc/` contains an experimental version of Biscuit, built to explore API issues
|
||||||
|
|
||||||
|
@ -4,7 +4,7 @@
|
|||||||
|
|
||||||
Biscuit is a bearer token that supports offline attenuation, can be verified
|
Biscuit is a bearer token that supports offline attenuation, can be verified
|
||||||
by any system that knows the root public key, and provides a flexible
|
by any system that knows the root public key, and provides a flexible
|
||||||
caveat language based on logic programming. It is serialized as
|
authorization language based on logic programming. It is serialized as
|
||||||
Protocol Buffers [^protobuf], and designed to be small enough for storage in
|
Protocol Buffers [^protobuf], and designed to be small enough for storage in
|
||||||
HTTP cookies.
|
HTTP cookies.
|
||||||
|
|
||||||
|
@ -12,7 +12,7 @@ signature, without contacting the server that created the token. Each attenuatio
|
|||||||
is done by adding a new "block" of logic data and rules. It is not possible to
|
is done by adding a new "block" of logic data and rules. It is not possible to
|
||||||
remove or replace a block while keeping a valid signature.
|
remove or replace a block while keeping a valid signature.
|
||||||
|
|
||||||
Biscuit uses a logic language called [Datalog](https://en.wikipedia.org/wiki/Datalog),
|
Biscuit uses a logic language based on [Datalog](https://en.wikipedia.org/wiki/Datalog),
|
||||||
to represent its authorization rules. It can model and combine authorization policies
|
to represent its authorization rules. It can model and combine authorization policies
|
||||||
like role-based access control or capabilities in a few lines, and even
|
like role-based access control or capabilities in a few lines, and even
|
||||||
have fine grained rules carried by the token.
|
have fine grained rules carried by the token.
|
||||||
|
Loading…
Reference in New Issue
Block a user