Skip to content

Commit

Permalink
Merge pull request #1837 from pgrassi-nist/render-issues-then-i-am-done
Browse files Browse the repository at this point in the history
Fixed rendering issues
  • Loading branch information
Paul Grassi authored Jun 7, 2017
2 parents 621e229 + f9a9fa9 commit 9dda8b1
Show file tree
Hide file tree
Showing 8 changed files with 17 additions and 20 deletions.
4 changes: 2 additions & 2 deletions sp800-63-3/cover.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
<div class="text-right" markdown="1">

# <a name="800-63-3"></a> DRAFT NIST Special Publication 800-63
# <a name="800-63-3"></a> NIST Special Publication 800-63
# Revision 3

![](sp800-63-3/media/div-1.png)
Expand All @@ -21,7 +21,7 @@ https://doi.org/10.6028/NIST.SP.800-63-3

</div><div class="breaker text-right" markdown="1">

# DRAFT NIST Special Publication 800-63-3
# NIST Special Publication 800-63-3

# Digital Identity Guidelines

Expand Down
2 changes: 1 addition & 1 deletion sp800-63-3/sec5_DIRM.md
Original file line number Diff line number Diff line change
Expand Up @@ -89,7 +89,7 @@ The three potential impact values are:

The assurance level determination is only based on transactions that are part of a digital system. An online transaction may not be equivalent to a complete business process that requires offline processing, or online processing in a completely segmented system. In selecting the appropriate assurance levels, the agency should assess the risk associated with online transactions they are offering via the digital service, not the entire business process associated with the provided benefit or service. For example, in an online survey, personal information may be collected, but it is never made available online to the submitter after the information is saved. In this instance, it is important for the information to be carefully protected in backend systems, but there is no reason to identity proof or even authenticate the user providing the information for the purposes of their own access to the system or its associated benefits. The online transaction is solely a submission of the data. The entire business process may require a significant amount of data validation, without ever needing to know if the correct person submitted the information. In this scenario, there is no need for any identity proofing nor authentication.

