ENT-1331: Updating High Level design following discussion with Mike, Jose and David H

docs/source/design/businessNetwork/decisions/nodeVsCorDapp.md

@@ -59,4 +59,35 @@ communicated with.
 
 ## Recommendation and justification
 
-This is a key decision for Technical Design and will be discussed during next Business Network working group meeting.
+As per meeting held on Fri, 26-Jan-2018 by @vkolomeyko, @josecoll, @mikehearn and @davejh69
+we agreed that it would make sense for all the new CorDapps written post BN implementation
+to know which BN they operate on.
+Such that they will be able to make BN specific membership checks and work with "Additional Information" that may be provided by BNO.
+"Additional Information" may incorporate BN specific information like Roles (E.g. "Agent" and "Lender")
+or transaction limits, reference data, etc.
+We will provide flexibility such that BN designers will be able to hold/distribute information that they feel relevant for their BN.
+
+All the pre-BN CorDapps will work as before with BN membership enforced on a Node level. Configuration details TBC.
+So it is not the case of Option #1 vs. Option #2 decision, but a form of hybrid approach.
+
+
+
+### In terms of addressing BN Privacy requirement:
+
+Unfortunately, we will have to supply information of **every** node into Global Network Map(GNM) regardless whether it is part of BN or not.
+This is necessary to protect against non-member on member attack when content of a GNM is used on TLS handshake phase to prevent
+connection with IP addresses that are not part of Compatibility Zone(CZ).
+Also GNP will be a key point where certification revocation will be enforced.
+
+In order to prevent non-members of BN from discovering content of a BN within CZ, when membership check fails, the node is meant to reply as if CorDapp is not installed at all on this node.
+This will make use cases:
+-	I am not talking to you because you are not part of my BN;
+
+and
+
+-	I do not know which flow you are talking about;
+
+un-distinguishable from attacker point of view.
+
+BN composition will be represented by a set which will be distributed to all the members.
+Fetching of "Additional Information" will be a separate operation which new style CorDapps may, but not have to, use.

docs/source/design/businessNetwork/design.md

@@ -10,7 +10,7 @@ DOCUMENT MANAGEMENT
 | Title                |                                          |
 | -------------------- | ---------------------------------------- |
 | Date                 | 14-Dec-2017                              |
