Merge pull request usnistgov#1663 from pgrassi-nist/63-a-editorial-fixes

63 a editorial fixes

sp800-63-3/definitions.md

@@ -85,7 +85,7 @@ The secret value contained within an authenticator.
 The property that data originated from its purported source.
 
 #### Authoritative Source
-An entity that has access to, or verified copies of, a sufficient amount of accurate information from an issuing source such that a CSP can confirm the validity of the identity evidence supplied by an applicant during identity proofing. An issuing source may also be an authoritative source. Often, authoritative sources are determined by a policy decision of the agency or CSP before they can be used in the validation phase of identity proofing.
+An entity that has access to, or verified copies of, accurate information from an issuing source such that a CSP can confirm the validity of the identity evidence supplied by an applicant during identity proofing. An issuing source may also be an authoritative source. Often, authoritative sources are determined by a policy decision of the agency or CSP before they can be used in the validation phase of identity proofing.
 
 #### Back-Channel Communication
 Communication between two systems that relies on a direct connection (allowing for standard protocol-level proxies), without using redirects through an intermediary such as a browser. This can be accomplished using HTTP requests and responses.
@@ -209,7 +209,7 @@ The process by which a CSP and an RA collect and verify information about a pers
 The party that manages the subscriber’s primary authentication credentials and issues assertions derived from those credentials. This is commonly the CSP as discussed within this document suite.
 
 #### Issuing Source
-An authority that is responsible for the generation of data or documents that can be used as identity evidence. 
+An authority that is responsible for the generation of data, digital evidence (such as assertions) or physical documents that can be used as identity evidence. 
 
 #### Kerberos
 A widely used authentication protocol developed at MIT. In "classic" Kerberos, users share a secret password with a Key Distribution Center (KDC). The user, Alice, who wishes to communicate with another user, Bob, authenticates to the KDC and is furnished a "ticket" by the KDC to use to authenticate with Bob.

sp800-63a/sec10_references.md

