Coco is designed for permissioned networks (as opposed to public networks). The network constitution in Coco contains a list, arrived at by a vote of consortium members, of all of the actors permitted to interact with the network. Coco implements network-level authentication to restrict access to participants. The constitution state is stored within the state replicated by the Coco Framework, so it is stored on all of the nodes in the network.
Beyond network-level authentication, there is also ledger and DApp level authentication. The supply chain demo demonstrates this capability. For the demo, we modified Ethereum to integrate it with the Coco prototype. We removed the capability to read raw transactions or to access raw smart contract state directly. Instead, the DApp must implement public smart contract methods enabling reads to state that the developer wants to expose. Those read methods contain code (in this case implemented in Solidity, executed by the EVM) that is responsible for authentication and authorization of callers. This enables the DApp developer to decide for themselves now to authenticate the caller, and what roles and privileges apply to the DApp's data. We also did some work to restrict access to events to only authorized callers - you can read more in the whitepaper on this.
We believe there's an opportunity for common patterns here (a la the ERC20 token standard), but these patterns can vary by ledger and by DApp. All of that is above the Coco layer. This is why the ledger (in this example Ethereum) matters. The ledger exposes capabilities that either natively, or through smart contracts, secure the data in the ledger. Coco's job is to ensure that ledger data is only ever in the clear inside the TEE, where the ledger and smart contract code can implement a confidentiality model appropriate for the use case.