From 80b1bb1ddbcb866720f310cbecfd6675216c5f82 Mon Sep 17 00:00:00 2001
From: David Lee <david.lee@r3.com>
Date: Wed, 29 Nov 2017 18:03:16 +0000
Subject: [PATCH 1/9] Added basic design doc

---
 .../doorman-admin-ui/decisions/decision.md    | 39 +++++++++++
 docs/source/design/doorman-admin-ui/design.md | 70 +++++++++++++++++++
 2 files changed, 109 insertions(+)
 create mode 100644 docs/source/design/doorman-admin-ui/decisions/decision.md
 create mode 100644 docs/source/design/doorman-admin-ui/design.md

diff --git a/docs/source/design/doorman-admin-ui/decisions/decision.md b/docs/source/design/doorman-admin-ui/decisions/decision.md
new file mode 100644
index 0000000000..9a2ca69069
--- /dev/null
+++ b/docs/source/design/doorman-admin-ui/decisions/decision.md
@@ -0,0 +1,39 @@
+![Corda](https://www.corda.net/wp-content/uploads/2016/11/fg005_corda_b.png)
+
+--------------------------------------------
+Design Decision: <Description heading>
+============================================
+
+## Background / Context
+
+Short outline of decision point.
+
+## Options Analysis
+
+### A. <Option summary>
+
+#### Advantages
+
+1.    ​
+2.    ​
+
+#### Disadvantages
+
+1.    ​
+2.    ​
+
+### B. <Option summary>
+
+#### Advantages
+
+1. ​
+2. ​
+
+#### Disadvantages
+
+1. ​
+2. ​
+
+## Recommendation and justification
+
+Proceed with Option <A or B or ... > 
diff --git a/docs/source/design/doorman-admin-ui/design.md b/docs/source/design/doorman-admin-ui/design.md
new file mode 100644
index 0000000000..230b46b59f
--- /dev/null
+++ b/docs/source/design/doorman-admin-ui/design.md
@@ -0,0 +1,70 @@
+![Corda](https://www.corda.net/wp-content/uploads/2016/11/fg005_corda_b.png)
+
+# Design: Doorman Administration UI
+
+DOCUMENT MANAGEMENT
+---
+
+## Document Control
+
+| Title                | Doorman Administration UI |
+| -------------------- | ------------------------- |
+| Date                 | 29/11/2017                |
+| Author               | David Lee                 |
+| Distribution         | TBD                       |
+| Corda target version | N/A - Doorman             |
+| JIRA reference       | ENT-1130                  |
+
+## Approvals
+
+#### Document Sign-off
+
+| Author            |      |
+| ----------------- | ---- |
+| Reviewer(s)       | TBD  |
+| Final approver(s) | TBD  |
+
+#### Design Decisions
+
+| Description                              | Recommendation  | Approval*               |
+| ---------------------------------------- | --------------- | ----------------------- |
+| [Near-term solution](decisions/near-term.md) | Selected option | (Design Approval Board) |
+
+\* only required for formal Design Approval Board meetings.
+
+HIGH LEVEL DESIGN
+---
+
+## Overview
+
+General overall of design proposal (goal, objectives, simple outline)
+
+## Background
+
+Existing Doorman code provides for optional integration with a JIRA project, in which issues mirror CSRs and movement of an issue to an Approved status is used to trigger approval of the underlying CSR (and subsequent release of a signed certificate to the client node)
+
+Whilst expedient as a near-term solution, the long-term practicality of JIRA (specifically, the JIRA instance provided by R3's corporate Atlassian account) for managing workflow has been questioned on grounds of: 
+
+- **Scalability**: Unproven where a system in which every request raises a JIRA issue would prove resistant to  volume-based attacks
+- **Extensibility**: Current work to develop an ID verification process is surfacing various requirements to track meta-data around a CSR - specifically, evidence captured on the requester's identity, checks performed etc. with reference to a policy, and evidence of controls (e.g. 4-eyes checks and approvals) applied. Whilst it is potentially feasible to implement these features through JIRA customisation, the required flexibility has not been demonstrated.
+- **Security**: Threat model around JIRA as a third-party, cloud-hosted application cannot be easily qualified. At a minimum, it may be assumed that Atlassian administrators would have both visibility and permissions to change statuses of JIRA stories, thus compromising the integrity of the certificate issuance process.
+
+## Scope
+
+* To provide a mechanism for doorman operators to manage the approvals of CSRs in way which is fit for near-term purposes. This may involve third-party open-source or commercial components (e.g. JIRA) where appropriate.
+* **Non-goal**: Develop a full bespoke end-to-end workflow solution equivalent to that used in financial institutions' KYC processes
+
+## Timeline
+
+* Solution required before Feb 1
+
+## Requirements
+
+* To be elaborated.
+
+
+## Design Decisions
+
+| Heading                                  | Recommendation |
+| ---------------------------------------- | -------------- |
+| [Near-term solution](decisions/near-term.md) | Option A       |

From 1de4f4c120c2db1c9f1addd8509629a100ba219e Mon Sep 17 00:00:00 2001
From: David Lee <david.lee@r3.com>
Date: Wed, 29 Nov 2017 18:20:45 +0000
Subject: [PATCH 2/9] Added decision doc

---
 .../doorman-admin-ui/decisions/decision.md    | 52 ++++++++++++++-----
 1 file changed, 40 insertions(+), 12 deletions(-)

diff --git a/docs/source/design/doorman-admin-ui/decisions/decision.md b/docs/source/design/doorman-admin-ui/decisions/decision.md
index 9a2ca69069..c5a8c06622 100644
--- a/docs/source/design/doorman-admin-ui/decisions/decision.md
+++ b/docs/source/design/doorman-admin-ui/decisions/decision.md
@@ -1,38 +1,66 @@
 ![Corda](https://www.corda.net/wp-content/uploads/2016/11/fg005_corda_b.png)
 
 --------------------------------------------
-Design Decision: <Description heading>
+Design Decision: Near-term solution for Doorman Administration UI
 ============================================
 
 ## Background / Context
 
-Short outline of decision point.
+A decision is required specifically on the doorman UI to be used for the near-term Pilot network, to be launched on Feb 1, 2018. See [main design doc](../design.md) for more context.
 
 ## Options Analysis
 
-### A. <Option summary>
+### A. Existing R3 Atlassian-Hosted JIRA
 
 #### Advantages
 
-1.    ​
-2.    ​
+1.    Incumbent option - no change required
 
 #### Disadvantages
 
-1.    ​
-2.    ​
+1.    Risk to R3 corporate operations exposed by JIRA integration of Doorman
+2.    Potential security challenges (See [main design doc](../design.md))
 
-### B. <Option summary>
+### B. Separate Atlassian-Hosted JIRA
 
 #### Advantages
 
-1. ​
-2. ​
+1. Minimal infrastructure deployment requirement - just buy a new account
+2. HA and DR provided by Atlassian (in principle - no easily enforceable SLAs etc.) 
 
 #### Disadvantages
 
-1. ​
-2. ​
+1. Scalability and performance under large loads unclear 
+2. Flexibility to support long term requirements unclear - may be just a 'stop-gap'
+
+### C. Private JIRA installation
+
+#### Advantages
+
+1. Low/no development effort to change
+2. A single installation with no HA etc. may be relatively cheap - [$10 for 10 users ](https://www.atlassian.com/software/jira/pricing?tab=self-hosted)
+3. Self-ownership of HA/DR issues may provide greater certainty
+4. Easier to secure (can put behind a firewall with extra authentication etc.)
+
+#### Disadvantages
+
+1. Scalability and performance under large loads unclear - may end up spending c. £12k for a data centre license.
+2. Flexibility to support long term requirements unclear - may be just a 'stop-gap'
+
+### D. Bespoke application
+
+Code a bespoke client UI (e.g. in AngularJS) that administers the doorman via direct calls to the API. 
+
+#### Advantages
+
+1. Starting point for eventual strategic solution that meets precise onboarding process requirements
+2. No flexibility issues
+3. No performance issues (driven off doorman database)
+4. Easier to secure (can put behind a firewall with extra authentication etc.)
+
+#### Disadvantages
+
+1. Extra development effort​
 
 ## Recommendation and justification
 

From 2f67a4e9eef08d335ed0261ead74387b58e4d3ff Mon Sep 17 00:00:00 2001
From: David Lee <david.lee@r3.com>
Date: Wed, 29 Nov 2017 18:22:12 +0000
Subject: [PATCH 3/9] Renamed decision.md

---
 .../doorman-admin-ui/decisions/{decision.md => near-term.md}      | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename docs/source/design/doorman-admin-ui/decisions/{decision.md => near-term.md} (100%)

diff --git a/docs/source/design/doorman-admin-ui/decisions/decision.md b/docs/source/design/doorman-admin-ui/decisions/near-term.md
similarity index 100%
rename from docs/source/design/doorman-admin-ui/decisions/decision.md
rename to docs/source/design/doorman-admin-ui/decisions/near-term.md

From 8a4af529286e917b6844f7583ccf2de342416dd0 Mon Sep 17 00:00:00 2001
From: David Lee <david.lee@r3cev.com>
Date: Wed, 29 Nov 2017 18:23:26 +0000
Subject: [PATCH 4/9] Grammar fix

---
 docs/source/design/doorman-admin-ui/design.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/source/design/doorman-admin-ui/design.md b/docs/source/design/doorman-admin-ui/design.md
index 230b46b59f..e8f0b21e25 100644
--- a/docs/source/design/doorman-admin-ui/design.md
+++ b/docs/source/design/doorman-admin-ui/design.md
@@ -45,7 +45,7 @@ Existing Doorman code provides for optional integration with a JIRA project, in
 
 Whilst expedient as a near-term solution, the long-term practicality of JIRA (specifically, the JIRA instance provided by R3's corporate Atlassian account) for managing workflow has been questioned on grounds of: 
 
-- **Scalability**: Unproven where a system in which every request raises a JIRA issue would prove resistant to  volume-based attacks
+- **Scalability**: Unproven that a system in which every request raises a JIRA issue would prove resistant to volume-based attacks
 - **Extensibility**: Current work to develop an ID verification process is surfacing various requirements to track meta-data around a CSR - specifically, evidence captured on the requester's identity, checks performed etc. with reference to a policy, and evidence of controls (e.g. 4-eyes checks and approvals) applied. Whilst it is potentially feasible to implement these features through JIRA customisation, the required flexibility has not been demonstrated.
 - **Security**: Threat model around JIRA as a third-party, cloud-hosted application cannot be easily qualified. At a minimum, it may be assumed that Atlassian administrators would have both visibility and permissions to change statuses of JIRA stories, thus compromising the integrity of the certificate issuance process.
 

From 0d6a88099622c9073b84552c84a5b68fc88570fc Mon Sep 17 00:00:00 2001
From: David Lee <david.lee@r3cev.com>
Date: Wed, 29 Nov 2017 18:29:06 +0000
Subject: [PATCH 5/9] Removed recommendation

---
 docs/source/design/doorman-admin-ui/design.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/source/design/doorman-admin-ui/design.md b/docs/source/design/doorman-admin-ui/design.md
index e8f0b21e25..da347e779d 100644
--- a/docs/source/design/doorman-admin-ui/design.md
+++ b/docs/source/design/doorman-admin-ui/design.md
@@ -67,4 +67,4 @@ Whilst expedient as a near-term solution, the long-term practicality of JIRA (sp
 
 | Heading                                  | Recommendation |
 | ---------------------------------------- | -------------- |
-| [Near-term solution](decisions/near-term.md) | Option A       |
+| [Near-term solution](decisions/near-term.md) | TBD     |

From 57634bd9dff6621c50fa77e8c152030fbd41f8c8 Mon Sep 17 00:00:00 2001
From: David Lee <david.lee@r3.com>
Date: Fri, 1 Dec 2017 14:06:58 +0000
Subject: [PATCH 6/9] Paired back to just recommendation for private instance

---
 .../doorman-admin-ui/decisions/near-term.md   | 67 -------------------
 docs/source/design/doorman-admin-ui/design.md | 51 +++++++++-----
 2 files changed, 36 insertions(+), 82 deletions(-)
 delete mode 100644 docs/source/design/doorman-admin-ui/decisions/near-term.md

diff --git a/docs/source/design/doorman-admin-ui/decisions/near-term.md b/docs/source/design/doorman-admin-ui/decisions/near-term.md
deleted file mode 100644
index c5a8c06622..0000000000
--- a/docs/source/design/doorman-admin-ui/decisions/near-term.md
+++ /dev/null
@@ -1,67 +0,0 @@
-![Corda](https://www.corda.net/wp-content/uploads/2016/11/fg005_corda_b.png)
-
---------------------------------------------
-Design Decision: Near-term solution for Doorman Administration UI
-============================================
-
-## Background / Context
-
-A decision is required specifically on the doorman UI to be used for the near-term Pilot network, to be launched on Feb 1, 2018. See [main design doc](../design.md) for more context.
-
-## Options Analysis
-
-### A. Existing R3 Atlassian-Hosted JIRA
-
-#### Advantages
-
-1.    Incumbent option - no change required
-
-#### Disadvantages
-
-1.    Risk to R3 corporate operations exposed by JIRA integration of Doorman
-2.    Potential security challenges (See [main design doc](../design.md))
-
-### B. Separate Atlassian-Hosted JIRA
-
-#### Advantages
-
-1. Minimal infrastructure deployment requirement - just buy a new account
-2. HA and DR provided by Atlassian (in principle - no easily enforceable SLAs etc.) 
-
-#### Disadvantages
-
-1. Scalability and performance under large loads unclear 
-2. Flexibility to support long term requirements unclear - may be just a 'stop-gap'
-
-### C. Private JIRA installation
-
-#### Advantages
-
-1. Low/no development effort to change
-2. A single installation with no HA etc. may be relatively cheap - [$10 for 10 users ](https://www.atlassian.com/software/jira/pricing?tab=self-hosted)
-3. Self-ownership of HA/DR issues may provide greater certainty
-4. Easier to secure (can put behind a firewall with extra authentication etc.)
-
-#### Disadvantages
-
-1. Scalability and performance under large loads unclear - may end up spending c. £12k for a data centre license.
-2. Flexibility to support long term requirements unclear - may be just a 'stop-gap'
-
-### D. Bespoke application
-
-Code a bespoke client UI (e.g. in AngularJS) that administers the doorman via direct calls to the API. 
-
-#### Advantages
-
-1. Starting point for eventual strategic solution that meets precise onboarding process requirements
-2. No flexibility issues
-3. No performance issues (driven off doorman database)
-4. Easier to secure (can put behind a firewall with extra authentication etc.)
-
-#### Disadvantages
-
-1. Extra development effort​
-
-## Recommendation and justification
-
-Proceed with Option <A or B or ... > 
diff --git a/docs/source/design/doorman-admin-ui/design.md b/docs/source/design/doorman-admin-ui/design.md
index da347e779d..40d98185d7 100644
--- a/docs/source/design/doorman-admin-ui/design.md
+++ b/docs/source/design/doorman-admin-ui/design.md
@@ -37,34 +37,55 @@ HIGH LEVEL DESIGN
 
 ## Overview
 
-General overall of design proposal (goal, objectives, simple outline)
+This document describes the application and deployment design for an administrator UI.
 
 ## Background
 
-Existing Doorman code provides for optional integration with a JIRA project, in which issues mirror CSRs and movement of an issue to an Approved status is used to trigger approval of the underlying CSR (and subsequent release of a signed certificate to the client node)
+Issuance of a certificate by the Doorman in a production context requires human approval. A business process to support this, including performing relevant checks to validate the identity of the requester of a certificate, is being designed in parallel. 
 
-Whilst expedient as a near-term solution, the long-term practicality of JIRA (specifically, the JIRA instance provided by R3's corporate Atlassian account) for managing workflow has been questioned on grounds of: 
+Existing Doorman code provides for optional integration with a JIRA project, in which issues mirror CSRs and movement of an issue to an Approved status is used to trigger approval of the underlying CSR (and subsequent release of a signed certificate to the client node). Testnet and other non-production deployments to date have used a cloud-based JIRA deployment provided by R3's general-purpose company Atlassian account.
 
-- **Scalability**: Unproven that a system in which every request raises a JIRA issue would prove resistant to volume-based attacks
-- **Extensibility**: Current work to develop an ID verification process is surfacing various requirements to track meta-data around a CSR - specifically, evidence captured on the requester's identity, checks performed etc. with reference to a policy, and evidence of controls (e.g. 4-eyes checks and approvals) applied. Whilst it is potentially feasible to implement these features through JIRA customisation, the required flexibility has not been demonstrated.
-- **Security**: Threat model around JIRA as a third-party, cloud-hosted application cannot be easily qualified. At a minimum, it may be assumed that Atlassian administrators would have both visibility and permissions to change statuses of JIRA stories, thus compromising the integrity of the certificate issuance process.
+The suitability of using the R3 general Atlassian account, specifically, is questioned on security grounds:
+
+- Every HTTPS request raises a JIRA issue. Significant volumes of HTTP requests may be trivially posted by a malicious attacker with knowledge of the doorman URL, generating a very large volume of JIRA issues.  This would disrupt the CSR approvals process. More significantly, if the R3 cloud JIRA is used, it could significantly disrupt normal business operations for R3, which uses JIRA for team planning and organisation across both Platform and other teams.
+
+  A working assumption has been that the URL for the doorman will be kept secret and only shared with trusted parties (R3 partners and their customers who run Corda nodes). However, no controls (legal or otherwise) are proposed to prevent this URL from being leaked into the public domain. 
+
+  For the same reason, automated load testing of the doorman's CSR submission endpoint is not currently possible.
+
+  Note: Evidence from the Atlassian website suggests that a single cloud JIRA instance is stable up to c. 200,000 issues, but they recommend splitting instances above this point, suggesting performance implications at that scale.
+
+- The threat model around the Atlassian Cloud JIRA cannot be easily qualified. At a minimum, it may be assumed that Atlassian administrators would have both visibility and permissions to change statuses of JIRA stories, thus compromising the integrity of the certificate issuance process. Note that the final signing stage via HSM remains a control point protected by multi-factor 
+
+The suitability of JIRA is further questioned in relation to future requirements to support ID verification workflows. These workflows will be conceptually similar to (but significantly less complex than) Know-Your-Client (KYC) processes used by large financial institutions, in which a series of checks need to be performed on each onboarding request. Such KYC/AML applications generally model each of these checks as a discrete work item which needs to be tracked to completion and recorded; the set of checks required by each case is determined by conditional policy logic. The set of checks then sum to an approval Yes/No outcome for the overall case. It is not clear, at present, whether such logic and management of checks/issues could be effectively managed in JIRA, using plugins or otherwise. 
+
+Beyond this, requirements are anticipated to expose the progress of a given CSR to the requester who raised it, and to allow the requester to submit additional documentary evidence where needed to support ID verification checks. It is not clear how these requirements could also be met solely using JIRA.
 
 ## Scope
 
-* To provide a mechanism for doorman operators to manage the approvals of CSRs in way which is fit for near-term purposes. This may involve third-party open-source or commercial components (e.g. JIRA) where appropriate.
-* **Non-goal**: Develop a full bespoke end-to-end workflow solution equivalent to that used in financial institutions' KYC processes
+### Goals
+
+Provide an admin solution for the near-term pilot and production phases which:
+
+- Does not expose R3 business operations to risk of significant disruption from a volume-based attack.
+- Can be meaningfully load tested
+
+### Non-Goals
+
+Design a strategic end-to-end solution incorporating specialist ID verification workflows, progress reporting to external clients etc.
 
 ## Timeline
 
-* Solution required before Feb 1
+* Solution required before the pilot launch (April 26)
 
-## Requirements
+## Target Solution
 
-* To be elaborated.
+A private installation of JIRA will be deployed to R3's Azure cloud. This will be a dedicated JIRA instance solely for use by permissioned R3 doorman operators and DevOps administrators. 
 
+Access to the JIRA instance will be over a VPN to the R3 (Ldn/NY) office network. Outside an R3 office, doorman operators will require their own VPN connection in order to access the doorman JIRA. (Note that under the proposed scheme where smart card-authentication is used to control the final signing stage, the user needs to be physically present in either the London or New York office anyway, so remote working is not assumed as a key requirement for this process.)
 
-## Design Decisions
+## Final recommendation
 
-| Heading                                  | Recommendation |
-| ---------------------------------------- | -------------- |
-| [Near-term solution](decisions/near-term.md) | TBD     |
+- Proceed to Technical Design stage
+
+## TECHNICAL DESIGN
\ No newline at end of file

From d568cee57e04ffb6a148206c10b86cf31003e744 Mon Sep 17 00:00:00 2001
From: David Lee <david.lee@r3.com>
Date: Fri, 1 Dec 2017 14:09:57 +0000
Subject: [PATCH 7/9] Added pricing

---
 docs/source/design/doorman-admin-ui/design.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/docs/source/design/doorman-admin-ui/design.md b/docs/source/design/doorman-admin-ui/design.md
index 40d98185d7..b61b57c034 100644
--- a/docs/source/design/doorman-admin-ui/design.md
+++ b/docs/source/design/doorman-admin-ui/design.md
@@ -84,6 +84,10 @@ A private installation of JIRA will be deployed to R3's Azure cloud. This will b
 
 Access to the JIRA instance will be over a VPN to the R3 (Ldn/NY) office network. Outside an R3 office, doorman operators will require their own VPN connection in order to access the doorman JIRA. (Note that under the proposed scheme where smart card-authentication is used to control the final signing stage, the user needs to be physically present in either the London or New York office anyway, so remote working is not assumed as a key requirement for this process.)
 
+Note that a private installation of JIRA for 10 users (perpetual license) costs USD 10;  25 users costs USD 2,500.
+
+
+
 ## Final recommendation
 
 - Proceed to Technical Design stage

From fc4373ded783bcdd0e08536001d652b173a79cb1 Mon Sep 17 00:00:00 2001
From: David Lee <david.lee@r3.com>
Date: Wed, 17 Jan 2018 17:50:10 +0000
Subject: [PATCH 8/9] Put near-term.md back (not sure why it got lost)

---
 .../doorman-admin-ui/decisions/near-term.md   | 70 +++++++++++++++++++
 1 file changed, 70 insertions(+)
 create mode 100644 docs/source/design/doorman-admin-ui/decisions/near-term.md

diff --git a/docs/source/design/doorman-admin-ui/decisions/near-term.md b/docs/source/design/doorman-admin-ui/decisions/near-term.md
new file mode 100644
index 0000000000..9021c7a349
--- /dev/null
+++ b/docs/source/design/doorman-admin-ui/decisions/near-term.md
@@ -0,0 +1,70 @@
+![Corda](https://www.corda.net/wp-content/uploads/2016/11/fg005_corda_b.png)
+
+--------------------------------------------
+Design Decision: Near-term solution for Doorman Administration UI
+============================================
+
+## Background / Context
+
+A decision is required specifically on the doorman UI to be used for the near-term Pilot network, to be launched on Feb 1, 2018. See [main design doc](../design.md) for more context.
+
+## Options Analysis
+
+### A. Existing R3 Atlassian-Hosted JIRA
+
+#### Advantages
+
+1.    Incumbent option - no change required
+
+#### Disadvantages
+
+1.    Risk to R3 corporate operations exposed by JIRA integration of Doorman
+2.    Potential security challenges (See [main design doc](../design.md))
+
+### B. Separate Atlassian-Hosted JIRA
+
+#### Advantages
+
+1. Minimal infrastructure deployment requirement - just buy a new account
+2. HA and DR provided by Atlassian (in principle - no easily enforceable SLAs etc.) 
+
+#### Disadvantages
+
+1. Scalability and performance under large loads unclear 
+2. Flexibility to support long term requirements unclear - may be just a 'stop-gap'
+
+### C. Private JIRA installation
+
+#### Advantages
+
+1. Low/no development effort to change
+2. A single installation with no HA etc. may be relatively cheap - [$10 for 10 users ](https://www.atlassian.com/software/jira/pricing?tab=self-hosted)
+3. Self-ownership of HA/DR issues may provide greater certainty
+4. Easier to secure (can put behind a firewall with extra authentication etc.)
+
+#### Disadvantages
+
+1. Scalability and performance under large loads unclear - may end up spending c. £12k for a data centre license.
+2. Flexibility to support long term requirements unclear - may be just a 'stop-gap'
+
+### D. Bespoke application
+
+Code a bespoke client UI (e.g. in AngularJS) that administers the doorman via direct calls to the API. 
+
+#### Advantages
+
+1. Starting point for eventual strategic solution that meets precise onboarding process requirements
+2. No flexibility issues
+3. No performance issues (driven off doorman database)
+4. Easier to secure (can put behind a firewall with extra authentication etc.)
+
+#### Disadvantages
+
+1. Extra development effort
+2. Higher potential for bugs and security vulnerabilities
+3. Replication of workflow logic that already exists
+4. Harder for business-side employees to change workflow or logic vs. JIRA
+
+## Recommendation and justification
+
+Proceed with Option C - Private JIRA installation
\ No newline at end of file

From c4bfc49d0c7c60f8961d853ea6e7f7a26fa2b434 Mon Sep 17 00:00:00 2001
From: David Lee <david.lee@r3.com>
Date: Wed, 17 Jan 2018 17:52:45 +0000
Subject: [PATCH 9/9] Updated main doc

---
 docs/source/design/doorman-admin-ui/design.md | 22 ++++++++-----------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/docs/source/design/doorman-admin-ui/design.md b/docs/source/design/doorman-admin-ui/design.md
index b61b57c034..634f301451 100644
--- a/docs/source/design/doorman-admin-ui/design.md
+++ b/docs/source/design/doorman-admin-ui/design.md
@@ -19,18 +19,16 @@ DOCUMENT MANAGEMENT
 
 #### Document Sign-off
 
-| Author            |      |
-| ----------------- | ---- |
-| Reviewer(s)       | TBD  |
-| Final approver(s) | TBD  |
+| Author            |            |
+| ----------------- | ---------- |
+| Reviewer(s)       | Mike Hearn |
+| Final approver(s) | Mike Hearn |
 
 #### Design Decisions
 
-| Description                              | Recommendation  | Approval*               |
-| ---------------------------------------- | --------------- | ----------------------- |
-| [Near-term solution](decisions/near-term.md) | Selected option | (Design Approval Board) |
-
-\* only required for formal Design Approval Board meetings.
+| Description                              | Recommendation                       | Approval*               |
+| ---------------------------------------- | ------------------------------------ | ----------------------- |
+| [Near-term solution](decisions/near-term.md) | Option C - Private JIRA installation | (Design Approval Board) |
 
 HIGH LEVEL DESIGN
 ---
@@ -86,10 +84,8 @@ Access to the JIRA instance will be over a VPN to the R3 (Ldn/NY) office network
 
 Note that a private installation of JIRA for 10 users (perpetual license) costs USD 10;  25 users costs USD 2,500.
 
-
-
 ## Final recommendation
 
-- Proceed to Technical Design stage
+- Proceed to DevOps implementation
 
-## TECHNICAL DESIGN
\ No newline at end of file
+## 
\ No newline at end of file