From 39e363821d0ebd374b36fe4b4a9acafefcc2d7e5 Mon Sep 17 00:00:00 2001 From: Gabriela DiSarli <107440934+gabydisarli@users.noreply.github.com> Date: Tue, 18 Jul 2023 16:31:23 -0500 Subject: [PATCH 1/5] Create 0022-submit-domain-request-user-flow adding a ADR that closes #800 --- .../0022-submit-domain-request-user-flow | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 docs/architecture/decisions/0022-submit-domain-request-user-flow diff --git a/docs/architecture/decisions/0022-submit-domain-request-user-flow b/docs/architecture/decisions/0022-submit-domain-request-user-flow new file mode 100644 index 000000000..598f4322e --- /dev/null +++ b/docs/architecture/decisions/0022-submit-domain-request-user-flow @@ -0,0 +1,21 @@ +# 22. Submit Domain Request User Flow + +Date: 2023-07-18 + +## Status + +Accepted + +## Context + +Historically, Verisign has managed the identity verification for users who request to apply for a .gov domain. With CISA's new system, any user who creates an account and verifies themselves through Login.gov will be able to request a .gov domain. As another layer of mitigation against abuse of the system, we needed a way to stop new users from submitting multiple domain requests before they are verified by CISA analysts. + +## Considered Options + +Option 1: Users that don't meet the requirement of having a prior approved application will not be able to submit any new applications. We add a page alert informing the user that they cannot submit their application because they have an application in one of these "3" statuses (Submitted, In Review or Action Needed). They would still be able to create and edit new applications, just not submit them. The benefits of this option are that it would allow users to have multiple applications essentially in "draft mode" that are queued up and ready for submission after they are permitted to submit (after approval of 1 application). + +Option 2: Users that don't meet the requirement of having a prior approved application will not be able to submit any new applications. Additionally, we would remove the ability to edit any application with the started/withdrawn/rejected status, or start a new application. The benefit of this option is that a user would not be able to begin an action (submitting an application) that they are not allowed to complete. + +## Decision + +We have decided to go with option 1. New users of the registrar will need to have at least one approved application OR prior registered .gov domain in order to submit another application. We would like to allow users be able to work on applications, even if they are unable to submit them. [A user flow diagram that demonstrates this logic can be viewed at this link](https://miro.com/app/board/uXjVM3jz3Bs=/?share_link_id=875307531981). From cd6b704e784c83883c8d1a4538be4a603ed04026 Mon Sep 17 00:00:00 2001 From: Gabriela DiSarli <107440934+gabydisarli@users.noreply.github.com> Date: Wed, 19 Jul 2023 13:29:51 -0500 Subject: [PATCH 2/5] Rename 0022-submit-domain-request-user-flow to 0022-submit-domain-request-user-flow.md fixed the file extension --- ...-request-user-flow => 0022-submit-domain-request-user-flow.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/architecture/decisions/{0022-submit-domain-request-user-flow => 0022-submit-domain-request-user-flow.md} (100%) diff --git a/docs/architecture/decisions/0022-submit-domain-request-user-flow b/docs/architecture/decisions/0022-submit-domain-request-user-flow.md similarity index 100% rename from docs/architecture/decisions/0022-submit-domain-request-user-flow rename to docs/architecture/decisions/0022-submit-domain-request-user-flow.md From 2b4cfd016dd2d64fb5f01a1a85277629009ba49b Mon Sep 17 00:00:00 2001 From: Gabriela DiSarli <107440934+gabydisarli@users.noreply.github.com> Date: Wed, 19 Jul 2023 13:33:21 -0500 Subject: [PATCH 3/5] Update 0022-submit-domain-request-user-flow.md Updated context paragraph + fixed wording and linking structure on linked user flow diagram --- .../decisions/0022-submit-domain-request-user-flow.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/architecture/decisions/0022-submit-domain-request-user-flow.md b/docs/architecture/decisions/0022-submit-domain-request-user-flow.md index 598f4322e..7d2f2196e 100644 --- a/docs/architecture/decisions/0022-submit-domain-request-user-flow.md +++ b/docs/architecture/decisions/0022-submit-domain-request-user-flow.md @@ -8,7 +8,7 @@ Accepted ## Context -Historically, Verisign has managed the identity verification for users who request to apply for a .gov domain. With CISA's new system, any user who creates an account and verifies themselves through Login.gov will be able to request a .gov domain. As another layer of mitigation against abuse of the system, we needed a way to stop new users from submitting multiple domain requests before they are verified by CISA analysts. +Historically, the .gov vendor managed initial identity verification and organizational affiliation for users that request a .gov domain. With the new registrar, _any user with a valid Login.gov account_ will be able to make a request. As a primary layer of abuse prevention (i.e., DDoSing the registry program with illegitimate requests), we need a way to stop new users from submitting multiple domain requests before they are known to the .gov registry. In this case, "known" means they have at least one approved domain application or existing domain. ## Considered Options @@ -18,4 +18,6 @@ Option 2: Users that don't meet the requirement of having a prior approved appli ## Decision -We have decided to go with option 1. New users of the registrar will need to have at least one approved application OR prior registered .gov domain in order to submit another application. We would like to allow users be able to work on applications, even if they are unable to submit them. [A user flow diagram that demonstrates this logic can be viewed at this link](https://miro.com/app/board/uXjVM3jz3Bs=/?share_link_id=875307531981). +We have decided to go with option 1. New users of the registrar will need to have at least one approved application OR prior registered .gov domain in order to submit another application. We would like to allow users be able to work on applications, even if they are unable to submit them. + +A [user flow diagram](https://miro.com/app/board/uXjVM3jz3Bs=/?share_link_id=875307531981)https://miro.com/app/board/uXjVM3jz3Bs=/?share_link_id=875307531981 demonstrates our decision. From 2114ff22f1d3b4230e87cc05e4f9f7d9c2bee85c Mon Sep 17 00:00:00 2001 From: Gabriela DiSarli <107440934+gabydisarli@users.noreply.github.com> Date: Wed, 19 Jul 2023 13:33:59 -0500 Subject: [PATCH 4/5] Update 0022-submit-domain-request-user-flow.md fixed double link error --- .../decisions/0022-submit-domain-request-user-flow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/decisions/0022-submit-domain-request-user-flow.md b/docs/architecture/decisions/0022-submit-domain-request-user-flow.md index 7d2f2196e..bde0fd404 100644 --- a/docs/architecture/decisions/0022-submit-domain-request-user-flow.md +++ b/docs/architecture/decisions/0022-submit-domain-request-user-flow.md @@ -20,4 +20,4 @@ Option 2: Users that don't meet the requirement of having a prior approved appli We have decided to go with option 1. New users of the registrar will need to have at least one approved application OR prior registered .gov domain in order to submit another application. We would like to allow users be able to work on applications, even if they are unable to submit them. -A [user flow diagram](https://miro.com/app/board/uXjVM3jz3Bs=/?share_link_id=875307531981)https://miro.com/app/board/uXjVM3jz3Bs=/?share_link_id=875307531981 demonstrates our decision. +A [user flow diagram](https://miro.com/app/board/uXjVM3jz3Bs=/?share_link_id=875307531981) demonstrates our decision. From 75190da2093ec3cce499961699ad117185c414da Mon Sep 17 00:00:00 2001 From: Gabriela DiSarli <107440934+gabydisarli@users.noreply.github.com> Date: Thu, 20 Jul 2023 09:38:01 -0500 Subject: [PATCH 5/5] Update 0022-submit-domain-request-user-flow.md Made some additional edits for clarity that were suggested in review --- .../decisions/0022-submit-domain-request-user-flow.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/architecture/decisions/0022-submit-domain-request-user-flow.md b/docs/architecture/decisions/0022-submit-domain-request-user-flow.md index bde0fd404..cc0ca83b8 100644 --- a/docs/architecture/decisions/0022-submit-domain-request-user-flow.md +++ b/docs/architecture/decisions/0022-submit-domain-request-user-flow.md @@ -12,12 +12,12 @@ Historically, the .gov vendor managed initial identity verification and organiza ## Considered Options -Option 1: Users that don't meet the requirement of having a prior approved application will not be able to submit any new applications. We add a page alert informing the user that they cannot submit their application because they have an application in one of these "3" statuses (Submitted, In Review or Action Needed). They would still be able to create and edit new applications, just not submit them. The benefits of this option are that it would allow users to have multiple applications essentially in "draft mode" that are queued up and ready for submission after they are permitted to submit (after approval of 1 application). +**Option 1:** Users will not be able to submit any new applications if they have 0 prior approved applications OR prior registered .gov domains. We would add a page alert informing the user that they cannot submit their application because they have an application in one of these "3" statuses (Submitted, In Review or Action Needed). They would still be able to create and edit new applications, just not submit them. The benefits of this option are that it would allow users to have multiple applications essentially in "draft mode" that are queued up and ready for submission after they are permitted to submit. -Option 2: Users that don't meet the requirement of having a prior approved application will not be able to submit any new applications. Additionally, we would remove the ability to edit any application with the started/withdrawn/rejected status, or start a new application. The benefit of this option is that a user would not be able to begin an action (submitting an application) that they are not allowed to complete. +**Option 2:** Users will not be able to submit any new applications if they have 0 prior approved applications OR prior registered .gov domains. Additionally, we would remove the ability to edit any application with the started/withdrawn/rejected status, or start a new application. The benefit of this option is that a user would not be able to begin an action (submitting an application) that they are not allowed to complete. ## Decision -We have decided to go with option 1. New users of the registrar will need to have at least one approved application OR prior registered .gov domain in order to submit another application. We would like to allow users be able to work on applications, even if they are unable to submit them. +We have decided to go with option 1. New users of the registrar will need to have at least one approved application OR prior registered .gov domain in order to submit another application. We chose this option because we would like to allow users be able to work on applications, even if they are unable to submit them. A [user flow diagram](https://miro.com/app/board/uXjVM3jz3Bs=/?share_link_id=875307531981) demonstrates our decision.