agorise
/
bsips
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

include more assert descrption and lisght rewriting

bsip53
Stefan Schießl 2018-07-27 14:43:51 +02:00 committed by GitHub
parent 815a50c802
commit 859169559d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
bsip-0040.md
View File

@ -40,9 +40,10 @@ The above list of named keys is nothing that is known to the backend as the back
# Rational
The description here is more on a superficial level and no recommendation how it can best be implemented.
Custom active permission is a list of custom active authorities. A `custom active authority` contains an `operation_id`, an `authority` (just like with active permission) and `asserts` than can be used to restrict arguments. When a transaction is signed with such an authority the backend checks if the contained operation has a corresponding custom active authority entry and if so acts as if the active authority of the corresponding account is given. If there are several custom active authorities, any matched one grants this, thus finding the first match is sufficient. It also checks if the arguments are in the allowed range.
Custom active permission is a list of `custom active authorities`. A `custom active authority` contains an `operation_id`, an `authority` (just like with active permission) and `asserts` than can be used to restrict arguments and is only valid a certain time period (`valid_from` and `valid_to`).
When a signed transaction arrives at the backend iterate the required accounts for each operations. If they have any one custom active authority that matches the given operation, signature and passes all asserts of the custom active authority, then the active authority of the required account is granted. This search can be stopped after finding one match.
A Custom Active Permission looks like follows (in JSON for clarification, backend serializes and stores in a different way):
A `custom_active_permission` looks like follows (in JSON for clarification, backend serializes and stores in a different way):
```
custom_active_permission = list of custom_active_authority items
custom_active_authority = {
@ -104,7 +105,7 @@ Requirements to modify the backend includes
* Operation-specific authorities (if present) must be evaluated in incoming transactions
* Additional committee parameters may be needed to limit the extend of usage of this feature
Note: The implementation must not differentiate the logic, all operations receive the same
Notes: The implementation must not differentiate the logic, all operations receive the same.
# Milestones
We propose do split the implmentation into two milestones:
@ -122,7 +123,7 @@ To be found in the [issue](https://github.com/bitshares/bitshares-core/issues/10
Bad publicity in terms of security can have very negative effect on the BTS value. This BSIP allows that traders can e.g. use a trading key, witnesses can use their witness key and a faucet can use a faucet key. If then for some reason the key or witness/faucet server becomes compromised, such a key can do little harm to the account holders, minimizing the risk.
This BSIP opens up a lot of use-cases for the backend as well.
This BSIP opens up a lot of use-cases as presented in Motivation section. The intention is to not alter any existing logic of the permission system, which reduces the risk of malfunctioning.
# Copyright