From 7fbc87d8003a5bd7c728cdb89aad0a5c529bac18 Mon Sep 17 00:00:00 2001 From: pama-ibm Date: Tue, 22 May 2018 11:43:19 -0400 Subject: [PATCH] [FAB-10285] MSP topic Minor edits to msp topic Change-Id: I6fe26a3213274b42d6b621aa684ff07062dac4bf Signed-off-by: pama-ibm --- docs/source/msp.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/source/msp.rst b/docs/source/msp.rst index 474f5cc3e94..98977f5cd5e 100644 --- a/docs/source/msp.rst +++ b/docs/source/msp.rst @@ -249,7 +249,7 @@ configuration in commonly met scenarios. **1) Mapping between organizations/corporations and MSPs** We recommend that there is a one-to-one mapping between organizations and MSPs. -If a different mapping type of mapping is chosen, the following needs to be to +If a different type of mapping is chosen, the following needs to be to considered: - **One organization employing various MSPs.** This corresponds to the @@ -322,7 +322,7 @@ peer/orderer MSP would be the administrators of that MSP. Another point to be considered with this approach is that peers authorize event registration requests based on membership of request originator within their local MSP. Clearly, since the originator of the -request is a client, the request originator is always doomed to belong +request is a client, the request originator is always deemed to belong to a different MSP than the requested peer and the peer would reject the request.