Hyperledger Fabric Policy

Hyperledger Fabric Policy in the configtx.yaml file uses shorthanded notation, which normally looks like a file path like this:

Channel/Application/Writers

That notation basically indicates the policy defined in

Channel/Groups/Application/Policies/Writers

Noticed that the Groups and Policies in the path are omitted.

Notice the 1st mod_policy in the chart is "/Channel/Orderer/Admins" which actually refers channel_group/groups/Orderer/policies/Admins element. The reason why it refers to that is because it starts with an absolute path. Actually the 2nd mod_policy also points to the same role but it uses relative path.

Though 2nd and 3rd mod_policy both only use the relative path "Admins", they actually point to the different role in the policies. The 2nd as indicated above, it points to the 1st Admins role, but the 3rd policy points to the 2nd Admins role. So if the absolute path used for the 2nd mod_policy, it would have been "/Channel/Orderer/Admins", same way if the absolute path used for the 3rd mod_policy, it would have been "/Channel/Admins", notice it has no word Orderer in it.

Do not mix up policy and policies. The element policy is always under defined role such as Admins, Readers and Writers etc, these roles are always directly under element policies. Where element policies is always under groups.<Something>, in our above example, you can see policies elements are under groups.Consortiums, groups.Orderer, config.channel_group. The element policies really just defines the role, element policy defines a specific rule. Policy has types, policies just have a list of roles. Policy type 1 is SignaturePolicy and type 3 is ImplictMetaPolicy. type 2 is the msp.

mod_policy indicates what role can make modifications to the Policies itself, policies control very much the fabric configuration, so in nearly all the cases, this means who can make changes channel configurations, who can read the channel configurations. The channel in this case can be either system channel or application channel. Now regarding who can create proposal, commit tx, prove tx all are controlled by ACL.

Policy defaults:

The configtxgen tool creates default policies as follows:

/Channel/Readers : ImplicitMetaPolicy for ANY of /Channel/*/Readers
/Channel/Writers : ImplicitMetaPolicy for ANY of /Channel/*/Writers
/Channel/Admins  : ImplicitMetaPolicy for MAJORITY of /Channel/*/Admins

/Channel/Application/Readers : ImplicitMetaPolicy for ANY of /Channel/Application/*/Readers
/Channel/Application/Writers : ImplicitMetaPolicy for ANY of /Channel/Application/*/Writers
/Channel/Application/Admins  : ImplicitMetaPolicy for MAJORITY of /Channel/Application/*/Admins

/Channel/Orderer/Readers : ImplicitMetaPolicy for ANY of /Channel/Orderer/*/Readers
/Channel/Orderer/Writers : ImplicitMetaPolicy for ANY of /Channel/Orderer/*/Writers
/Channel/Orderer/Admins  : ImplicitMetaPolicy for MAJORITY of /Channel/Orderer/*/Admins

# Here * represents either Orderer, or Application, and this is repeated for each org
/Channel/*/Org/Readers : SignaturePolicy for 1 of MSP Principal Org Member
/Channel/*/Org/Writers : SignaturePolicy for 1 of MSP Principal Org Member
/Channel/*/Org/Admins  : SignaturePolicy for 1 of MSP Principal Org Admin

see the following chart for examples of ImplictMetaPolicy and SignaturePolicy

The principal_classification can either be ROLE or IDENTITY. However, more commonly the ROLE type is used, as it allows the principal to match many different certs issued by the MSP's CA. The role matches MSPRole defined as MEMBER, ADMIN, CLIENT, PEER.

Member matches any certificate issued by the MSP. Admin matches certificate enumerated as admin in the MSP definition. Client (Peer) matches certificates that carry the client(peer) Organizational Unit.

In the case of IDENTITY the principal field is set to the bytes of a certificate literal.That is, the principal field should just contain the base64 encoded (The very long string) certificate for that identity.

The sub_policy in the ImplicitMetaPolicy indicate any named policy in its value, in the example above, which is Admins, so any the policy named Admins at that level or under will be used. If the rule is ALL, then all the policies named Admins at that level or under will be evaluated.