give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Introduction:   * Many use cases need an endorsement policy that requires endorsements from multiple organizations   * The chaincode that is installed needs to be identical across all peers (in fact - Fabric enforces this at endorsement time).    However, two organizations that have the same chaincode installed, may have slightly different rules that dictate who is authorized to request an endorsement:   *  Organization A might trust only users from a specific OU in organization B to receive an endorsement from it, while this might not be of an importance to organization B.   * The reason the chaincode needs to be identical across organizations is that the write sets would be computed in the same fashion across organizations, since the chaincode endorsement is actually a proof of correct execution of business logic rules that dictate the next world state based on the previous world state.   * An organization might want to check if the given client (user) is found in some black list (i.e an OCSP request to the client's issuer) and doesn't want to enforce other organizations in the channel that have endorsers to upgrade their chaincodes.   * An organization might want to communicate to some system that performs access control decisions but it may not want to share this with other organizations.    As known, [authentication filters|https://github.com/hyperledger/fabric/blob/master/sampleconfig/core.yaml#L345-L360] (introduced in v1.1) are peer-local handlers which intercept chaincode proposals for endorsement, and enforce custom logic which may decide to reject the client's proposal and return an error.    Currently, authentication filters are enforced globally across all chaincodes, and the implementer needs to extract the chaincode name from the proposal if he/she wishes to have different rules per chaincode.    This makes deployment clumsy and inefficient, because if the peer has *n* chaincodes installed and each of the chaincodes has its own authentication filter - the peer actually runs the proposal through *n* authentication filters instead of through 1 of them.       I suggest that we make authentication filters to be able to be enforced per-chaincode and not globally.    However, in order to be backward compatible with existing deployments and also to be able to have authentication filter logic that spans across chaincodes - we need to also support the original mode where authentication filters are enforced globally.    Therefore I suggest that the authentication filter configuration would be extended with another attribute that would govern whether the given auth filter is enforced globally or only to specific chaincodes.    The existing authentication filter configuration looks as the following:  {code:java}  authFilters:    -   name: FilterOne   library: /opt/lib/filter.so     -   name: FilterTwo{code}  Where the library attribute symbols that it is a plugin and not a pre-compiled auth filter.    We propose another attribute: *chaincodes* which governs on which chaincodes the auth filter is enforced.    Absence of the attribute would denote it is enforced globally, and therefore the existing behavior will be preserved.    In the following example - *FilterOne* is only enforced on exampleCC, and *FilterTwo* is enforced on all chaincodes.   Therefore, if a proposal is received - it will first go through *FilterOne* (if it is targeted to exampleCC, otherwise it won't go through it), and in any case will go through *FilterTwo*.  {code:java}  authFilters:    -   name: FilterOne   library: /opt/lib/filter.so   chaincodes: exampleCC     -   name: FilterTwo    {code}  *Decorators*: I believe similar arguments could be applied for [decorators|https://github.com/hyperledger/fabric/blob/master/sampleconfig/core.yaml#L361-L366], which are handlers which pass additional information to the shim.    I believe that users might benefit from per chaincode decorators    Opinions?    [~<USER> [~<USER> [~<USER> [~<USER> [~<USER>"
Answer: 1012597.0