How does Hyperledger composer handle endorsements

Question

I have been reading about endorsement policies e.g.here and do understand that they determine which transactions are saved in the block chain in Hyperledger Fabric v1.

I am wondering how I can be able to transfer an asset across multiple stages e.g. as shown here. Is it one transaction that goes through multiple stages in order to be approved i.e. using endorsement policies? Or there are many transactions, each with its own policies.

Either way, I would like to have a transaction approved by a different user e.g. admin MANUALLY before it's saved or rejected on the block chain. Could endorsement policies help me in this?

My thinking is that each transaction is usually submitted by 1 participant. Then, how do the endorsement policies that require a transaction to be signed by two participants work? Is it that there is another signing process separately where endorsers sign transactions explicitly?

Any guidance in the right direction will be highly appreciated.

Answer 1

To some degree, you may be slightly confusing Fabric endorsement policies with application (business logic) based multi-stage approval (across multi-orgs) as shown in the car lease demo, and following the lifecycle of a vehicle (post-approvals etc).

A Fabric endorsement policy can be based on Fabric keys or identities relating to the deployed network for example - and define a set of endorsers based on identity in a multi-org setup.

As mentioned in the issue https://github.com/hyperledger/composer/issues/1251 you refer to - Composer provides a (multi-org) example of what is (ultimately) a Fabric endorsement policy (eg the -O example on July 4) and the ability to 'pass those on' as a passthrough mechanism for what is ultimately Fabric policy parameters if that's what you want to do. As shown in the example, they can be related to the Fabric identities. See more here -> http://hyperledger-fabric.readthedocs.io/en/release/arch-deep-dive.html?highlight=endorsement#endorsement-policies

As for your approval process you described - you can capture the approval process (its a business approvals process) using Composer, so the 'appropriate participant' (application user from whatever org) gets notified of a request transaction (eg notified using Composer Events) that he/she needs to generate an approval (a separate transaction - so the ledger shows it was approved), and then the asset can be transferred (triggered upon approval - based on approver from a role in an Org for example**).

**If you wish, you can create a Participant that is a role to be the 'Approver' (a participant can have multiple identities, that have authority to 'approve' - and you can always trace 'which' identity performed the approval). The asset may then (potentially) move on to another, intermediate transfer stage, and then there is another [business] process step that takes it to the next stage (whatever that is). The organisations are sharing the same business network on the same ledger/channel, so to me you would do this through Composer.