hyperledger
Update auth_rules document to reflect the current defaults
The Default AUTH_MAP Rules document, although mostly accurate, does not fully reflect the default auth rules of a new indy-node network.
One example is the REVOC_REG_ENTRY ADD rule. The document states the owner of the corresponding REVOC_REG_DEF, regardless of role, can add new REVOC_REG_ENTRYs. The default auth_rules for the network on the other hand, indicate you need to be the owner of the corresponding REVOC_REG_DEF and have a signature from a Trustee, Steward, or Endorser.
Taken from a new network:
| REVOC_REG_ENTRY | ADD | * | - | * | { |
| | | | | | "auth_constraints": [ |
| | | | | | { |
| | | | | | "constraint_id": "ROLE", |
| | | | | | "metadata": {}, |
| | | | | | "need_to_be_owner": true, |
| | | | | | "role": "0", |
| | | | | | "sig_count": 1 |
| | | | | | }, |
| | | | | | { |
| | | | | | "constraint_id": "ROLE", |
| | | | | | "metadata": {}, |
| | | | | | "need_to_be_owner": true, |
| | | | | | "role": "2", |
| | | | | | "sig_count": 1 |
| | | | | | }, |
| | | | | | { |
| | | | | | "constraint_id": "ROLE", |
| | | | | | "metadata": {}, |
| | | | | | "need_to_be_owner": true, |
| | | | | | "role": "101", |
| | | | | | "sig_count": 1 |
| | | | | | } |
| | | | | | ], |
| | | | | | "constraint_id": "OR" |
| | | | | | } |
It appears the rule for adding a new REVOC_REG_ENTRY was updated in mid 2019, but the documentation was not updated to reflect the change in code.
The indicated discrepancy in the documentation may actually be a bug in the code. The initial code associated to the above indicated changes happened here, https://github.com/hyperledger/indy-node/commit/8d505a919dc13170a33ef99603d8ef0c921e5b19, and is associated with this Jira ticket, https://jira.hyperledger.org/browse/INDY-1554. The acceptance criteria for the ticket (in both settings cases) indicates the owner of the REVOC_REG_DEF should be allowed to write new REVOC_REG_ENTRYs.
First step would be to determine if this particular discrepancy is a bug or intentional.
So what I remember is that this went through a lot of review by the evernym team but we didn't change the documentation. But I would feel a lot more comfortable if @ashcherbakov would confirm.
@mac-arrap, What's throwing me off right now is the acceptance criteria of the jira ticket matches what is indicated in the auth_rules documentation, but it does not match the default auth_rule (included above) that was implemented in the code.