Personally, i dont really see the appeal for permissioned chains as it goes against the idea of decentralization. However, i can understand that there are usecases where it would indeed be handy to have a permissioned chain.
Also, there are some chains where without permission you are not even able to see the chain at all. In this case, the chain parameters would need to be kept secret or some packet encryption layer be implemented. I will assume that just keeping the exact chain parameters secret is enough protection to prevent unauthorized access. Without the exact -ac chain parameters, no node would be able to connect to and sync to a secret chain.
It is for this reason, that there is no way to know how many chains are using komodo tech: https://developers.komodoplatform.com/basic-docs/installations/asset-chain-parameters.html
To make it more industrial strength, there would need to be packet level encryption to a group pubkey and only those with the proper privkeys would be able to decrypt it. This doesnt affect any consensus issues, it is just adding a layer of encryption to prevent access. A network that is secured from external nodes will also serve the same purpose.
OK, so now we have the consensus level changes that are needed. Namely the ability to send and receive funds. It might be that we want to separate this, so some addresses can only send, but not receive, but it seems a bit contrived. If separation of specific transactions are needed, the same technique as below can be used for whatever functionality is needed to be segregated.
The method would have the hardcoded way where the approved pubkeys are part of the chain parameters, but that seems pretty limiting. I would suggest to specify the set of authorized pubkeys in an -earlytxid, where the earlytxid is as I describe in https://medium.com/@jameslee777/solving-the-chicken-and-egg-problem-of-self-bootstrapping-a-blockchain-1914437d2be3
Once there is a list of approved pubkeys, then it would be a simple matter for the CC validation to make sure that only the approved pubkeys are involved in signing a transaction. Further granularity can be achieved by requiring all signers be in the approved list, or just one, or some other predefined number. Basically whatever restriction rules are desired can be encoded in the earlytxid.
It would even be possible to designate some special pubkeys as having the power to authorize new pubkeys and revoke existing ones. Make sure to tag these new authorizations so it is efficient to find all authorized pubkeys. https://medium.com/@jameslee777/ensuring-exclusivity-with-baton-utxo-in-cc-8932f64434d6
As you can see, implementing a permissioned chain using CC is not a very difficult task at all
