Compile, validate and apply endorsement rules for CANdy Prod

[esune]

The CANdy Prod endorser has been set-up to require manual endorsement of transactions for existing registered authors in an effort to facilitate applying governance. While this works well for schemas and credential definition transactions that have already been endorsed and written, errors may arise when endorsement of a new revocation registry definition and/or revocation registry entry is required.

To resolve this:

• Review which schemas/credential definitions have been published by each issuer.
• Compile allow-lists matching the known endorsed objects, so that revocation registry definitions and entries are automatically endorsed.
• Confirm with executives the "goodness" of the rule-set.
• Apply configuration to the appropriate endorser service.

[WadeBarnes]

The official auth_rules for CANdy Prod can be found in a human readable format here; https://github.com/ICCS-ISAC/Candy/blob/main/environments/prod/auth_rules

The following rules are defined for REVOC_REG_DEF:
https://github.com/ICCS-ISAC/Candy/blob/ffadb47d3389d73c13afbbe05c3d26697c885846/environments/prod/auth_rules#L329-L344

• In summary writing a REVOC_REG_DEF requires an Endorser signature.

# =================================================================================================================================================================
# Add/Edit Revocation Registry Definitions
# -----------------------------------------------------------------------------------------------------------------------------------------------------------------

# Add Revocation Registry Definition
#  - Require 1 Endorser signature
#  - Source: Draft Governance; Governed Role Policies: Registered Entity (https://github.com/ICCS-ISAC/Groupes-de-travail-CANdy-Working-Groups/blob/main/Provisional-GF-provisoire/(Layer%201)-CANdy-Utility-Provisional-Governance-Framework#governed-role-policies-registered-entity)
#  - The desire is to define the rule for this as
#    {"sig_count":1,"role":"*","constraint_id":"ROLE","need_to_be_owner":true}
#    where the context of owner is the associated CLAIM_DEF.
ledger auth-rule txn_type=REVOC_REG_DEF action=ADD field=* old_value=* new_value=* constraint="{"sig_count":1,"role":"101","constraint_id":"ROLE","need_to_be_owner":false}"

# Edit Revocation Registry Definition
#  - Require 1 Owner signature
ledger auth-rule txn_type=REVOC_REG_DEF action=EDIT field=* old_value=* new_value=* constraint="{"sig_count":1,"role":"*","constraint_id":"ROLE","need_to_be_owner":true}"
# =================================================================================================================================================================

The following rules are defined for REVOC_REG_ENTRY:
https://github.com/ICCS-ISAC/Candy/blob/ffadb47d3389d73c13afbbe05c3d26697c885846/environments/prod/auth_rules#L347-L359

• In summary, the author/owner of the associated REVOC_REG_DEF can freely write REVOC_REG_ENTRYs.

# =================================================================================================================================================================
# Add/Edit Revocation Registry Entries
# -----------------------------------------------------------------------------------------------------------------------------------------------------------------

# Add Revocation Registry Entry
#  - Require 1 Owner signature
# - Source: Popular vote
ledger auth-rule txn_type=REVOC_REG_ENTRY action=ADD field=* old_value=* new_value=* constraint="{"sig_count":1,"role":"*","constraint_id":"ROLE","need_to_be_owner":true}"

# Edit Revocation Registry Entry
#  - Require 1 Owner signature
ledger auth-rule txn_type=REVOC_REG_ENTRY action=EDIT field=* old_value=* new_value=* constraint="{"sig_count":1,"role":"*","constraint_id":"ROLE","need_to_be_owner":true}"
# =================================================================================================================================================================

[esune]

I compiled a list of what has so far been endorsed in production - excluding Trustee/Steward DIDs since I believe those were done manually when setting-up the network.

Allowed DIDs:

