How to Implement Construction for Hyperledger-Fabric Chains

I am working on a Rosetta implementation for a Hyperledger-Fabric blockchain (which is permissioned and private). There are a few parts of the Construction API that don’t seem to match well with the structure of Fabric - was hoping that someone may be able to provide some insight or documents. Questions listed below:

  1. For /construction/derive, the documentation states: “Blockchains that require an on-chain action to create an account should not implement this method.”

    • In Hyperledger-Fabric, Identities (and in our case, unique accounts) are associated with an X509 identity. These must be acquired from a certificate authority. While this is not strictly an “on-chain” action - it is a requirement to create an account (you cannot simply derive a pub/priv key-pair, it must come from the authorized CA). Does this mean that /construction/derive is not necessary for this type of chain? Is there some sort of alternative criteria that the account creation needs to satisfy for this case?
  2. The transaction lifecycle for Hyperledger-Fabric requires the user to sign a message at both the endorsement stage as well as the broadcasting stage. In other words - First the user signs and sends a transaction proposal, which is endorsed by a node and returned to the user. Second, the user signs the endorsed transaction again, and then broadcasts it to the network.

    • The Rosetta Construction API doesn’t seem to accommodate this type of scenario where the transaction must be signed twice? The /construction/combine endpoint would need to be used at both the endorsement as well as the broadcast stage. Also, the /construction/submit endpoint would need to have separate behavior for both endorsement and broadcast, as the submission of the signed-payload is handled differently (submitted to different nodes types).
      Are there any known implementations of Rosetta for Fabric which resolve this difference in transaction flow? Is it completely necessary that the implementation support exactly the same process flow as in the Rosetta documentation? We have considered using a middleware to manage identities so that the two-signature lifecycle can be reduced to a single signature for the end-user, allowing us to fit the Rosetta flow. Would appreciate any other ideas or input here.

Thanks for reading!