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.