Uploaded image for project: 'Fabric'
  1. Fabric
  2. FAB-1219

Support access control policies for chaincode (creation, termination, invocation - in terms of chaincode library)



    • Chaincode Invocation Access Control
    • Unset
    • Unset
    • Unset
    • Unset
    • Unset


      From adc -

      In 0.5/0.6, we had two ways to perform access control.

      1) The first was based on signatures. The metadata field contained
      a signature of the invocation payload concatenated to the transaction binding.
      The chaincode was in charge to check the signature against a set of locally
      stored certificates in order to evaluate access control.
      An example of this mechanism was the chaincode asset_management.go.

      2) The second solution was based on TCert's attributes. The chaincode
      was in charge to get the caller certificate and evaluate the attributes carried
      by the certificate. An example of this mechanism was the chaincode

      Now, the implementation of the above mechanisms was mainly based on two
      fields extracted from the transaction. Namely, the caller certificate and the metadata.

      In order to have the same mechanisms in v1, the chaincode needs a way
      to extract again the caller certificate and, this time, the transient field.

      In addition the Shim also provides a way to access the transaction binding (will the Unique TXID be sufficient for this purpose ?). We would need the same in v1 to implement solution1) and also for the confidentiality library.

      Within this epic, one would also need to enhance proposal structure with (transient) data field, i.e., a field that appears in the proposal, but not in the subsequent endorsed actions/transaction.

      Also for ales ellaki binhn mastersingh24


        Issue Links



              angelo.decaro Angelo De Caro
              muralisr Srinivasan Muralidharan
              0 Vote for this issue
              4 Start watching this issue