Access control for chaincode design

[binhn]

We need ability to control who can issue specific transactions on specific chaincode

[jeffgarratt]

Will document the work on https://github.com/hyperledger/fabric/wiki/Access-Control-Specification

[frankyclu]

Add some clarification:

This function does not limit to invocation transactions, For example, some has mentioned that they would like to filter the information in the query response so that a user can only see what he/she is entitled to see.

[jeffgarratt]

This is in progress. The current focus will be on user defined ACLs for their specific application.

[jeffgarratt]

@binhn here is s breakdown of the work for this issue, will track through item list below. I want to use this work as an archetype of how new functionality should be added to system through a test first approach.

• [ ] define behave tests for ACL demonstration leveraging asset control chaincode
• [ ] extend behave implementation to support new constructs (eg. multi chaincode access from scenario)
• [ ] document the use case and guidelines within the ACL spec wiki page

[jeffgarratt]

Classification of access control mechanisms: ordered by complexity

• access control based on TCerts (No attributes, not role based) see -> asset_mgt.go (doable now with behave and should pass)
• Role based access control using TCerts w/o using attributes -> @adecaro will provide simple example (doable soon, will coordinate with @adecaro )
• Attribute based access control using Tcerts with Attributes -> ( @adecaro @diegomasini to determine)
• attribute access control with User Defined membership services (use their own PKI infastructure) TBD