Another example where the assessed risk could differ if the agency evaluated the entire business process rather than the online transaction requirements is a digital service that accepts résumés to apply for open job postings. In this use case, the digital service allows an individual to submit--or at least does not restrict an individual from submitting--a résumé on behalf of anyone else, and in subsequent visits to the site, access the résumé for various purposes. Since the résumé information is available to the user in later sessions, and is likely to contain personal information, the agency must select an AAL that requires MFA, even though the user self-asserted the personal information. In this case, the requirements of [EO 13681](#eo13681) apply and the application must provide at least AAL2. However, the identity proofing requirements remain unclear. The entire business process of examining a résumé and ultimately hiring and onboarding a person requires a significant amount of identity proofing. The agency needs a high level of confidence that the job applicant is in fact the subject of the résumé submitted online if a decision to hire is made. Yet this level of proofing is not required to submit the résumé online. Identity proofing is not required to complete the digital portion of the transaction successfully. Identity proofing the submitter would create more risk than required in the online system as excess personal information would be collected when no such information is needed for the portion of the hiring process served by the digital job application portal and may reduce usability. Therefore, the most appropriate IAL selection would be 1. There is no need to identity proof the user to successfully complete the online transaction. This decision for the online portal itself is independent of a seemingly obvious identity proofing requirement for the entire business process, lest a job be offered to a fraudulent applicant.
Another example where the assessed risk could differ if the agency evaluated the entire business process rather than the online transaction requirements is a digital service that accepts résumés to apply for open job postings. In this use case, the digital service allows an individual to submit--or at least does not restrict an individual from submitting--a résumé on behalf of anyone else, and in subsequent visits to the site, access the résumé for various purposes. Since the résumé information is available to the user in later sessions, and is likely to contain personal information, the agency must select an AAL that requires MFA, even though the user self-asserted the personal information. In this case, the requirements of [EO 13681](#EO13681) apply and the application must provide at least AAL2. However, the identity proofing requirements remain unclear. The entire business process of examining a résumé and ultimately hiring and onboarding a person requires a significant amount of identity proofing. The agency needs a high level of confidence that the job applicant is in fact the subject of the résumé submitted online if a decision to hire is made. Yet this level of proofing is not required to submit the résumé online. Identity proofing is not required to complete the digital portion of the transaction successfully. Identity proofing the submitter would create more risk than required in the online system as excess personal information would be collected when no such information is needed for the portion of the hiring process served by the digital job application portal and may reduce usability. Therefore, the most appropriate IAL selection would be 1. There is no need to identity proof the user to successfully complete the online transaction. This decision for the online portal itself is independent of a seemingly obvious identity proofing requirement for the entire business process, lest a job be offered to a fraudulent applicant.

#### 5.3.2 Impacts per Category

Expand Down
4 changes: 2 additions & 2 deletions sp800-63a/cover.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
<div class="text-right" markdown="1">

# <a name="800-63a"></a> DRAFT NIST Special Publication 800-63A
# <a name="800-63a"></a> NIST Special Publication 800-63A

![](sp800-63-3/media/div-1.png)

Expand Down Expand Up @@ -32,7 +32,7 @@ https://doi.org/10.6028/NIST.SP.800-63a

</div><div class="breaker text-right" markdown="1">

# DRAFT NIST Special Publication 800-63A
# NIST Special Publication 800-63A

# Digital Identity Guidelines

Expand Down
2 changes: 1 addition & 1 deletion sp800-63a/sec3_definitions.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,4 +4,4 @@

## 3 Definitions and Abbreviations

See [800-63, Appendix A](https://pages.nist.gov/800-63-3/sp800-63-3.html#def-and-acr) for a complete set of definitions and abbreviations.
See [800-63, Appendix A](sp800-63-3.html#def-and-acr) for a complete set of definitions and abbreviations.
4 changes: 2 additions & 2 deletions sp800-63a/sec4_ial.md
Original file line number Diff line number Diff line change
Expand Up @@ -267,10 +267,10 @@ _This section is informative._
Requirement | IAL1 | IAL2 | IAL3
------------|-------|-------|-------
Presence|No requirements|In-person and unsupervised remote.|In-person and supervised remote.
Resolution|No requirements|The minimum attributes necessary to accomplish identity resolution.<br><br>KBV may be used for added confidence.| Same as IAL2
Resolution|No requirements|The minimum attributes necessary to accomplish identity resolution.<br><br>KBV may be used for added confidence.| Same as IAL2.
Evidence|No identity evidence is collected| - One piece of SUPERIOR or STRONG evidence depending on strength of original proof and validation occurs with issuing source, or<br><br>- Two pieces of STRONG evidence, or <br><br> - One piece of STRONG evidence plus two (2) pieces of FAIR evidence.|- Two pieces of SUPERIOR evidence, or<br><br> - One piece of SUPERIOR evidence and one piece of STRONG evidence depending on strength of original proof and validation occurs with issuing source, or<br><br> - Two pieces of STRONG evidence plus one piece of FAIR evidence.
Validation|No validation|Each piece of evidence must be validated with a process that is able to achieve the same strength as the evidence presented.|Same as IAL2.
Verification| No verification |Verified by a process that is able to achieve a strength of STRONG.|Verified by a process that is able to achieve a strength of SUPERIOR.<br>
Address Confirmation|No requirements for address confirmation|Required. Enrollment code sent to any address of record. Notification sent by means different from enrollment code.|Required. Notification of proofing to postal address.
Biometric Collection|No|Optional|Mandatory
Security Controls|N/A|[SP 800-53](#SP800-53) Moderate Baseline (or equivalent federal or industry standard)|[SP 800-53](#SP800-53) High Baseline (or equivalent federal or industry standard)
Security Controls|N/A|[SP 800-53](#SP800-53) Moderate Baseline (or equivalent federal or industry standard).|[SP 800-53](#SP800-53) High Baseline (or equivalent federal or industry standard).
15 changes: 6 additions & 9 deletions sp800-63b/cover.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@

<div class="text-right" markdown="1">

# <a name="800-63b"></a> DRAFT NIST Special Publication 800-63B
# <a name="800-63b"></a> NIST Special Publication 800-63B

![](sp800-63-3/media/div-1.png)

Expand Down Expand Up @@ -30,16 +30,16 @@ Yee-Yin Choong
Kristen K. Greene
Mary F. Theofanos

This publication is available free of charge from:
https://doi.org/10.6028/NIST.SP.800-63b
This publication is available free of charge from:
https://doi.org/10.6028/NIST.SP.800-63b


![](sp800-63-3/media/csd.png)
![](sp800-63-3/media/nist_logo.png)

</div><div class="breaker text-right" markdown="1">

# DRAFT NIST Special Publication 800-63B
# NIST Special Publication 800-63B

# Digital Identity Guidelines

Expand Down Expand Up @@ -88,9 +88,8 @@ Mary F. Theofanos
*Information Access Division
Information Technology Laboratory*

This publication is available free of charge from:
https://doi.org/10.6028/NIST.SP.800-63b

This publication is available free of charge from:
https://doi.org/10.6028/NIST.SP.800-63b

Month TBD 2017

Expand Down Expand Up @@ -123,8 +122,6 @@ National Institute of Standards and Technology Special Publication 800-63B
Natl. Inst. Stand. Technol. Spec. Publ. 800-63B, xxx pages (MonthTBD 2017)
CODEN: NSPUE2



This publication is available free of charge from:
https://doi.org/10.6028/NIST.SP.800-63b

Expand Down
4 changes: 2 additions & 2 deletions sp800-63c/cover.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
<div class="text-right" markdown="1">

# <a name="800-63c"></a> DRAFT NIST Special Publication 800-63C
# <a name="800-63c"></a> NIST Special Publication 800-63C

![](sp800-63-3/media/div-1.png)

Expand Down Expand Up @@ -33,7 +33,7 @@ https://doi.org/10.6028/NIST.SP.800-63c

</div><div class="breaker text-right" markdown="1">

# DRAFT NIST Special Publication 800-63C
# NIST Special Publication 800-63C

# Digital Identity Guidelines

Expand Down
2 changes: 1 addition & 1 deletion sp800-63c/sec8_security.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ Mechanisms that assist in mitigating the threats identified above are identified
| | Send assertion over an authenticated protected channel authenticating the IdP | [7.1](#back-channel), [7.2](#front-channel) |
| | Include a non-guessable random identifier in the assertion | [6.2.1](#assertion-id) |
| Assertion disclosure | Send assertion over an authenticated protected channel authenticating the RP | [7.1](#back-channel), [7.2](#front-channel) |
| | Encrypt assertion for a specific RP (may be accomplished by use of a mutually authenticated protected channel) | [6.2.3](#encrypted-assertion) | [6.2.3] |
| | Encrypt assertion for a specific RP (may be accomplished by use of a mutually authenticated protected channel) | [6.2.3](#encrypted-assertion) |
| Assertion repudiation by the IdP | Cryptographically sign the assertion at the IdP with a key that supports non-repudiation; verify signature at RP | [6.2.2](#signed-assertion) |
| Assertion repudiation by the subscriber | Issue holder-of-key assertions; proof of possession of presented key verifies subscriber's participation | [6.1.2](#holderofkey) |
| Assertion redirect | Include identity of the RP ("audience") for which the assertion is issued in its signed content; RP verifies that they are intended recipient | [6](#assertions), [7.1](#back-channel), [7.2](#front-channel) |
Expand Down

0 comments on commit 9dda8b1

Please sign in to comment.