Public DID	Description
RGjWbW1eycP7FrMf4QJvX8	IDIM
E2h4RUJxyh48PLJ1CtGJrq	BC VC Pilot Issuer
A2UZSmrL9N5FDZGPu68wy	Chief Permitting Officer of Mines
AcZpBDz3oxmKrpcuPcdKai	BC Registries Prod
XqaRXJt4sXE6TRpfGpVbGw	BC Wallet

Allowed Schemas:

Author DID	Name	Version
RGjWbW1eycP7FrMf4QJvX8	Person	1.0
E2h4RUJxyh48PLJ1CtGJrq	BC VC Pilot Certificate	1.0.1
A2UZSmrL9N5FDZGPu68wy	bc-mines-act-permit	1.0
AcZpBDz3oxmKrpcuPcdKai	Digital Business Card	1.0.0
A2UZSmrL9N5FDZGPu68wy	bc-mines-act-permit	1.1.1
XqaRXJt4sXE6TRpfGpVbGw	app_attestation	1.0

Allowed Credential Definitions:

Author DID	Issuer DID	Schema Name	Schema Version	Tag	RevRegDef	RevRegEntry
RGjWbW1eycP7FrMf4QJvX8	RGjWbW1eycP7FrMf4QJvX8	Person	1.0	Person	TRUE	TRUE
E2h4RUJxyh48PLJ1CtGJrq	E2h4RUJxyh48PLJ1CtGJrq	BC VC Pilot Certificate	1.0.1	default	TRUE	TRUE
A2UZSmrL9N5FDZGPu68wy	A2UZSmrL9N5FDZGPu68wy	bc-mines-act-permit	1.0	mds-prod-revok	TRUE	TRUE
AcZpBDz3oxmKrpcuPcdKai	AcZpBDz3oxmKrpcuPcdKai	Digital Business Card	1.0.0	default	TRUE	TRUE
A2UZSmrL9N5FDZGPu68wy	A2UZSmrL9N5FDZGPu68wy	bc-mines-act-permit	1.1.1	mds-prod-revok	TRUE	TRUE
XqaRXJt4sXE6TRpfGpVbGw	XqaRXJt4sXE6TRpfGpVbGw	app_attestation	1.0	bcwallet	TRUE	TRUE

@CharlesMacpherson can you confirm this looks good and can be used as allow list for the current state?
I am also wondering if the Governance is establishing any rules (and reviewing them) for submitted schema names and tags: do we want/need to follow a naming convention, or each issuer is free to use whatever they see fit as long as the schema structure and naming are allowed?

Unless there is a better place to store these files, I suggest we use https://github.com/bcgov/dts-endorser-service since it already contains the deployment configurations for the endorser service - @WadeBarnes thoughts on this?

[WadeBarnes]

Since the https://github.com/bcgov/dts-endorser-service is the repo containing the configurations for out endorser instances it makes sense to store the rules there as well. It also allows us to manage updates to the rules in a controlled and automated fashion.

[CharlesMacpherson]

I would like new schemas and creddefs to require explicit email approval by management prior to endorsement. revocation related transactions can be set to auto-endorsed. Since we are the primary/central party communicating credential issuer identifiers to verifying parties, we need to maintain strict control and awareness of how and when our issuers are updating their credential identifiers.

The lists above align with my understanding our production issuers, in terms of plain text names/descriptions.

[esune]

I would like new schemas and creddefs to require explicit email approval by management prior to endorsement. revocation related transactions can be set to auto-endorsed. Since we are the primary/central party communicating credential issuer identifiers to verifying parties, we need to maintain strict control and awareness of how and when our issuers are updating their credential identifiers.

The lists above align with my understanding our production issuers, in terms of plain text names/descriptions.

Yes, this is just to catch-up with the current state and formalize it.
Future requests will have to go through approval (email request as per above) before the changes are merged/applied.

I will PR the current changes to the deployment configurations repo so we can start tracking it there.

[esune]

PR - pending testing of payloads with descriptions: bcgov/dts-endorser-service#38