@@ -32,3 +32,5 @@ For The Federal Bridge Certification Authority (FBCA), Version 2.27 (December 2,
 <a name="9397"></a>[EO 9397] *Executive Order 9397, NUMBERING SYSTEM FOR FEDERAL ACCOUNTS RELATING TO INDIVIDUAL PERSONS* (November 22, 1943), available at: <https://www.ssa.gov/foia/html/EO9397.htm>.
 
 <a name="SP800-53"></a>[SP 800-53] NIST Special Publication 800-53, Revision 4, *Recommended Security and Privacy Controls for Federal Information Systems and Organizations*, August 2013 and Errata as of January 2015.
+
+<a name="dmf"></a>[DMF] National Technical Information Service, *Social Security Death Master File*, available at: <https://www.ssdmf.com/Library/InfoManage/Guide.asp?FolderID=1>.

sp800-63a/sec1_2_introduction.md

@@ -14,7 +14,7 @@ This document provides requirements for enrollment and identity proofing of subs
 
 _This section is informative._
 
-One of the challenges associated with digital identity is the association of set of online activities with a single, specific entity. While there are situations where this is not required or is even undesirable (e.g., use cases where anonymity or pseudonymity are required), there are others where it is important to reliably establish an association with a real-life subject. Examples include obtaining health care and executing financial transactions. There are also situations where the association is required for regulatory reasons (e.g., Know Your Customer requirements in the financial community) or to establish accountability for high-risk actions (e.g., changing the release rate of water from a dam).
+One of the challenges associated with digital identity is the association of set of online activities with a single, specific entity. While there are situations where this is not required or is even undesirable (e.g., use cases where anonymity or pseudonymity are required), there are others where it is important to reliably establish an association with a real-life subject. Examples include obtaining health care and executing financial transactions. There are also situations where the association is required for regulatory reasons (e.g., 'Know Your Customer' requirements, established in response to the USA PATRIOT Act of 2001, in the financial community) or to establish accountability for high-risk actions (e.g., changing the release rate of water from a dam).
 
 There are also instances where it is desirable for a relying party (RP) to know something about a user executing a transaction, but not know the real life identity of the user.  For example, in order to maintain integrity of the service, it may be desirable to know the home ZIP Code of a user for purposes of census taking or petitioning an elected official but where it is not necessary or desirable to know the underlying identity of the person. IALs provide a method for expressing the level of assurance (LOA) associated with attributes established by the CSP during the proofing process.
 

sp800-63a/sec4_ial.md

@@ -59,7 +59,7 @@ The following requirements apply to any CSP performing identity proofing at IAL2
 
 10. The entire proofing transaction, including transactions that involve a third party, SHALL occur over an Authenticated Protected Channel.
 
-11. <a name="gr13"></a>The CSP SHOULD obtain additional confidence in remote identity proofing using fraud mitigation measures, for example inspecting geolocation, examining the device characteristics of the applicant, evaluating behavioral characteristics, or checking vital statistic repositories such as the [Death Master File](https://www.ssdmf.com/Library/InfoManage/Guide.asp?FolderID=1), so long as any additional mitigations do not substitute for the mandatory requirements contained herein and the CSP SHALL conduct a privacy risk assessment of these mitigation measures. Such assessments SHOULD include any privacy risk mitigations (e.g., limited retention, use limitations, notice, etc.) or other technological mitigations (e.g. cryptography).
+11. <a name="gr13"></a>The CSP SHOULD obtain additional confidence in unsupervised remote identity proofing using fraud mitigation measures, for example inspecting geolocation, examining the device characteristics of the applicant, evaluating behavioral characteristics, or checking vital statistic repositories such as the Death Master File [[DMF]](#dmf), so long as any additional mitigations do not substitute for the mandatory requirements contained herein and the CSP SHALL conduct a privacy risk assessment of these mitigation measures. Such assessments SHOULD include any privacy risk mitigations (e.g., limited retention, use limitations, notice, etc.) or other technological mitigations (e.g. cryptography).
 
 12. In the event a CSP ceases to conduct identity proofing and enrollment processes, the CSP SHALL be responsible for fully disposing of or destroying any sensitive data including PII, or its protection from unauthorized access for the duration of retention.
 
@@ -86,17 +86,17 @@ A CSP SHOULD implement identity proofing in accordance with [Section 4.4.1](#nor
 
 Collection of PII SHALL be limited to the minimum necessary to resolve to a unique identity in a given context.  See [Section 5.1](#resolve) for general resolution requirements.
 
-#### 4.4.1.2. Evidence Requirements
+#### 4.4.1.2. Evidence Collection Requirements
 
-See [Section 5.2, Identity Evidence Validation](#validate) for more information on acceptable identity evidence.
+See [Section 5.2.1. Identity Evidence Quality Requirements](#evidence-quality) for more information on acceptable identity evidence.
 
-- One (1) piece of SUPERIOR or STRONG evidence **if** the issuing source of the evidence, during its identity proofing event, confirmed the claimed identity by collecting two (2) or more forms of SUPERIOR or STRONG evidence; **OR**
+- One (1) piece of SUPERIOR or STRONG evidence **if** the issuing source of the evidence, during its identity proofing event, confirmed the claimed identity by collecting two (2) or more forms of SUPERIOR or STRONG evidence **AND** the CSP validates the evidence directly with the issuing source; **OR**
 - Two (2) pieces of STRONG evidence; **OR**
 - One (1) piece of STRONG evidence plus two (2) pieces of FAIR evidence.
 
 #### 4.4.1.3. Validation Requirements
 
-See [Section 5.2, Identity Evidence Validation](#validate) for more information on acceptable identity evidence.
+See [Section 5.2.2. Validating Identity Evidence](#evidence_validation") for more information on validating identity evidence.
 
 - Each piece of evidence SHALL be validated with a process that is able to achieve the same strength as the evidence presented. For example, if two forms of STRONG identity evidence are presented, each piece of evidence will be validated at a strength of STRONG.
 - Validation against a third party data service SHALL NOT be used for more than one piece of presented identity evidence.
@@ -118,20 +118,20 @@ In-person and remote identity proofing are allowed. The CSP SHOULD offer both in
 
 - Self-asserted address data that has not been confirmed in records SHALL NOT be used for confirmation.
 
-- **If CSP performed in-person proofing:**  
+- **If CSP performs in-person proofing (physical or supervised remote):**  
 
 	- The CSP SHOULD send a notification of proofing to the address of record.
 	- The CSP MAY provide an enrollment code directly to the subscriber if binding to an authenticator will occur at a later time.
 	- The enrollment code SHALL be valid for a maximum of 7 days
 
-- **If the CSP performed remote proofing:**  
+- **If the CSP performs remote proofing (unsupervised):**  
 
 	- The CSP SHALL send an enrollment code to an address of record of the applicant.
 	- The applicant SHALL present a valid enrollment code to complete the identity proofing process.
 	- The CSP SHOULD send the enrollment code to the physical mailing address that has been verified in records.  The CSP MAY send the enrollment code to a mobile telephone (SMS or voice), landline telephone, or email that has been verified in records.
 	- If the enrollment code is also intended to be an authentication factor, it SHALL be reset upon first use.
 	- Enrollment codes sent by means other than physical mail SHALL be valid for a maximum of 10 minutes; those sent to a postal address of record SHALL be valid for a maximum of 7 days but MAY be made valid up to 21 days via an exception process to accommodate addresses outside the direct reach of the U.S. Postal Service.  
-	- If delivery of the enrollment code was sent to an address of record that is not physical mail, the CSP SHALL send notification of proofing to a different address of record than the destination of the enrollment code. For example, if the CSP sends an enrollment code to a mobile phone of record, a notification of proofing will be sent to the physical address in records or obtained from validated and verified evidence, such as a driver's license.
+	- The CSP SHALL ensure the enrollment code and notification of proofing are sent by different means. For example, if the CSP sends an enrollment code to a mobile phone of record, a notification of proofing will be sent to the physical address in records or obtained from validated and verified evidence, such as a driver's license.
 
 #### 4.4.1.7. Biometric Collection
 
@@ -154,17 +154,17 @@ IAL3 adds additional rigor to the steps required at IAL2, to include providing f
 Collection of PII SHALL be limited to the minimum necessary to resolve to a unique identity record.  See [Section 5.1](#resolve) for general resolution requirements.
 
 
-#### 4.5.2. Evidence Requirements
+#### 4.5.2. Evidence Collection Requirements
 
-See [Section 5.2, Identity Evidence Validation](#validate) for more information on acceptable identity evidence.
+See [Section 5.2.1. Identity Evidence Quality Requirements](#evidence-quality) for more information on acceptable identity evidence.
 
 - Two (2) or more pieces of SUPERIOR evidence; **OR**
-- One (1) piece of SUPERIOR evidence and one (1) piece of STRONG evidence **if** the issuing source of the evidence, during its identity proofing event, confirmed the claimed identity by collecting two (2) or more forms of SUPERIOR or STRONG evidence; **OR**
+- One (1) piece of SUPERIOR evidence and one (1) piece of STRONG evidence **if** the issuing source of the evidence, during its identity proofing event, confirmed the claimed identity by collecting two (2) or more forms of SUPERIOR or STRONG evidence **AND** the CSP validates the evidence directly with the issuing source; **OR**
 - Two (2) pieces of STRONG evidence plus one (1) piece of FAIR evidence.
 
 #### 4.5.3. Validation Requirements  
 
-See [Section 5.2, Identity Evidence Validation](#validate) for more information on acceptable identity evidence.
+See [Section 5.2.2. Validating Identity Evidence](#evidence_validation) for more information on validating identity evidence
 
 - Each piece of evidence must be validated with a process that is able to achieve the same strength as the evidence presented. For example, if two forms of STRONG identity evidence are presented, each evidence will be validated at a strength of STRONG.
 - Validation against a third party data service SHALL only be used for one piece of presented identity evidence.
@@ -179,7 +179,7 @@ See [Section 5.3, Identity Verification](#verify) for more information on accept
 
 All identity proofing steps SHALL be performed in person. See [Section 5.3.3](#vip) for more details.
 
-Remote proofing SHALL NOT be allowed.
+Unsupervised remote proofing SHALL NOT be allowed.
 
 #### 4.5.6. Address Confirmation