biscuit-auth/biscuit
1
1
Fork 0
mirror of https://github.com/biscuit-auth/biscuit.git synced 2024-10-06 02:27:33 +03:00
Code Issues Packages Projects Releases Wiki Activity

3rd-party: describe specific rules for public keys and symbol interning

Browse Source
This commit is contained in:
Clement Delafargue 2022-04-05 14:33:48 +02:00 committed by Clément Delafargue
parent 71c63b9b5d
commit 80afed104e
No known key found for this signature in database
1 changed files with 40 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
SPECIFICATIONS.md
View File

@ -474,9 +474,10 @@ for the final decision on request validation.
The token must first be deserialized according to the protobuf format definition,
of `Biscuit`.
The cryptographic signature must be checked immediately after deserializing. For the
`Biscuit` with a public key signature, the verifier must check that the public key of the
authority block is the root public key it is expecting.
The cryptographic signature must be checked immediately after
deserializing. The verifier must check that the public key of the authority
block is the root public key it is expecting.
A `Biscuit` contains in its `authority` and `blocks` fields
some byte arrays that must be deserialized as a `Block`.
@ -853,6 +854,8 @@ defined in a token or authorizer must start from 1024.
#### Adding content to the symbol table
##### Regular blocks (no external signature)
When creating a new block, we start from the current symbol table of the token.
For each fact or rule that introduces a new symbol, we add the corresponding
string to the table, and convert the fact or rule to use its index instead.
@ -866,6 +869,40 @@ block in order, the block's symbols.
It is important to verify that different blocks do not contain the same symbol in
their list.
##### 3rd party blocks (with an external signature)
Blocks that are signed by an external key don't use the token symbol table
and start from the default symbol table. Following blocks ignore the symbols
declared in their `symbols` field.
The reason for this is that the party signing the block is not supposed to have
access to the token itself and can't use the token's symbol table.
### Public key tables
Public keys carried in `SignedBlock`s are stored as is, as they are required for verification.
Public keys carried in datalog scope annotations are stored in a table, to reduce token size.
Public keys are interned the same way for first-party and third-party tokens, unlike symbols.
#### Reading
Building a symbol table for a token can be done this way:
for each block:
- add the external public key if defined (and if not already present)
- add the contents of the `publicKeys` field of the `Block` message
It is important to only add the external public key if it's not already
present, to avoid having it twice in the symbol table.
#### Appending
Same as for symbols, the `publicKeys` field should only contain public keys
that were not present in the table yet.
## Test cases
We provide sample tokens and the expected result of their verification at