-| Authors              | David Lee and Viktor Kolomeyko           |
+| Authors              | David Lee, Viktor Kolomeyko, Jose Coll, Mike Hearn  |
 | Distribution         | Design Review Board, Product Management, Services - Technical (Consulting), Platform Delivery |
 | Corda target version | Enterprise |
 | JIRA reference       | [Sample Business Network implementation](https://r3-cev.atlassian.net/browse/R3NET-546) |
@@ -21,7 +21,7 @@ DOCUMENT MANAGEMENT
 
 | Author            |                                          |
 | ----------------- | ---------------------------------------- |
-| Reviewer(s)       | David Lee, Viktor Kolomeyko, Mike Hearn and James Carlyle |
+| Reviewer(s)       | David Lee, Viktor Kolomeyko, Mike Hearn, Jose Coll, Dave Hudson  and James Carlyle |
 | Final approver(s) | Richard G. Brown |
 
 
@@ -35,8 +35,7 @@ even know of each other existence.
 
 The key concept of Business Network is **Business Network Operator ('BNO') node** as a mean for BNOs to serve reference data to members 
 of their business network(s), as required by CorDapp(s) specific to that business network. This includes allowing BNO 
-nodes to supplement the `NodeInfo`-vending capabilities of the global network map, serving network map entries which are
+nodes to vend additional information associated with Business Network participant like roles, transaction limits, etc.
-not listed in the global network map. This allows BNOs to ensure strict privacy of their members and control which IP addresses are used in relation to which CorDapps.
 
 ## Background
 
@@ -48,7 +47,7 @@ In order to address those privacy concerns Business Networks were introduced as
 based on a need-to-know principle. 
 
 This design document reflects on what was previously discussed on this Confluence page
-[Business Network Membership](https://r3-cev.atlassian.net/wiki/spaces/CCD/pages/131972363/Business+Network+Membership)
+[Business Network Membership](https://r3-cev.atlassian.net/wiki/spaces/CCD/pages/131972363/Business+Network+Membership).
 
 ## Scope
 
@@ -106,7 +105,7 @@ The following requirements are addressed as follows:
 | Description                              | Recommendation  | Approval               |
 | ---------------------------------------- | --------------- | ----------------------- |
 | [TLS vs. Membership](decisions/tlsVsMembership.md) | Proceed with Membership | Mike Hearn |
-| [BN membership: Node vs. CorDapp](decisions/nodeVsCorDapp.md) | TBD | TBD |
+| [BN membership: Node vs. CorDapp](decisions/nodeVsCorDapp.md) | Hybrid approach for options #1 and #2 | Mike Hearn |
 
 * Per [New Network Map](https://r3-cev.atlassian.net/wiki/spaces/AWG/pages/127710793/New+Network+Map):
    * R3 will serve a file containing NetworkParameters to all members of the Corda Connect Compatibility Zone, made publicly available via CDN. 
@@ -114,24 +113,14 @@ The following requirements are addressed as follows:
    * The network map file will continue to serve references to downloadable entries 
    (Signed `NodeInfo` file with the node's certificate chain, IP addresses etc. for a given node) for any nodes which wish to be publicly discoverable by all CZ members.
 
-* Nodes **may individually choose** to publish to the global network map by posting their entry to an R3-provided endpoint, 
-but are **not required to do so**.
-
 * BNO nodes expose a range of services to their membership over normal Corda flows (via a custom BNO CorDapp deployed on their BNO node).
 The BNO is free to define whatever services apply in the context of their business network; these will typically include:     
    * Managing requests to join/leave the business network;
-   * Accepting uploads of network map entries (signed `NodeInfos`) from business network members.
-   *A node may choose to publish different `NodeInfos` to different business networks in order to indicate that they want 
-   to be addressed on a given IP in relation to a given set of traffic.*
    * Vending a membership list of distinguished names (DNs) that a given party within the business network is allowed 
    to see / transact with, for use in 'address book' / 'drop-down' type UI functionality. 
    *The structure of the membership list may be tailored according to the needs of the BNO and, according to the needs 
-   of the CorDapp, it may either be expressed as a subclass of the `NetworkMapCache` itself or as a standalone data structure in its own right.*
+   of the CorDapp, it may either be expressed as a standalone data structure in its own right.*
-   * Vending `NodeInfos` in response to lookup requests by a business network member for a particular DN 
+   * Vending `AdditionalInformation` for a Business Network Participant which may include roles associated with it, trading limits, etc.
-   (more sophisticated query options may also be offered), which are integrated into the node's local `NetworkMapCache`.
-   *A node may acquire multiple `NodeInfos` in relation to the same DN via its association with multiple business networks
-   and needs a mechanism to (a) retain distinctions between them, (b) when initiating a flow by a specific CorDapp, 
-   preferentially address messages to the IP(s) referenced in the `NodeInfo` served by the associated business network.* 
 
 * For each **Business Network-specific CorDapp**, the CorDapp developer will include features to restrict such that the
 CorDapp cannot be used to transact with non-members. Namely:
@@ -140,16 +129,14 @@ CorDapp cannot be used to transact with non-members. Namely:
 
 ## Target Solution
 
-*Illustration of services exposed by both network map and BNO node. Interface names shown are indicative and may be changed as needed.*
-
 ![Business Network diagram](businessNetwork.png)
 
 ## Complementary solutions
 
 * No requirement to change the Network Map design currently proposed in
-[New Network Map](https://r3-cev.atlassian.net/wiki/spaces/AWG/pages/127710793/New+Network+Map);
+[New Network Map](https://r3-cev.atlassian.net/wiki/spaces/AWG/pages/127710793/New+Network+Map).
-* Data model for `NetworkMapCache` needs to be able to manage potential conflicts between `NodeInfos` downloaded from different
+
-network maps, and supply the correct one when needed. 
+* [Cash business network requirements](https://r3-cev.atlassian.net/wiki/spaces/CCD/pages/198443424/Cash+business+network+requirements)
 
 ## Final recommendation