The specification does not propose any specific implementation of the privacy data layer. Vendors can implement this layer in different ways or select from the Marketplace.

This specification encourage implementers to support the following flows:

• Access Control List: Any request to access private data MUST verify the requester with an ACL. The verification MAY use the Organization's Identifier, request signature, Request IP Address, TLS Client Certificate , etc

• Hash Backup: Organizations MUST create and store a verifiable HASH of the current data into the underlying blockchain to allow for verification and validation by recipients of the private data. Hash construction will be part of the specification.

• Advertising: Organizations MAY advertise updates of the private data to the network, to other Routers on the ACL for that specific data. For example push an update on an Asset KYA to the group of Routers that are authorized to present that asset to their users.

The private data interface allows organizations to keep sensitive data out of reach of public requests but accessible to a specific group of organizations that are allowed under an ACL.

Signatures and credentials are verified at every request to access private data. If the owner of the signature is allowed to access, the data is returned. Any other outcome will generate an error.

Private Data Sharing Patterns

The specification doesn’t dictate how private data should be shared and disseminated by the Router, the network layer of FinP2P enables the implementation of either a Push or a Pull pattern, or a combination of both to private data sharing.

Pull

In a Pull data sharing model, the data is stored only on the Primary Router private store and not replicated over to other Routers private stores, when a Primary Router wants to share data with other Routers, he can notify those Routers by utilizing the network layer pub-sub capability, when other Routers will require to read the private data, they will issue a request-response network call to the Primary Router in order to retrieve the private data.

Push

In a Push data sharing model, the data is stored on the Primary Router private store and also replicated on all of the Routers private store whom the Primary Router shared the data with, in this model the Primary Router will utilize the network layer pub-sub capability in order to push the data into the Routers he desire to share the data with, any change or update to the shared data will be pushed by the Primary Router to all Routers which the piece of data is shared with.

Use Cases 

Asset Information Sharing

Financial institutions who bring assets into the network (their Primary Assets) need to have distribution control over which other institution’s users may see and transact with the asset. This distribution control may be required at the asset level.

Therefore, organizations can decide to share information about the assets they manage. The use case is to allow other Organizations to offer the asset to their users.

Organizations can then discover which assets are being shared, and by whom, and decide if they want to offer them to their users. Once the asset data is shared, an organization can subscribe to get updates on changes, or it can pull data by sending P2P requests.

User Information Sharing

In this use case a user form Organization A wants to Buy assets managed by Organization B. In order to verify the buyer and its legal situation, Organization B sends a request to get user information from Organization A. If the request fails, the user will not be able to transact with the assets.