Application-Specific Governance

[TheBankster]

Hello,
Our project is building a CCF-based Attestation Verification Service (AVS) acting as a Root of Trust for an enterprise. As such, it needs to maintain two application-specific tables: signing keys and attestation policies. It is clear that the signing key table must be kept private, and policies may also be best kept confidential, so only authorized parties get to see them. In addition, we would like to separate "signing key administrator" and "policy administrator" roles, while it is probably okay for Members to decide who is in which role. It is also important for our Root-of-Trust scenario to protect against rogue administrators, so no single administrator can be given free reign to alter either a signing key or a policy unilaterally.
We are basically faced with a problem similar to what CCF governance accomplishes, but at the application level. There has to be a service-specific constitution, and administrators of the two types are similar to members, only they do not modify the consortium properties. They would still be notified of and vote on role-specific proposals, for instance.
So a question to those with in-depth understanding of CCF: is it feasible to replicate CCF governance at per-application level, or is it better to create a custom governance module and give Members different roles? Would it be realistic to merge such a change into CCF mainline to avoid a long-term fork?
Note that this is likely not a one-off problem. While CCF was originally intended for ledgers and blockchains, in this case we're building something similar to a CA, which is likely a reusable pattern as well.
Any ideas are welcome.

[eddyashton]

Hi @TheBankster.

A deliberate restriction on the current member-facing governance code is that it may only modify public tables. We believe this simplifies the audit story significantly - everything that the governing members do is recorded in the clear in the ledger, so can be examined, re-executed, and blamed by anyone with ledger access. This includes all proposals and ballots being recorded in the clear as well, so setting confidential entries here is not possible (ie - even if we allowed constitutions to write private entries, you would need to submit a "generate_new_private_key()" proposal, not a "set_private_key(K)" proposal, because K would be visible in the proposal itself).

We believe the right answer here is to implement some kind of governance/constitution at the application level. It's fully expected that applications have different kind of users with different roles, bootstrapped by actions from the governing members, and for many applications some of these will be very powerful user-space "administrator" type roles. We also have a sample constitution with multiple distinct member roles. We think it's very useful to be able to separate these roles if necessary (ie - the operator-members running the nodes do not overlap with the governor-members responsible for the service behaviour do not overlap with the adminstrator-users responsible for the service contents do not overlap with the end-users benefiting from the service contents), and crucially this still allows you to go the other way and combine roles (by re-using identities).

Building some kind of voting system at the application level also gives you flexibility, as you do not need to match the CCF governance model. The main benefit in your case is that you can submit proposals that contain and modify private state, and reveal those only to authorised parties. You could also simplify proposals as a set of natively-coded, bound-to-code-ID actions, or simplify voting by submitting boolean votes rather than executable ballots, or use an alternative signing format for proposals, or provide namespacing where admins can only modify their "own" copies of these tables rather than a single central copy, or allow the effects of a given proposal to be visible to authorised users before it is accepted, or many other tweaks,

In terms of upstreaming, we're very interested in seeing apps and constitutions which implement generic patterns which may be useful for other use cases. Our current approach has been to implement those as sample apps, but we might also build some kind of sample zoo.

Hope that helps.

[TheBankster]

Understood. If I were to define several different user tables for different application-specific roles, which of the "AuthnPolicies" defined in common_auth_policies.h would I use to ensure that the request comes from a member of that user group? Is there sample code around that? Thank you.

[eddyashton]

@TheBankster None of the built-in policies will do that, but we sample code showing how to write your own policy here: https://github.com/microsoft/CCF/blob/main/samples/apps/logging/logging.cpp#L52-L134

Summary:

• Create a new class to implement the authentication policy, inheriting from ccf::AuthnPolicy.
• Override the authenticate() method. This takes a Tx, to read from any tables you've populated defining user roles, and an RpcContext describing the current request, and returns a ccf::AuthnIdentity pointer describing the extracted identity (or nullptr if the user isn't permitted to call this). Work out who the caller is from the RpcContext, lookup whether they have the correct role with the Tx, and return a summary of their identity if they're authorised.
• You may want to return a custom AuthnIdentity type, containing for instance the caller's extracted roles. This should subclass ccf::AuthnIdentity, like the CustomIdentity in this sample code.
• Create an instance of that AuthnPolicy in your application code, and pass that instance to make_endpoint() for the endpoints you want restricted in this way (see lines 778 and 779 for the equivalent in the sample).

Let me know if you have any questions.