Conversation
| is a Biscuit token, that base 64 string should be prefixed with `biscuit:`. | ||
|
|
||
| ### Cryptography | ||
| ## Cryptography |
There was a problem hiding this comment.
Putting the cryptography section at the same level as the format section
| If all signatures are verified, extract pk_n+1 from the last block and | ||
| sig from the proof field, and check `verify(pk_n+1, sig_n+1, data_n+alg_n+1+pk_n+1+sig_n)` | ||
|
|
||
| ### Blocks |
There was a problem hiding this comment.
this is already covered in a different part of the spec
| them with its rules list. | ||
|
|
||
| ### Symbol table | ||
| ## Symbol table |
There was a problem hiding this comment.
the symbol table section is moving up a level. Maybe it should move under the format section though?
There was a problem hiding this comment.
maybe we should rename it to "string interning", since it’s not just a serialization matter
divarvel
left a comment
There was a problem hiding this comment.
a few comments / suggestions / typo fixes
| transmitted over the wire is either the normal Biscuit wrapper: | ||
| The token contains two levels of serialization, each with its own versioning scheme. | ||
|
|
||
| ### Signed blocks |
There was a problem hiding this comment.
| ### Signed blocks | |
| ### Signed blocks | |
| } | ||
| ``` | ||
|
|
||
| The `rootKeyId` is a hint to decide which root public key should be used |
There was a problem hiding this comment.
| The `rootKeyId` is a hint to decide which root public key should be used | |
| The `rootKeyId` is a hint to help the consumer decide which root public key should be used |
|
|
||
| The `rootKeyId` is a hint to decide which root public key should be used | ||
| for signature verification. | ||
| The `authority` block has a special meaning, as it is signed by the root key, |
There was a problem hiding this comment.
these should be bullet points or have a line break after them
| } | ||
| ``` | ||
|
|
||
| The `SignedBlock` structure carries the sigend data and its signatures, representing the |
There was a problem hiding this comment.
| The `SignedBlock` structure carries the sigend data and its signatures, representing the | |
| The `SignedBlock` structure carries the signed data and its signatures, representing the |
| - `externalSignature`: if present, it is a signature of the current block by another key | ||
| - `version`: indicates the version of the signed payload format | ||
|
|
||
| The version field is used to vary how the block is signed and verified. |
There was a problem hiding this comment.
| The version field is used to vary how the block is signed and verified. | |
| The version field is used to specify how the block was signed and must be verified. |
| The `rootKeyId` is a hint to decide which root public key should be used | ||
| for signature verification. | ||
| Public keys are serialized as a byte array, with the `algorithm` field discriminating between | ||
| algorithms. The algorithm depedent serialization format is described in the [Cryptography section](#Algorithms). |
There was a problem hiding this comment.
| algorithms. The algorithm depedent serialization format is described in the [Cryptography section](#Algorithms). | |
| algorithms. The algorithm-dependent serialization format is described in the [Cryptography section](#Algorithms). |
| ``` | ||
|
|
||
| Each `SignedBlock` contains: | ||
| - `block`: a `Block` structure serialized as a byte array |
There was a problem hiding this comment.
maybe we should hint that why there are two layers of serialization (unless it’s already done somewhere else)
| was generated. Since a Biscuit implementation at version N can receive a valid | ||
| Each `Block` contains the following fields: | ||
| - `symbols`: the list of new [symbols](#symbol-table) introduced in this block. | ||
| - `context`: a free form field with no particular meaning for Biscuit authorization. It can be used to hold application specific data |
There was a problem hiding this comment.
| - `context`: a free form field with no particular meaning for Biscuit authorization. It can be used to hold application specific data | |
| - `context`: a free-form field with no particular meaning for Biscuit authorization. It can be used to hold application specific data |
|
|
||
| When transmitted as text, a Biscuit token should be serialized to a | ||
| URLS safe base 64 string. When the context does not indicate that it | ||
| URL safe base 64 string. When the context does not indicate that it |
There was a problem hiding this comment.
| URL safe base 64 string. When the context does not indicate that it | |
| URL-safe base 64 string. When the context does not indicate that it |
| them with its rules list. | ||
|
|
||
| ### Symbol table | ||
| ## Symbol table |
There was a problem hiding this comment.
maybe we should rename it to "string interning", since it’s not just a serialization matter
No description provided.