├── _includes ├── NISTPagesFooter.html ├── sidenav.html └── NISTPagesHeader.html ├── assets ├── 63.png ├── 63a.png ├── 63b.png ├── 63c.png ├── issue_title.png ├── 800_63_3_doc.png ├── watch_project.png ├── create_new_issue.png ├── submit_new_issue.png ├── 800_63_3_Proofing.png ├── document-icons.graffle ├── issue_apply_label.png ├── 800_63_3_Federation.png ├── create_github_account.png └── 800_63_3_Authenticators.png ├── .gitignore ├── sp800-63-3 ├── media │ ├── csd.png │ ├── div-1.png │ ├── div-2.png │ ├── model.png │ ├── AAL_CYOA.png │ ├── FAL_CYOA.png │ ├── IAL_CYOA.png │ ├── aal-step1.png │ ├── aal-step2.png │ ├── fal-step1.png │ ├── fal-step2.png │ ├── fal-step3.png │ ├── ial-step1.png │ ├── ial-step2.png │ ├── ial-step3.png │ ├── ial-step4.png │ ├── ial-step5.png │ ├── ial-step6.png │ ├── model.graffle │ ├── nist_logo.png │ ├── commerce_logo.png │ └── 800-63-3 Decision Trees.graffle ├── sec3_definitions.md ├── index.html ├── README.md ├── errata.md ├── sec7_tofedornottofed.md └── sec8_references.md ├── sp800-63a ├── media │ ├── csd.png │ ├── div-1.png │ ├── div-2.png │ ├── ProofingProcess.png │ └── ProofingProcess.graffle ├── sec3_definitions.md ├── index.html ├── README.md ├── errata.md ├── sec6_dc.md ├── sec7_security.md ├── sec10_references.md ├── sec1_2_introduction.md ├── sec8_privacy.md └── cover.md ├── sp800-63b ├── media │ ├── use.png │ ├── div-1.png │ ├── div-2.png │ ├── Look-up-secrets.png │ ├── Memorized-secret.png │ ├── Out-of-band-OOB.png │ ├── Authenticators.graffle │ ├── Single-factor-crypto.png │ ├── Multi-factor-otp-device.png │ ├── Single-factor-otp-device.png │ ├── Multi-factor-crypto-device.png │ ├── Multi-factor-software-crypto.png │ ├── Single-factor-software-crypto.png │ └── 800-63B-sec10_Usability Table.docx ├── sec3_definitions.md ├── index.html ├── README.md ├── errata.md ├── sec9_privacy.md ├── sec1_2_introduction.md ├── appA_memorized.md ├── sec7_session.md └── cover.md ├── static ├── css │ ├── nist_logo.png │ ├── graphics.css │ ├── nist_logo_mark.png │ └── NISTPages.css ├── font-awesome │ ├── fonts │ │ ├── FontAwesome.otf │ │ ├── fontawesome-webfont.eot │ │ ├── fontawesome-webfont.ttf │ │ ├── fontawesome-webfont.woff │ │ └── .htaccess │ ├── less │ │ ├── fixed-width.less │ │ ├── core.less │ │ ├── bordered-pulled.less │ │ ├── rotated-flipped.less │ │ ├── larger.less │ │ ├── list.less │ │ ├── font-awesome.less │ │ ├── stacked.less │ │ ├── path.less │ │ ├── mixins.less │ │ └── spinning.less │ └── scss │ │ ├── _fixed-width.scss │ │ ├── _core.scss │ │ ├── _bordered-pulled.scss │ │ ├── _larger.scss │ │ ├── _rotated-flipped.scss │ │ ├── _list.scss │ │ ├── font-awesome.scss │ │ ├── _stacked.scss │ │ ├── _path.scss │ │ ├── _mixins.scss │ │ └── _spinning.scss └── js │ └── init.js ├── sp800-63c ├── media │ ├── broker.png │ ├── div-1.png │ ├── div-2.png │ ├── dynamic.png │ ├── manual.png │ ├── authority.png │ ├── back-channel.png │ ├── broker.graffle │ ├── dynamic.graffle │ ├── federation.png │ ├── manual.graffle │ ├── authority.graffle │ ├── federation.graffle │ ├── front-channel.png │ ├── back-channel.graffle │ └── front-channel.graffle ├── sec3_definitions.md ├── index.html ├── README.md ├── errata.md ├── sec1_2_introduction.md ├── references.md ├── sec8_security.md ├── sec4_fal.md ├── sec11_examples.md ├── sec7_presentation.md ├── cover.md └── sec9_privacy.md ├── docker-compose.yml ├── _layouts ├── page.html ├── cover.html └── default.html ├── .github └── ISSUE_TEMPLATE.md ├── sp800-63-3.md ├── sp800-63a.md ├── sp800-63b.md ├── sp800-63c.md ├── README.md ├── _config.yml ├── LICENSE.md ├── index.md └── comment_help.md /_includes/NISTPagesFooter.html: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /assets/63.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/63.png -------------------------------------------------------------------------------- /assets/63a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/63a.png -------------------------------------------------------------------------------- /assets/63b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/63b.png -------------------------------------------------------------------------------- /assets/63c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/63c.png -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.pdf 2 | 3 | _site/ 4 | .sass-cache/ 5 | .jekyll-metadata 6 | *.css.map 7 | *.lock -------------------------------------------------------------------------------- /assets/issue_title.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/issue_title.png -------------------------------------------------------------------------------- /assets/800_63_3_doc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/800_63_3_doc.png -------------------------------------------------------------------------------- /assets/watch_project.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/watch_project.png -------------------------------------------------------------------------------- /sp800-63-3/media/csd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/csd.png -------------------------------------------------------------------------------- /sp800-63a/media/csd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63a/media/csd.png -------------------------------------------------------------------------------- /sp800-63b/media/use.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/use.png -------------------------------------------------------------------------------- /static/css/nist_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/static/css/nist_logo.png -------------------------------------------------------------------------------- /assets/create_new_issue.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/create_new_issue.png -------------------------------------------------------------------------------- /assets/submit_new_issue.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/submit_new_issue.png -------------------------------------------------------------------------------- /sp800-63-3/media/div-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/div-1.png -------------------------------------------------------------------------------- /sp800-63-3/media/div-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/div-2.png -------------------------------------------------------------------------------- /sp800-63-3/media/model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/model.png -------------------------------------------------------------------------------- /sp800-63a/media/div-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63a/media/div-1.png -------------------------------------------------------------------------------- /sp800-63a/media/div-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63a/media/div-2.png -------------------------------------------------------------------------------- /sp800-63b/media/div-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/div-1.png -------------------------------------------------------------------------------- /sp800-63b/media/div-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/div-2.png -------------------------------------------------------------------------------- /sp800-63c/media/broker.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/broker.png -------------------------------------------------------------------------------- /sp800-63c/media/div-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/div-1.png -------------------------------------------------------------------------------- /sp800-63c/media/div-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/div-2.png -------------------------------------------------------------------------------- /sp800-63c/media/dynamic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/dynamic.png -------------------------------------------------------------------------------- /sp800-63c/media/manual.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/manual.png -------------------------------------------------------------------------------- /assets/800_63_3_Proofing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/800_63_3_Proofing.png -------------------------------------------------------------------------------- /assets/document-icons.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/document-icons.graffle -------------------------------------------------------------------------------- /assets/issue_apply_label.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/issue_apply_label.png -------------------------------------------------------------------------------- /sp800-63-3/media/AAL_CYOA.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/AAL_CYOA.png -------------------------------------------------------------------------------- /sp800-63-3/media/FAL_CYOA.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/FAL_CYOA.png -------------------------------------------------------------------------------- /sp800-63-3/media/IAL_CYOA.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/IAL_CYOA.png -------------------------------------------------------------------------------- /sp800-63c/media/authority.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/authority.png -------------------------------------------------------------------------------- /static/css/graphics.css: -------------------------------------------------------------------------------- 1 | img[alt=authenticator] { height: 100px; width: 100px; } /* Generic graphic size */ 2 | -------------------------------------------------------------------------------- /static/css/nist_logo_mark.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/static/css/nist_logo_mark.png -------------------------------------------------------------------------------- /assets/800_63_3_Federation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/800_63_3_Federation.png -------------------------------------------------------------------------------- /assets/create_github_account.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/create_github_account.png -------------------------------------------------------------------------------- /sp800-63-3/media/aal-step1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/aal-step1.png -------------------------------------------------------------------------------- /sp800-63-3/media/aal-step2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/aal-step2.png -------------------------------------------------------------------------------- /sp800-63-3/media/fal-step1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/fal-step1.png -------------------------------------------------------------------------------- /sp800-63-3/media/fal-step2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/fal-step2.png -------------------------------------------------------------------------------- /sp800-63-3/media/fal-step3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/fal-step3.png -------------------------------------------------------------------------------- /sp800-63-3/media/ial-step1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/ial-step1.png -------------------------------------------------------------------------------- /sp800-63-3/media/ial-step2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/ial-step2.png -------------------------------------------------------------------------------- /sp800-63-3/media/ial-step3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/ial-step3.png -------------------------------------------------------------------------------- /sp800-63-3/media/ial-step4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/ial-step4.png -------------------------------------------------------------------------------- /sp800-63-3/media/ial-step5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/ial-step5.png -------------------------------------------------------------------------------- /sp800-63-3/media/ial-step6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/ial-step6.png -------------------------------------------------------------------------------- /sp800-63-3/media/model.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/model.graffle -------------------------------------------------------------------------------- /sp800-63-3/media/nist_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/nist_logo.png -------------------------------------------------------------------------------- /sp800-63c/media/back-channel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/back-channel.png -------------------------------------------------------------------------------- /sp800-63c/media/broker.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/broker.graffle -------------------------------------------------------------------------------- /sp800-63c/media/dynamic.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/dynamic.graffle -------------------------------------------------------------------------------- /sp800-63c/media/federation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/federation.png -------------------------------------------------------------------------------- /sp800-63c/media/manual.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/manual.graffle -------------------------------------------------------------------------------- /assets/800_63_3_Authenticators.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/assets/800_63_3_Authenticators.png -------------------------------------------------------------------------------- /sp800-63-3/media/commerce_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/commerce_logo.png -------------------------------------------------------------------------------- /sp800-63c/media/authority.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/authority.graffle -------------------------------------------------------------------------------- /sp800-63c/media/federation.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/federation.graffle -------------------------------------------------------------------------------- /sp800-63c/media/front-channel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/front-channel.png -------------------------------------------------------------------------------- /sp800-63a/media/ProofingProcess.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63a/media/ProofingProcess.png -------------------------------------------------------------------------------- /sp800-63b/media/Look-up-secrets.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/Look-up-secrets.png -------------------------------------------------------------------------------- /sp800-63b/media/Memorized-secret.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/Memorized-secret.png -------------------------------------------------------------------------------- /sp800-63b/media/Out-of-band-OOB.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/Out-of-band-OOB.png -------------------------------------------------------------------------------- /sp800-63c/media/back-channel.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/back-channel.graffle -------------------------------------------------------------------------------- /sp800-63c/media/front-channel.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63c/media/front-channel.graffle -------------------------------------------------------------------------------- /sp800-63a/media/ProofingProcess.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63a/media/ProofingProcess.graffle -------------------------------------------------------------------------------- /sp800-63b/media/Authenticators.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/Authenticators.graffle -------------------------------------------------------------------------------- /sp800-63b/media/Single-factor-crypto.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/Single-factor-crypto.png -------------------------------------------------------------------------------- /static/font-awesome/fonts/FontAwesome.otf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/static/font-awesome/fonts/FontAwesome.otf -------------------------------------------------------------------------------- /sp800-63b/media/Multi-factor-otp-device.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/Multi-factor-otp-device.png -------------------------------------------------------------------------------- /sp800-63b/media/Single-factor-otp-device.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/Single-factor-otp-device.png -------------------------------------------------------------------------------- /sp800-63b/media/Multi-factor-crypto-device.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/Multi-factor-crypto-device.png -------------------------------------------------------------------------------- /sp800-63-3/media/800-63-3 Decision Trees.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63-3/media/800-63-3 Decision Trees.graffle -------------------------------------------------------------------------------- /sp800-63b/media/Multi-factor-software-crypto.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/Multi-factor-software-crypto.png -------------------------------------------------------------------------------- /sp800-63b/media/Single-factor-software-crypto.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/Single-factor-software-crypto.png -------------------------------------------------------------------------------- /static/font-awesome/fonts/fontawesome-webfont.eot: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/static/font-awesome/fonts/fontawesome-webfont.eot -------------------------------------------------------------------------------- /static/font-awesome/fonts/fontawesome-webfont.ttf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/static/font-awesome/fonts/fontawesome-webfont.ttf -------------------------------------------------------------------------------- /sp800-63b/media/800-63B-sec10_Usability Table.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/sp800-63b/media/800-63B-sec10_Usability Table.docx -------------------------------------------------------------------------------- /static/font-awesome/fonts/fontawesome-webfont.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/usnistgov/800-63-3/HEAD/static/font-awesome/fonts/fontawesome-webfont.woff -------------------------------------------------------------------------------- /static/font-awesome/fonts/.htaccess: -------------------------------------------------------------------------------- 1 | 2 | 3 | Header set Access-Control-Allow-Origin "*" 4 | 5 | -------------------------------------------------------------------------------- /static/font-awesome/less/fixed-width.less: -------------------------------------------------------------------------------- 1 | // Fixed Width Icons 2 | // ------------------------- 3 | .@{fa-css-prefix}-fw { 4 | width: (18em / 14); 5 | text-align: center; 6 | } 7 | -------------------------------------------------------------------------------- /static/font-awesome/scss/_fixed-width.scss: -------------------------------------------------------------------------------- 1 | // Fixed Width Icons 2 | // ------------------------- 3 | .#{$fa-css-prefix}-fw { 4 | width: (18em / 14); 5 | text-align: center; 6 | } 7 | -------------------------------------------------------------------------------- /docker-compose.yml: -------------------------------------------------------------------------------- 1 | version: '3' 2 | 3 | services: 4 | server: 5 | image: jricher/nistpages-dev 6 | volumes: 7 | - .:/srv/jekyll 8 | command: serve 9 | ports: 10 | - "4000:4000" 11 | -------------------------------------------------------------------------------- /sp800-63-3/sec3_definitions.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 | ## 3 Definitions and Abbreviations 5 | 6 | See [Appendix A](#def-and-acr) for a complete set of definitions and abbreviations. 7 | -------------------------------------------------------------------------------- /sp800-63b/sec3_definitions.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 | ## 3 Definitions and Abbreviations 5 | 6 | See [SP 800-63](sp800-63-3.html), Appendix A for a complete set of definitions and abbreviations. 7 | -------------------------------------------------------------------------------- /sp800-63a/sec3_definitions.md: -------------------------------------------------------------------------------- 1 | 2 | 3 |
4 | 5 | ## 3 Definitions and Abbreviations 6 | 7 | See [SP 800-63](sp800-63-3.html) Appendix A for a complete set of definitions and abbreviations. 8 | -------------------------------------------------------------------------------- /sp800-63c/sec3_definitions.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 | ## 3 Definitions and Abbreviations 5 | 6 | See [SP 800-63](sp800-63-3.html), Appendix A for a complete set of definitions and abbreviations. 7 | -------------------------------------------------------------------------------- /_layouts/page.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | --- 4 | 5 |
6 | 7 | This revision of NIST SP 800-63 has been superseded by NIST SP 800-63-4 as of August 1, 2025. Please refer to those documents for the current guidelines. 8 | 9 |
10 | 11 | {{ content }} 12 | -------------------------------------------------------------------------------- /static/font-awesome/less/core.less: -------------------------------------------------------------------------------- 1 | // Base Class Definition 2 | // ------------------------- 3 | 4 | .@{fa-css-prefix} { 5 | display: inline-block; 6 | font-family: FontAwesome; 7 | font-style: normal; 8 | font-weight: normal; 9 | line-height: 1; 10 | -webkit-font-smoothing: antialiased; 11 | -moz-osx-font-smoothing: grayscale; 12 | } 13 | -------------------------------------------------------------------------------- /static/font-awesome/scss/_core.scss: -------------------------------------------------------------------------------- 1 | // Base Class Definition 2 | // ------------------------- 3 | 4 | .#{$fa-css-prefix} { 5 | display: inline-block; 6 | font-family: FontAwesome; 7 | font-style: normal; 8 | font-weight: normal; 9 | line-height: 1; 10 | -webkit-font-smoothing: antialiased; 11 | -moz-osx-font-smoothing: grayscale; 12 | } 13 | -------------------------------------------------------------------------------- /static/font-awesome/less/bordered-pulled.less: -------------------------------------------------------------------------------- 1 | // Bordered & Pulled 2 | // ------------------------- 3 | 4 | .@{fa-css-prefix}-border { 5 | padding: .2em .25em .15em; 6 | border: solid .08em @fa-border-color; 7 | border-radius: .1em; 8 | } 9 | 10 | .pull-right { float: right; } 11 | .pull-left { float: left; } 12 | 13 | .@{fa-css-prefix} { 14 | &.pull-left { margin-right: .3em; } 15 | &.pull-right { margin-left: .3em; } 16 | } 17 | -------------------------------------------------------------------------------- /static/font-awesome/less/rotated-flipped.less: -------------------------------------------------------------------------------- 1 | // Rotated & Flipped Icons 2 | // ------------------------- 3 | 4 | .@{fa-css-prefix}-rotate-90 { .fa-icon-rotate(90deg, 1); } 5 | .@{fa-css-prefix}-rotate-180 { .fa-icon-rotate(180deg, 2); } 6 | .@{fa-css-prefix}-rotate-270 { .fa-icon-rotate(270deg, 3); } 7 | 8 | .@{fa-css-prefix}-flip-horizontal { .fa-icon-flip(-1, 1, 0); } 9 | .@{fa-css-prefix}-flip-vertical { .fa-icon-flip(1, -1, 2); } 10 | -------------------------------------------------------------------------------- /static/font-awesome/scss/_bordered-pulled.scss: -------------------------------------------------------------------------------- 1 | // Bordered & Pulled 2 | // ------------------------- 3 | 4 | .#{$fa-css-prefix}-border { 5 | padding: .2em .25em .15em; 6 | border: solid .08em $fa-border-color; 7 | border-radius: .1em; 8 | } 9 | 10 | .pull-right { float: right; } 11 | .pull-left { float: left; } 12 | 13 | .#{$fa-css-prefix} { 14 | &.pull-left { margin-right: .3em; } 15 | &.pull-right { margin-left: .3em; } 16 | } 17 | -------------------------------------------------------------------------------- /_layouts/cover.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | {% include NISTPagesHeader.html %} 4 | 5 |
6 |
7 | {{ content }} 8 |
9 |
10 | 11 | 17 | 18 | {% include NISTPagesFooter.html %} 19 | 20 | -------------------------------------------------------------------------------- /static/font-awesome/less/larger.less: -------------------------------------------------------------------------------- 1 | // Icon Sizes 2 | // ------------------------- 3 | 4 | /* makes the font 33% larger relative to the icon container */ 5 | .@{fa-css-prefix}-lg { 6 | font-size: (4em / 3); 7 | line-height: (3em / 4); 8 | vertical-align: -15%; 9 | } 10 | .@{fa-css-prefix}-2x { font-size: 2em; } 11 | .@{fa-css-prefix}-3x { font-size: 3em; } 12 | .@{fa-css-prefix}-4x { font-size: 4em; } 13 | .@{fa-css-prefix}-5x { font-size: 5em; } 14 | -------------------------------------------------------------------------------- /static/font-awesome/scss/_larger.scss: -------------------------------------------------------------------------------- 1 | // Icon Sizes 2 | // ------------------------- 3 | 4 | /* makes the font 33% larger relative to the icon container */ 5 | .#{$fa-css-prefix}-lg { 6 | font-size: (4em / 3); 7 | line-height: (3em / 4); 8 | vertical-align: -15%; 9 | } 10 | .#{$fa-css-prefix}-2x { font-size: 2em; } 11 | .#{$fa-css-prefix}-3x { font-size: 3em; } 12 | .#{$fa-css-prefix}-4x { font-size: 4em; } 13 | .#{$fa-css-prefix}-5x { font-size: 5em; } 14 | -------------------------------------------------------------------------------- /_layouts/default.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | {% include NISTPagesHeader.html %} 4 | 5 | {% include sidenav.html %} 6 | 7 |
8 |
9 | {{ content }} 10 |
11 |
12 | 13 | 19 | 20 | {% include NISTPagesFooter.html %} 21 | 22 | -------------------------------------------------------------------------------- /static/font-awesome/less/list.less: -------------------------------------------------------------------------------- 1 | // List Icons 2 | // ------------------------- 3 | 4 | .@{fa-css-prefix}-ul { 5 | padding-left: 0; 6 | margin-left: @fa-li-width; 7 | list-style-type: none; 8 | > li { position: relative; } 9 | } 10 | .@{fa-css-prefix}-li { 11 | position: absolute; 12 | left: -@fa-li-width; 13 | width: @fa-li-width; 14 | top: (2em / 14); 15 | text-align: center; 16 | &.@{fa-css-prefix}-lg { 17 | left: -@fa-li-width + (4em / 14); 18 | } 19 | } 20 | -------------------------------------------------------------------------------- /static/font-awesome/scss/_rotated-flipped.scss: -------------------------------------------------------------------------------- 1 | // Rotated & Flipped Icons 2 | // ------------------------- 3 | 4 | .#{$fa-css-prefix}-rotate-90 { @include fa-icon-rotate(90deg, 1); } 5 | .#{$fa-css-prefix}-rotate-180 { @include fa-icon-rotate(180deg, 2); } 6 | .#{$fa-css-prefix}-rotate-270 { @include fa-icon-rotate(270deg, 3); } 7 | 8 | .#{$fa-css-prefix}-flip-horizontal { @include fa-icon-flip(-1, 1, 0); } 9 | .#{$fa-css-prefix}-flip-vertical { @include fa-icon-flip(1, -1, 2); } 10 | -------------------------------------------------------------------------------- /static/font-awesome/scss/_list.scss: -------------------------------------------------------------------------------- 1 | // List Icons 2 | // ------------------------- 3 | 4 | .#{$fa-css-prefix}-ul { 5 | padding-left: 0; 6 | margin-left: $fa-li-width; 7 | list-style-type: none; 8 | > li { position: relative; } 9 | } 10 | .#{$fa-css-prefix}-li { 11 | position: absolute; 12 | left: -$fa-li-width; 13 | width: $fa-li-width; 14 | top: (2em / 14); 15 | text-align: center; 16 | &.#{$fa-css-prefix}-lg { 17 | left: -$fa-li-width + (4em / 14); 18 | } 19 | } 20 | -------------------------------------------------------------------------------- /static/font-awesome/scss/font-awesome.scss: -------------------------------------------------------------------------------- 1 | /*! 2 | * Font Awesome 4.1.0 by @davegandy - http://fontawesome.io - @fontawesome 3 | * License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License) 4 | */ 5 | 6 | @import "variables"; 7 | @import "mixins"; 8 | @import "path"; 9 | @import "core"; 10 | @import "larger"; 11 | @import "fixed-width"; 12 | @import "list"; 13 | @import "bordered-pulled"; 14 | @import "spinning"; 15 | @import "rotated-flipped"; 16 | @import "stacked"; 17 | @import "icons"; 18 | -------------------------------------------------------------------------------- /static/font-awesome/less/font-awesome.less: -------------------------------------------------------------------------------- 1 | /*! 2 | * Font Awesome 4.1.0 by @davegandy - http://fontawesome.io - @fontawesome 3 | * License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License) 4 | */ 5 | 6 | @import "variables.less"; 7 | @import "mixins.less"; 8 | @import "path.less"; 9 | @import "core.less"; 10 | @import "larger.less"; 11 | @import "fixed-width.less"; 12 | @import "list.less"; 13 | @import "bordered-pulled.less"; 14 | @import "spinning.less"; 15 | @import "rotated-flipped.less"; 16 | @import "stacked.less"; 17 | @import "icons.less"; 18 | -------------------------------------------------------------------------------- /static/font-awesome/less/stacked.less: -------------------------------------------------------------------------------- 1 | // Stacked Icons 2 | // ------------------------- 3 | 4 | .@{fa-css-prefix}-stack { 5 | position: relative; 6 | display: inline-block; 7 | width: 2em; 8 | height: 2em; 9 | line-height: 2em; 10 | vertical-align: middle; 11 | } 12 | .@{fa-css-prefix}-stack-1x, .@{fa-css-prefix}-stack-2x { 13 | position: absolute; 14 | left: 0; 15 | width: 100%; 16 | text-align: center; 17 | } 18 | .@{fa-css-prefix}-stack-1x { line-height: inherit; } 19 | .@{fa-css-prefix}-stack-2x { font-size: 2em; } 20 | .@{fa-css-prefix}-inverse { color: @fa-inverse; } 21 | -------------------------------------------------------------------------------- /static/font-awesome/scss/_stacked.scss: -------------------------------------------------------------------------------- 1 | // Stacked Icons 2 | // ------------------------- 3 | 4 | .#{$fa-css-prefix}-stack { 5 | position: relative; 6 | display: inline-block; 7 | width: 2em; 8 | height: 2em; 9 | line-height: 2em; 10 | vertical-align: middle; 11 | } 12 | .#{$fa-css-prefix}-stack-1x, .#{$fa-css-prefix}-stack-2x { 13 | position: absolute; 14 | left: 0; 15 | width: 100%; 16 | text-align: center; 17 | } 18 | .#{$fa-css-prefix}-stack-1x { line-height: inherit; } 19 | .#{$fa-css-prefix}-stack-2x { font-size: 2em; } 20 | .#{$fa-css-prefix}-inverse { color: $fa-inverse; } 21 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | ## SP 800-63-3 Has Been Published 2 | 3 | The SP 800-63-3 document suite has been finalized and published. It is publicly available at https://pages.nist.gov/800-63-3/ 4 | 5 | As the document has been finalized in its current revision, requests for normative changes will be held for adjudication for possible inclusion in a future revision of the SP 800-63 document suite. Editorial changes and internal clarifications may be incorporated in an errata set for this revision. Additional context and discussion may be addressed by the FAQ (https://pages.nist.gov/800-63-FAQ/) or other publications and resources. 6 | -------------------------------------------------------------------------------- /sp800-63-3.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: "NIST Special Publication 800-63-3" 4 | description: "NIST Special Publication 800-63-3" 5 | --- 6 | 7 | {{ site.time | date_to_rfc822 }} 8 | {% include_relative sp800-63-3/cover.md %} 9 | {% include_relative sp800-63-3/errata.md %} 10 | {% include_relative sp800-63-3/sec1_2_introduction.md %} 11 | {% include_relative sp800-63-3/sec3_definitions.md %} 12 | {% include_relative sp800-63-3/sec4_model.md %} 13 | {% include_relative sp800-63-3/sec5_DIRM.md %} 14 | {% include_relative sp800-63-3/sec6_xAL.md %} 15 | {% include_relative sp800-63-3/sec7_tofedornottofed.md %} 16 | {% include_relative sp800-63-3/sec8_references.md %} 17 | {% include_relative sp800-63-3/definitions.md %} 18 | -------------------------------------------------------------------------------- /static/js/init.js: -------------------------------------------------------------------------------- 1 | $(document).ready(function() { 2 | $('.below-fold').hide(); 3 | $('.below-fold').after(''); 4 | 5 | $(document).on( "click", ".hide-below-fold", function() { 6 | $(this).prev('.below-fold').hide(); 7 | $(this).replaceWith(''); 8 | }); 9 | 10 | $(document).on( "click", ".show-below-fold", function() { 11 | $(this).prev('.below-fold').show(); 12 | $(this).replaceWith(''); 13 | }); 14 | }); -------------------------------------------------------------------------------- /sp800-63a.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: "NIST Special Publication 800-63A" 4 | description: "NIST Special Publication 800-63A" 5 | --- 6 | 7 | {{ site.time | date_to_rfc822 }} 8 | {% include_relative sp800-63a/cover.md %} 9 | {% include_relative sp800-63a/errata.md %} 10 | {% include_relative sp800-63a/sec1_2_introduction.md %} 11 | {% include_relative sp800-63a/sec3_definitions.md %} 12 | {% include_relative sp800-63a/sec4_ial.md %} 13 | {% include_relative sp800-63a/sec5_proofing.md %} 14 | {% include_relative sp800-63a/sec6_dc.md %} 15 | {% include_relative sp800-63a/sec7_security.md %} 16 | {% include_relative sp800-63a/sec8_privacy.md %} 17 | {% include_relative sp800-63a/sec9_usability.md %} 18 | {% include_relative sp800-63a/sec10_references.md %} 19 | -------------------------------------------------------------------------------- /static/font-awesome/scss/_path.scss: -------------------------------------------------------------------------------- 1 | /* FONT PATH 2 | * -------------------------- */ 3 | 4 | @font-face { 5 | font-family: 'FontAwesome'; 6 | src: url('#{$fa-font-path}/fontawesome-webfont.eot?v=#{$fa-version}'); 7 | src: url('#{$fa-font-path}/fontawesome-webfont.eot?#iefix&v=#{$fa-version}') format('embedded-opentype'), 8 | url('#{$fa-font-path}/fontawesome-webfont.woff?v=#{$fa-version}') format('woff'), 9 | url('#{$fa-font-path}/fontawesome-webfont.ttf?v=#{$fa-version}') format('truetype'), 10 | url('#{$fa-font-path}/fontawesome-webfont.svg?v=#{$fa-version}#fontawesomeregular') format('svg'); 11 | //src: url('#{$fa-font-path}/FontAwesome.otf') format('opentype'); // used when developing fonts 12 | font-weight: normal; 13 | font-style: normal; 14 | } 15 | -------------------------------------------------------------------------------- /static/font-awesome/less/path.less: -------------------------------------------------------------------------------- 1 | /* FONT PATH 2 | * -------------------------- */ 3 | 4 | @font-face { 5 | font-family: 'FontAwesome'; 6 | src: ~"url('@{fa-font-path}/fontawesome-webfont.eot?v=@{fa-version}')"; 7 | src: ~"url('@{fa-font-path}/fontawesome-webfont.eot?#iefix&v=@{fa-version}') format('embedded-opentype')", 8 | ~"url('@{fa-font-path}/fontawesome-webfont.woff?v=@{fa-version}') format('woff')", 9 | ~"url('@{fa-font-path}/fontawesome-webfont.ttf?v=@{fa-version}') format('truetype')", 10 | ~"url('@{fa-font-path}/fontawesome-webfont.svg?v=@{fa-version}#fontawesomeregular') format('svg')"; 11 | // src: url('@{fa-font-path}/FontAwesome.otf') format('opentype'); // used when developing fonts 12 | font-weight: normal; 13 | font-style: normal; 14 | } 15 | -------------------------------------------------------------------------------- /static/font-awesome/less/mixins.less: -------------------------------------------------------------------------------- 1 | // Mixins 2 | // -------------------------- 3 | 4 | .fa-icon-rotate(@degrees, @rotation) { 5 | filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=@rotation); 6 | -webkit-transform: rotate(@degrees); 7 | -moz-transform: rotate(@degrees); 8 | -ms-transform: rotate(@degrees); 9 | -o-transform: rotate(@degrees); 10 | transform: rotate(@degrees); 11 | } 12 | 13 | .fa-icon-flip(@horiz, @vert, @rotation) { 14 | filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=@rotation, mirror=1); 15 | -webkit-transform: scale(@horiz, @vert); 16 | -moz-transform: scale(@horiz, @vert); 17 | -ms-transform: scale(@horiz, @vert); 18 | -o-transform: scale(@horiz, @vert); 19 | transform: scale(@horiz, @vert); 20 | } 21 | -------------------------------------------------------------------------------- /static/font-awesome/scss/_mixins.scss: -------------------------------------------------------------------------------- 1 | // Mixins 2 | // -------------------------- 3 | 4 | @mixin fa-icon-rotate($degrees, $rotation) { 5 | filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=#{$rotation}); 6 | -webkit-transform: rotate($degrees); 7 | -moz-transform: rotate($degrees); 8 | -ms-transform: rotate($degrees); 9 | -o-transform: rotate($degrees); 10 | transform: rotate($degrees); 11 | } 12 | 13 | @mixin fa-icon-flip($horiz, $vert, $rotation) { 14 | filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=#{$rotation}); 15 | -webkit-transform: scale($horiz, $vert); 16 | -moz-transform: scale($horiz, $vert); 17 | -ms-transform: scale($horiz, $vert); 18 | -o-transform: scale($horiz, $vert); 19 | transform: scale($horiz, $vert); 20 | } 21 | -------------------------------------------------------------------------------- /sp800-63-3/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | Redirect 800-63 document directories to main pages.nist.gov page 4 | 5 | 6 | 7 | 8 | 13 | 14 | 15 |

If you are accessing one of the SP 800-63 document directories 16 | directly, this will send you to the right page:

17 |

https://pages.nist.gov/800-63-3/

18 | 19 | 20 | -------------------------------------------------------------------------------- /sp800-63a/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | Redirect 800-63 document directories to main pages.nist.gov page 4 | 5 | 6 | 7 | 8 | 13 | 14 | 15 |

If you are accessing one of the SP 800-63 document directories 16 | directly, this will send you to the right page:

17 |

https://pages.nist.gov/800-63-3/

18 | 19 | 20 | -------------------------------------------------------------------------------- /sp800-63b/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | Redirect 800-63 document directories to main pages.nist.gov page 4 | 5 | 6 | 7 | 8 | 13 | 14 | 15 |

If you are accessing one of the SP 800-63 document directories 16 | directly, this will send you to the right page:

17 |

https://pages.nist.gov/800-63-3/

18 | 19 | 20 | -------------------------------------------------------------------------------- /sp800-63c/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | Redirect 800-63 document directories to main pages.nist.gov page 4 | 5 | 6 | 7 | 8 | 13 | 14 | 15 |

If you are accessing one of the SP 800-63 document directories 16 | directly, this will send you to the right page:

17 |

https://pages.nist.gov/800-63-3/

18 | 19 | 20 | -------------------------------------------------------------------------------- /sp800-63b.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: "NIST Special Publication 800-63B" 4 | description: "NIST Special Publication 800-63B" 5 | --- 6 | 7 | {{ site.time | date_to_rfc822 }} 8 | {% include_relative sp800-63b/cover.md %} 9 | {% include_relative sp800-63b/errata.md %} 10 | {% include_relative sp800-63b/sec1_2_introduction.md %} 11 | {% include_relative sp800-63b/sec3_definitions.md %} 12 | {% include_relative sp800-63b/sec4_aal.md %} 13 | {% include_relative sp800-63b/sec5_authenticators.md %} 14 | {% include_relative sp800-63b/sec6_lifecycle.md %} 15 | {% include_relative sp800-63b/sec7_session.md %} 16 | {% include_relative sp800-63b/sec8_security.md %} 17 | {% include_relative sp800-63b/sec9_privacy.md %} 18 | {% include_relative sp800-63b/sec10_usability.md %} 19 | {% include_relative sp800-63b/references.md %} 20 | {% include_relative sp800-63b/appA_memorized.md %} 21 | -------------------------------------------------------------------------------- /sp800-63c.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: "NIST Special Publication 800-63C" 4 | description: "NIST Special Publication 800-63C" 5 | --- 6 | 7 | {{ site.time | date_to_rfc822 }} 8 | {% include_relative sp800-63c/cover.md %} 9 | {% include_relative sp800-63c/errata.md %} 10 | {% include_relative sp800-63c/sec1_2_introduction.md %} 11 | {% include_relative sp800-63c/sec3_definitions.md %} 12 | {% include_relative sp800-63c/sec4_fal.md %} 13 | {% include_relative sp800-63c/sec5_federation.md %} 14 | {% include_relative sp800-63c/sec6_assertions.md %} 15 | {% include_relative sp800-63c/sec7_presentation.md %} 16 | {% include_relative sp800-63c/sec8_security.md %} 17 | {% include_relative sp800-63c/sec9_privacy.md %} 18 | {% include_relative sp800-63c/sec10_usability.md %} 19 | {% include_relative sp800-63c/sec11_examples.md %} 20 | {% include_relative sp800-63c/references.md %} 21 | 22 | -------------------------------------------------------------------------------- /static/font-awesome/less/spinning.less: -------------------------------------------------------------------------------- 1 | // Spinning Icons 2 | // -------------------------- 3 | 4 | .@{fa-css-prefix}-spin { 5 | -webkit-animation: spin 2s infinite linear; 6 | -moz-animation: spin 2s infinite linear; 7 | -o-animation: spin 2s infinite linear; 8 | animation: spin 2s infinite linear; 9 | } 10 | 11 | @-moz-keyframes spin { 12 | 0% { -moz-transform: rotate(0deg); } 13 | 100% { -moz-transform: rotate(359deg); } 14 | } 15 | @-webkit-keyframes spin { 16 | 0% { -webkit-transform: rotate(0deg); } 17 | 100% { -webkit-transform: rotate(359deg); } 18 | } 19 | @-o-keyframes spin { 20 | 0% { -o-transform: rotate(0deg); } 21 | 100% { -o-transform: rotate(359deg); } 22 | } 23 | @keyframes spin { 24 | 0% { 25 | -webkit-transform: rotate(0deg); 26 | transform: rotate(0deg); 27 | } 28 | 100% { 29 | -webkit-transform: rotate(359deg); 30 | transform: rotate(359deg); 31 | } 32 | } 33 | -------------------------------------------------------------------------------- /static/font-awesome/scss/_spinning.scss: -------------------------------------------------------------------------------- 1 | // Spinning Icons 2 | // -------------------------- 3 | 4 | .#{$fa-css-prefix}-spin { 5 | -webkit-animation: spin 2s infinite linear; 6 | -moz-animation: spin 2s infinite linear; 7 | -o-animation: spin 2s infinite linear; 8 | animation: spin 2s infinite linear; 9 | } 10 | 11 | @-moz-keyframes spin { 12 | 0% { -moz-transform: rotate(0deg); } 13 | 100% { -moz-transform: rotate(359deg); } 14 | } 15 | @-webkit-keyframes spin { 16 | 0% { -webkit-transform: rotate(0deg); } 17 | 100% { -webkit-transform: rotate(359deg); } 18 | } 19 | @-o-keyframes spin { 20 | 0% { -o-transform: rotate(0deg); } 21 | 100% { -o-transform: rotate(359deg); } 22 | } 23 | @keyframes spin { 24 | 0% { 25 | -webkit-transform: rotate(0deg); 26 | transform: rotate(0deg); 27 | } 28 | 100% { 29 | -webkit-transform: rotate(359deg); 30 | transform: rotate(359deg); 31 | } 32 | } 33 | -------------------------------------------------------------------------------- /sp800-63-3/README.md: -------------------------------------------------------------------------------- 1 | # SP 800-63-3 2 | 3 | This is NIST Special Publication (SP) 800-63-3 *Digital Identity Guidelines*. This document references SP 800-63A, SP 800-63B, and SP 800-63C. 4 | 5 | The official version of this document is the PDF available at . This repository, used for development of the SP 800-63 document suite, is available as a resource for those who prefer to view the documents in HTML form or who wish to view the original Markdown. 6 | 7 | Because of differences in Markdown rendering engines, the best place to view the HTML is on the NIST Pages website at rather than the GitHub rendering of the documents. 8 | 9 | While this is believed to be a faithful representation of the official PDF documents, NIST would appreciate being informed about any inconsistencies that may be found other than minor formatting differences. These may be reported to . 10 | -------------------------------------------------------------------------------- /sp800-63c/README.md: -------------------------------------------------------------------------------- 1 | # SP 800-63C 2 | 3 | This is NIST Special Publication (SP) 800-63C, *Federation and Assertions*. This document is referenced by SP 800-63-3 covering the associated topics that had been previously in SP 800-63-2. 4 | 5 | The official version of this document is the PDF available at . This repository, used for development of the SP 800-63 document suite, is available as a resource for those who prefer to view the documents in HTML form or who wish to view the original Markdown. 6 | 7 | Because of differences in Markdown rendering engines, the best place to view the HTML is on the NIST Pages website at rather than the GitHub rendering of the documents. 8 | 9 | While this is believed to be a faithful representation of the official PDF documents, NIST would appreciate being informed about any inconsistencies that may be found other than minor formatting differences. These may be reported to . 10 | -------------------------------------------------------------------------------- /sp800-63a/README.md: -------------------------------------------------------------------------------- 1 | # SP 800-63A 2 | 3 | This is the final version of NIST Special Publication (SP) 800-63A *Enrollment and Identity Proofing*. This document is \referenced by SP 800-63-3 covering the associated topics that had been previously in SP 800-63-2. 4 | 5 | The official version of this document is the PDF available at . This repository, used for development of the SP 800-63 document suite, is available as a resource for those who prefer to view the documents in HTML form or who wish to view the original Markdown. 6 | 7 | Because of differences in Markdown rendering engines, the best place to view the HTML is on the NIST Pages website at rather than the GitHub rendering of the documents. 8 | 9 | While this is believed to be a faithful representation of the official PDF documents, NIST would appreciate being informed about any inconsistencies that may be found other than minor formatting differences. These may be reported to . -------------------------------------------------------------------------------- /sp800-63b/README.md: -------------------------------------------------------------------------------- 1 | # SP 800-63B 2 | 3 | This is NIST Special Publication (SP) 800-63B *Authentication and Lifecycle Management*. This document is referenced by SP 800-63-3 covering the associated topics that had been previously in SP 800-63-2. 4 | 5 | The official version of this document is the PDF available at . This repository, used for development of the SP 800-63 document suite, is available as a resource for those who prefer to view the documents in HTML form or who wish to view the original Markdown. 6 | 7 | Because of differences in Markdown rendering engines, the best place to view the HTML is on the NIST Pages website at rather than the GitHub rendering of the documents. 8 | 9 | While this is believed to be a faithful representation of the official PDF documents, NIST would appreciate being informed about any inconsistencies that may be found other than minor formatting differences. These may be reported to . 10 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Special Publication 800-63 *Digital Identity Guidelines* 2 | 3 | The finalized four-volume SP 800-63 *Digital Identity Guidelines* is now available, both in PDF format and online. 4 | 5 | The official versions of these documents are the PDFs available at: 6 | * 7 | * 8 | * 9 | * 10 | 11 | This repository, used for development of the SP 800-63 document suite, is available as a resource for those who prefer to view the documents in HTML form or who wish to view the original Markdown. 12 | 13 | Because of differences in Markdown rendering engines, the best place to view the HTML is on the NIST Pages website at rather than the GitHub rendering of the documents. 14 | 15 | While this is believed to be a faithful representation of the official PDF documents, NIST would appreciate being informed about any inconsistencies that may be found other than minor formatting differences. These may be reported to . 16 | -------------------------------------------------------------------------------- /sp800-63-3/errata.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 |
5 | ## Errata 6 |
7 | 8 | This table contains changes that have been incorporated into Special Publication 800-63-3. Errata updates can include corrections, clarifications, or other minor changes in the publication that are either editorial or substantive in nature. 9 | 10 | |Date|Type|Change|Location 11 | |----|----|----|----| 12 | |2017-12-01|Editorial|Removed the term 'cryptographic' from the AAL3 description.|Executive Summary| 13 | ||Editorial|Updated reference to Risk Management Framework|§5| 14 | ||Editorial|Fixed verbiage in xAL flowcharts|Figures 6-1, 6-2, and 6-3| 15 | ||Editorial|Added NISTIR 8062 as a reference|§8.1| 16 | ||Editorial|Added definitions for disassociability, manageability, processing, and predictability|Appendix A| 17 | |2020-03-02|Editorial|Fixed wording of FAL3 definition|§5.2| 18 | ||Substantive|Clarified flowcharts for xAL selection|Figures 6-1, 6-2, and 6-3| 19 | ||Substantive|Added definition for Authorization Component|Appendix A| 20 | ||Editorial|Removed extraneous definition of Protected Session|Appendix A| 21 | -------------------------------------------------------------------------------- /sp800-63c/errata.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 |
5 | ## Errata 6 |
7 | 8 | This table contains changes that have been incorporated into Special Publication 800-63C. Errata updates can include corrections, clarifications, or other minor changes in the publication that are either editorial or substantive in nature. 9 | 10 | |Date|Type|Change|Location 11 | |----|----|----|----| 12 | |2017-12-01|Editorial|Bearer assertion, signed by IdP.|§5| 13 | ||Substantive|Refined the requirements about processing of attributes|§5.2| 14 | ||Substantive|Clarified the language, incorporated privacy objectives language, and specified that consent is explicit|§9.1| 15 | ||Editorial|Added NISTIR 8062 as a reference|§12.1| 16 | |2020-03-02|Editorial|Clarified that assertions contain attributes about authentication event and subscriber|Abstract, §1, §2| 17 | ||Editorial|Refined language on transmission requirements|§4.2| 18 | ||Editorial|Removed term "authorization credential" in favor of "authorization component"|§6, §7| 19 | ||Editorial|Refined language for assertion contents|§6| 20 | ||Editorial|Removed personal pronouns|§9| 21 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | # Site settings 2 | title: SP 800-63 Digital Identity Guidelines 3 | description: "NIST Special Publication 800-63 Digital Identity Guidelines" 4 | baseurl: "/800-63-3" # the subpath of your site, e.g. /blog 5 | url: "https://pages.nist.gov/" # the base hostname & protocol for your site 6 | 7 | # Build settings 8 | markdown: kramdown 9 | 10 | exclude: 11 | - ".ruby-version" 12 | - ".jekyll-metadata" 13 | - ".gitignore" 14 | - ".travis.yml" 15 | - todo.txt 16 | - resources 17 | - Gemfile 18 | - Gemfile.lock 19 | - Makefile 20 | - vendor 21 | - README.md 22 | - CONTRIBUTING.md 23 | - LICENSE.md 24 | - docker-compose.yml 25 | - sp800-63-3/*.md 26 | - sp800-63a/*.md 27 | - sp800-63b/*.md 28 | - sp800-63c/*.md 29 | 30 | # GitHub information 31 | org_name: usnistgov 32 | repo_name: 800-63-3 33 | repository: usnistgov/800-63-3 34 | 35 | # Navigation 36 | # List links that should appear in the site sidebar here 37 | navigation: 38 | - text: Home 39 | url: /800-63-3/ 40 | - text: SP 800-63-3 41 | url: /800-63-3/sp800-63-3/ 42 | - text: SP 800-63A 43 | url: /800-63-3/sp800-63a/ 44 | - text: SP 800-63B 45 | url: /800-63-3/sp800-63b/ 46 | - text: SP 800-63C 47 | url: /800-63-3/sp800-63c/ 48 | 49 | host: 0.0.0.0 50 | -------------------------------------------------------------------------------- /_includes/sidenav.html: -------------------------------------------------------------------------------- 1 | 29 | -------------------------------------------------------------------------------- /sp800-63a/errata.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 |
5 | ## Errata 6 |
7 | 8 | This table contains changes that have been incorporated into Special Publication 800-63A. Errata updates can include corrections, clarifications, or other minor changes in the publication that are either editorial or substantive in nature. 9 | 10 | |Date|Type|Change|Location 11 | |----|----|----|----| 12 | |2017-12-01|Editorial|Made minor grammatical edits throughout the document.|N/A| 13 | ||Editorial|Changed §6 'Normative' to 'Informative'|Table 2-1| 14 | ||Substantive|Changed 'Normative' to 'Informative'|§4.1| 15 | ||Editorial|Confirmed 'Normative'|§4.2| 16 | ||Substantive|Clarified the requirements about processing of attributes|§4.2 Bullet 4 17 | ||Editorial|Remove redundant word|§4.3| 18 | ||Substantive|Clarified and removed ambiguity in requirement|§4.4| 19 | ||Substantive|Clarified requirement|§4.4.1.3| 20 | ||Substantive|Clarified and removed ambiguity in requirement|§4.4.1.6| 21 | ||Substantive|Changed the title to processing limitation; clarified the language, incorporated privacy objectives language, and specified that consent is explicit|§8.3| 22 | ||Editorial|Added NISTIR 8062 as a reference|§10.1| 23 | |2020-03-02|Editorial|Updated Type and Change of the §4.3 errata update (2017-12-01)|Errata table| 24 | ||Editorial|Updated Change in Table 2-1 errata update (2017-12-01) to specify the changed row|Errata table| 25 | ||Editorial|Removed entry for change made to §6 in the 2017-12-01 errata update since no change was made|Errata table| 26 | -------------------------------------------------------------------------------- /sp800-63-3/sec7_tofedornottofed.md: -------------------------------------------------------------------------------- 1 | 2 | 3 |
4 | 5 | ## 7 Federation Considerations 6 | 7 | _This section is informative._ 8 | 9 | This guideline and its companion volumes are agnostic to the authentication and identity proofing architecture an agency selects. However, there are scenarios an agency may encounter that make identity federation potentially more efficient and effective than establishing identity services local to the agency or individual applications. The following list details scenarios where, if any apply, the agency may consider federation a viable option. This list does not take into consideration any economic benefits or weaknesses of federation vs. localized identity architectures. 10 | 11 | Federate authenticators when: 12 | 13 | 1. Potential users already have an authenticator at or above required AAL. 14 | 2. Multiple credential form factors are required to cover all possible user communities. 15 | 3. Agency does not have infrastructure to support authentication management (e.g., account recovery, authenticator issuance, help desk). 16 | 4. There is a desire to allow primary authenticators to be added and upgraded over time without changing the RP's implementation. 17 | 5. There are different environments to be supported, as federation protocols are network-based and allow for implementation on a wide variety of platforms and languages. 18 | 6. Potential users come from multiple communities, each with its own existing identity infrastructure. 19 | 20 | Federate attributes when: 21 | 22 | 1. Pseudonymity is required, necessary, feasible, or important to stakeholders accessing the service. 23 | 2. Access to the service only requires a partial attribute list. 24 | 3. Access to the service only requires at least one attribute reference. 25 | 4. The agency is not the authoritative source or issuing source for required attributes. 26 | 5. Attributes are only required temporarily during use (such as to make an access decision), such that agency does not need to locally persist the data. 27 | -------------------------------------------------------------------------------- /sp800-63b/errata.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 |
5 | ## Errata 6 |
7 | 8 | This table contains changes that have been incorporated into Special Publication 800-63B. Errata updates can include corrections, clarifications, or other minor changes in the publication that are either editorial or substantive in nature. 9 | 10 | |Date|Type|Change|Location| 11 | |----|----|----|----| 12 | |2017-12-01|Editorial|Updated AAL descriptions for consistency with other text in document|Introduction| 13 | ||Editorial|Deleted "cryptographic" to consistently reflect authenticator options at AAL3|§4.3| 14 | ||Substantive|Refined the requirements about processing of attributes|§4.4| 15 | ||Editorial|Make language regarding activation factors for multifactor authenticators consistent|§5.1.5.1, 5.1.8.1, and 5.1.9.1| 16 | ||Substantive|Recognize use of hardware TPM as hardware crypto authenticator|§5.1.7.1, 5.1.9.1| 17 | ||Editorial|Improve normative language on authenticated protected channels for biometrics|§5.2.3| 18 | ||Editorial|Changed "transaction" to "binding transaction" to emphasize that requirement doesn't apply to authentication transactions|§6.1.1| 19 | ||Editorial|Replaced out-of-context note at end of section 7.2|§7.2| 20 | ||Editorial|Changed IdP to CSP to match terminology used elsewhere in this document|Table 8-1| 21 | ||Editorial|Corrected capitalization of Side Channel Attack|Table 8-2| 22 | ||Substantive|Changed the title to processing limitation; clarified the language, incorporated privacy objectives language, and specified that consent is explicit|§9.3| 23 | ||Editorial|Added NISTIR 8062 as a reference|§11.1| 24 | ||Editorial|Corrected title of SP 800-63C|§11.3| 25 | |2020-03-02|Substantive|Clarified wording of verifier impersonation resistance requirement|§4.3.2| 26 | ||Editorial|Emphasized use of key unlocked by additional factor to sign nonce|§5.1.9.1| 27 | ||Editorial|Provided examples of risk-based behavior observations|§5.2.2| 28 | ||Editorial|Removed redundant phrase|§5.2.3| 29 | ||Editorial|Updated URL for reference [Blacklists]|§11.1| 30 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # NIST Technical Series Publications 2 | 3 | In accordance with [Public Law 100-519, Section 107 (Oct 24, 1988)](https://www.govinfo.gov/content/pkg/STATUTE-102/pdf/STATUTE-102-Pg2589.pdf), NIST maintains a research information center to support the research, publishing, and preservation needs required to fulfill the scientific and technical mission of NIST. This includes publishing the NIST Technical Series: technical reports and Journal of Research of NIST. All works authored by NIST employees are not subject to Copyright protection within the United States; foreign rights are reserved. To the extent NIST may assert rights outside of the United States, the public is granted the non-exclusive, perpetual, paid-up, royalty-free, worldwide right to reprint works in all formats including print, electronically, and online, and in all subsequent editions, and derivative works. Please use the recommended citation format below followed by “Republished courtesy of the National Institute of Standards and Technology.” Some works published by NIST may have been written by third parties and may be subject to copyright protection. 4 | 5 | ## Citation Recommendations 6 | 7 | Journals often have their own citing formats for publications and other items included in article reference lists. NIST's data and software citation recommendations are consistent in using the same citation elements (author, title, publisher, year of publication, etc.) as used by journals. In the absence of other (e.g., journal) defined requirements, these recommendations provide a consistent manner for appropriate attribution to scientific datasets and software that are made available under NIST's public access policy. 8 | 9 | ### Recommended Format for NIST Technical Series Publications 10 | 11 | Author/editor (Publication Year), Title, Series and Publication Identifier, Publisher, Persistent Identifier (PID) or URL (Access date) 12 | 13 | #### Example: 14 | 15 | Joint Task Force Transformation Initiative Interagency Working Group (2013), Security and Privacy Controls for Federal Information Systems and Organizations, NIST Special Publication (SP) 800-53, Rev. 4, Includes updates as of January 22, 2015, National Institute of Standards and Technology, Gaithersburg, MD, https://doi.org/10.6028/NIST.SP.800-53r4 (Accessed June 21, 2018) -------------------------------------------------------------------------------- /sp800-63a/sec6_dc.md: -------------------------------------------------------------------------------- 1 | 2 | 3 |
4 | 5 | ## 6 Derived Credentials 6 | 7 | _This section is informative._ 8 | 9 | Deriving credentials is based on the process of an individual proving to a CSP that they are the rightful subject of an identity record (i.e., a credential) that is bound to one or more authenticators they possess. This process is made available by a CSP that wants individuals to have an opportunity to obtain new authenticators bound to the existing, identity proofed record, or credential. As minimizing the number of times the identity proofing process is repeated benefits the individual and CSP, deriving identity is accomplished by proving possession and successful authentication of an authenticator that is already bound to the original, proofed digital identity. 10 | 11 | The definition of derived in this section does *not* imply that an authenticator is cryptographically tied to a primary authenticator, for example deriving a key from another key. Rather, an authenticator can be derived by simply issuing on the basis of successful authentication with an authenticator that is already bound to a proofed identity, rather than unnecessarily repeating an identity proofing process. 12 | 13 | There are two specific use cases for deriving identity: 14 | 15 | 1. A _claimant_ seeks to obtain a derived PIV, bound to their identity record, for use only within the limits and authorizations of having a PIV smartcard. *This use case is covered in [SP 800-157](#SP800-157), Guidelines for Derived Personal Identity Verification (PIV) Credentials*. 16 | 2. An _applicant_ seeks to establish a credential with a CSP with which the individual does not have a pre-existing relationship. For example, an applicant wants to switch from one CSP to another, or have a separate authenticator from a new CSP for other uses (e.g., basic browsing vs. financial). *This use case is covered by allowable identity evidence in [Section 5.2](#validate).* 17 | 18 | As stated above, all requirements for PIV-derived credentials can be found in [SP 800-157](#SP800-157). For the second use case described above, this guideline does not differentiate between physical and digital identity evidence. Therefore it is acceptable, if the authenticator or an assertion generated by the primary CSP meet the requirements of [Section 5](#sec5), for them to be used at identity evidence for IAL2 and IAL3. In addition, any authenticators issued as a result of providing digital identity evidence are subject to the requirements of [SP 800-63B](sp800-63b.html). 19 | -------------------------------------------------------------------------------- /_includes/NISTPagesHeader.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 30 | 31 | {% if page.title %} 32 | {{ page.title }} 33 | 34 | {% else %} 35 | {{ site.title }} 36 | 37 | {% endif %} 38 | 39 | {% if page.description %} 40 | 41 | 42 | {% else %} 43 | 44 | 45 | {% endif %} 46 | 47 | 48 | -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: cover 3 | title: "NIST SP 800-63 Digital Identity Guidelines" 4 | description: "NIST Special Publication 800-63 Digital Identity Guidelines" 5 | --- 6 |
7 | 8 | # Digital Identity Guidelines 9 | 10 |
11 | 12 |
13 | 14 |
15 | 16 | This revision of NIST SP 800-63 has been superseded by NIST SP 800-63-4 as of August 1, 2025. Please refer to those documents for the current guidelines. 17 | 18 |
19 | 20 |
21 | 22 |
23 |
24 | 25 | The four-volume SP 800-63 *Digital Identity Guidelines* document suite is available in both PDF format and online. 26 | 27 | PDF versions of the documents are available from: 28 | 29 | | Document | Title | URL | 30 | |-----|-----|-----| 31 | | SP 800-63-3 | Digital Identity Guidelines | | 32 | | SP 800-63A | Enrollment and Identity Proofing | | 33 | | SP 800-63B | Authentication and Lifecycle Management | | 34 | | SP 800-63C | Federation and Assertions | | 35 | 36 | Links to the online version of the SP 800-63 suite are below. 37 | 38 |
    39 |
  • 40 |
    41 | SP 800-63-3 42 |
    43 |

    SP 800-63-3

    44 |
    Digital Identity Guidelines
    45 |
    • 46 |
  • 47 |
    48 | SP 800-63A 49 |
    50 |

    SP 800-63A

    51 |
    Enrollment & Identity Proofing
    52 |
    • 53 |
  • 54 |
    55 | SP 800-63B 56 |
    57 |

    SP 800-63B

    58 |
    Authentication & Lifecycle Management
    59 |
    • 60 |
  • 61 |
    62 | SP 800-63C 63 |
    64 |

    SP 800-63C

    65 |
    Federation & Assertions
    66 |
    • 67 |
68 | 69 | #### Additional informative resources: 70 | 71 | * [Frequently Asked Questions (FAQ)](https://pages.nist.gov/800-63-FAQ/) 72 | * [NIST SP 800-63-3 Implementation Resources](https://pages.nist.gov/800-63-3-Implementation-Resources/) ([PDF](https://www.nist.gov/document/sp-800-63-3-implementation-resources07012020pdf)) 73 | * Conformance Criteria for SP 800-63A *Enrollment and Identity Proofing* ([PDF](https://www.nist.gov/document/conformance-criteria-sp-800-63a-enrollment-and-identity-proofing)) 74 | * Conformance Criteria for SP 800-63B *Authentication and Lifecycle Management* ([PDF](https://www.nist.gov/document/conformance-criteria-sp-800-63b-authentication-and-lifecycle-management)) 75 | * Conformance Criteria for SP 800-63C *Federation and Assertions* ([PDF](https://www.nist.gov/document/conformance-criteria-sp-800-63c-federation-and-assertions)) 76 | 77 |
78 |
79 | -------------------------------------------------------------------------------- /comment_help.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: "Providing Feedback" 4 | description: "Guide on providing feedback" 5 | --- 6 | 7 | # Providing Feedback 8 | 9 | **Review the documentation.** No account is needed to review the updated version of NIST SP 800-63-3. Simply follow [this link](https://github.com/usnistgov/800-63-3) and enjoy at your leisure. However, if you wish to comment you must… 10 | 11 | 1. **Establish a GitHub account.** In order to submit a comment through the GitHub “Issues” feature, you will need to create a GitHub account. This can be done by proceeding to https://github.com/join. If this is a personal account, GitHub allows you to remain pseudonymous if you would like, just make sure you select the options that suit you on the “Profile” and “Emails” pages of your “Personal Settings”. We also highly encourage you to turn on two-factor authentication in the “Security” page, also part of “Personal Settings”. **For issues submitted on behalf of an organization, we prefer a generic account named for the organization, rather than a personal account from someone within the organization.** 12 | ![How to create account](assets/create_github_account.png) 13 | 14 | 2. **Open an issue.** As you are reading and identify comments you would like to make: 15 | 16 | 1. Click on either the "Comment" link in the sidebar navigation or the "Send Feedback" link in the footer of the page. 17 | 18 | 2. Review open and closed issues to determine if a similar issue has already been created. 19 | 20 | 2. Click on the "New Issue" button in the upper right of the screen. 21 | ![Create issue](assets/create_new_issue.png) 22 | 23 | 4. Provide a short description in the field labelled "Title" for the feedback being provided. 24 | ![Issue title](assets/issue_title.png) 25 | 26 | 5. Within the field labelled "Leave a comment", fill out the comment template and provide as much information as possible. 27 | 28 | **Organization Name**: 29 | 30 | **Organization Type**: 31 | 32 | **Document (63-3, 63A, 63B, or 63C)**: 33 | 34 | **Reference (Include section and paragraph number)**: 35 | 36 | **Comment (Include rationale for comment)**: 37 | 38 | **Suggested Change**: 39 | 40 | --- 41 | 42 | Organization: 1 = Federal, 2 = Industry, 3 = Academia, 4 = Self, 5 = Other 43 | 44 | 6. Hit “Submit New Issue” and you are done! 45 | ![Submit issue](assets/submit_new_issue.png) 46 | 47 | 7. If you want to keep up with others comments through email and monitor future changes, make sure you choose to “Watch” the project! 48 | ![Watch project](assets/watch_project.png) 49 | 50 | If you are familiar with GitHub you are also welcome to provide suggestions to concrete changes as a pull request (PR). We prefer PRs as follows: 51 | 52 | 1. Fork a copy of USNISTGOV/800-63-3 to your own organization/personal space. 53 | 2. Create a branch in your fork, named specifically for the edit you propose. We prefer focused PR's rather than broad-sweeping updates. 54 | 3. Issue a PR from your branch to the `post-public-comment` branch in USNISTGOV/800-63-3. 55 | 4. If we intend to merge the PR, we may engage via PR reviews and request changes before completing the merge. 56 | 57 | Please provide information about your organization and rationale for the suggested change. 58 | -------------------------------------------------------------------------------- /sp800-63a/sec7_security.md: -------------------------------------------------------------------------------- 1 | 2 | 3 |
4 | 5 | ## 7 Threats and Security Considerations 6 | 7 | _This section is informative._ 8 | 9 | There are two general categories of threats to the enrollment process: impersonation, and either compromise or malfeasance of the infrastructure provider. This section focuses on impersonation threats, as infrastructure threats are addressed by traditional computer security controls (e.g., intrusion protection, record keeping, independent audits) and are outside the scope of this document. For more information on security controls, see [SP 800-53](#SP800-53), *Recommended Security and Privacy Controls for Federal Information Systems and Organizations*. 10 | 11 | Threats to the enrollment process include impersonation attacks and threats to the transport mechanisms for identity proofing, authenticator binding, and credential issuance. [Table 7-1](#63aSec7-Table1) lists the threats related to enrollment and identity proofing. 12 | 13 | 14 | 15 |
16 | 17 | **Table 7-1 Enrollment and Identity Proofing Threats** 18 | 19 |
20 | 21 | 22 | 23 | |**Activity** | **Threat/Attack** | **Example** | 24 | |---------------|------------------------|------------------| 25 | |Enrollment | Falsified identity proofing evidence | An applicant claims an incorrect identity by using a forged driver's license.| 26 | | | Fraudulent use of another's identity | An applicant uses a passport associated with a different individual. 27 | | | Enrollment repudiation | A subscriber denies enrollment, claiming that they did not enroll with the CSP.| 28 | 29 | 30 | ### 7.1 Threat Mitigation Strategies 31 | 32 | Enrollment threats can be deterred by making impersonation more difficult to accomplish or by increasing the likelihood of detection. This recommendation deals primarily with methods for making impersonation more difficult; however, it does prescribe certain methods and procedures that may help prove who perpetrated an impersonation. At each level, methods are employed to determine that a person with the claimed identity exists, that the applicant is the person entitled to the claimed identity, and that the applicant cannot later repudiate the enrollment. As the level of assurance increases, the methods employed provide increasing resistance to casual, systematic, and insider impersonation. [Table 7-2](#63aSec7-Table2) lists strategies for mitigating threats to the enrollment and issuance processes. 33 | 34 | 35 | 36 |
37 | 38 | **Table 7-2 Enrollment and Issuance Threat Mitigation Strategies** 39 | 40 |
41 | 42 | 43 | | **Activity** | **Threat/Attack** | **Mitigation Strategy** |**Normative Reference(s)**| 44 | |--------------|-------------------|-------------------------|------------------------| 45 | | Enrollment | Falsified identity proofing evidence | CSP validates physical security features of presented evidence.|[4.4.1.3](#4-4-1-3), [4.5.3](#4-5-3), [5.2.2](#evidence_validation)| 46 | | | | CSP validates personal details in the evidence with the issuer or other authoritative source.|[4.4.1.3](#4-4-1-3), [4.5.3](#4-5-3), [4.5.6](#4-5-6) [5.2.2](#evidence_validation)| 47 | | | Fraudulent use of another's identity | CSP verifies identity evidence and biometric of applicant against information obtained from issuer or other authoritative source.|[4.4.1.7](#4-4-1-7), [4.5.7](#4-5-7), [5.3](#verify)| 48 | | | |Verify applicant-provided non-government-issued documentation (e.g., electricity bills in the name of the applicant with the current address of the applicant printed on the bill, or a credit card bill) to help achieve a higher level of confidence in the applicant's identity.|[4.4.1.7](#4-4-1-7), [4.5.7](#4-5-7), [5.3](#verify)| 49 | | | Enrollment repudiation | CSP saves a subscriber's biometric. |[4.4.1.7](#4-4-1-7), [4.5.7](#4-5-7) 50 | -------------------------------------------------------------------------------- /sp800-63c/sec1_2_introduction.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 | ## 1 Purpose 5 | 6 | *This section is informative.* 7 | 8 | This recommendation and its companion documents, [SP 800-63](sp800-63-3.html), [SP 800-63A](sp800-63a.html), and [SP 800-63B](sp800-63b.html), provide technical guidelines to credential service providers (CSPs) for the implementation of digital authentication. 9 | 10 | This document, SP 800-63C, provides requirements to identity providers (IdPs) and relying parties (RPs) of federated identity systems. Federation allows a given IdP to provide authentication attributes and (optionally) subscriber attributes to a number of separately-administered RPs through the use of assertions. Similarly, RPs may use more than one IdP. 11 | 12 |
13 | 14 | 15 | ## 2 Introduction 16 | 17 | *This section is informative.* 18 | 19 | Federation is a process that allows for the conveyance of authentication attributes and subscriber attributes across networked systems. In a federation scenario, the verifier or CSP is referred to as an identity provider, or IdP. The RP is the party that receives and uses the information provided by the IdP. 20 | 21 | Federated identity systems use assertions to accomplish this task. Assertions are statements from an IdP to an RP that contain information about a subscriber. Federation technology is generally used when the RP and the IdP are not a single entity or are not under common administration. The RP uses the information in the assertion to identify the subscriber and make authorization decisions about their access to resources controlled by the RP. An assertion typically includes an identifier for the subscriber, allowing association of the subscriber with their previous interactions with the RP. Assertions may additionally include attribute values or attribute references that further characterize the subscriber and support the authorization decision at the RP. Additional attributes may also be available outside of the assertion as part of the larger federation protocol. These attribute values and attribute references are often used in determining access privileges for Attribute Based Access Control (ABAC) or facilitating a transaction (e.g., shipping address). 22 | 23 | In a federated identity scenario, the subscriber does not authenticate directly to the RP. Instead, the federation protocol defines a mechanism for an IdP to generate an assertion for the identifier associated with a subscriber, usually in response to a request from the RP. The IdP is responsible for authenticating the subscriber (though it may use session management as described in [SP 800-63B, Section 7](sp800-63b.html#sec7)). This process allows the subscriber to obtain services from multiple RPs without the need to hold or maintain separate credentials at each. This process can also be used to support *single sign on*, where subscribers authenticate once to an IdP and subsequently obtain services from multiple RPs. 24 | 25 | Federation requires relatively complex multiparty protocols that have subtle security and privacy requirements and require careful consideration. When evaluating a particular federation structure, it may be instructive to break it down into its component interactions. Generally speaking, authentication between the subscriber and the IdP will be based on the authentication mechanisms presented in SP 800-63B, while interactions between the IdP and RP will convey attributes established using procedures in SP 800-63A and other self-asserted attributes. Many of the requirements presented in this document, therefore, have some relationship with corresponding requirements in those two documents. 26 | 27 | The following table states which sections of the document are normative and which are informative: 28 | 29 | |Section Name|Normative/Informative| 30 | |----|:--:| 31 | |1. Purpose|Informative| 32 | |2. Introduction|Informative| 33 | |3. Definitions and Abbreviations|Informative| 34 | |4. Federation Assurance Level (FAL)|Normative| 35 | |5. Federation|Normative| 36 | |6. Assertion|Normative| 37 | |7. Assertion Presentation|Normative| 38 | |8. Security|Informative| 39 | |9. Privacy Considerations|Informative| 40 | |10. Usability Considerations|Informative| 41 | |11. Examples|Informative| 42 | |12. References|Informative| 43 | -------------------------------------------------------------------------------- /sp800-63c/references.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 | ## 12 References 5 | 6 | *This section is informative.* 7 | 8 | ### 12.1 General References 9 | [FEDRAMP] General Services Administration, *Federal Risk and Authorization Management Program*, available at: . 10 | 11 | [M-03-22] OMB Memorandum M-03-22, *OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002*, September 26, 2003, available at: . 12 | 13 | [NISTIR8062] NIST Internal Report 8062, *An Introduction to Privacy Engineering and Risk Management in Federal Systems*, January 2017, available at: . 14 | 15 | [NISTIR 8112] NIST Internal Report 8112 (Draft), *Attribute Metadata*, available at: . 16 | 17 | [Section 508] Section 508 Law and Related Laws and Policies (January 30, 2017), available at: . 18 | 19 | ### 12.2 Standards 20 | [BCP 195] Sheffer, Y., Holz, R., and P. Saint-Andre, *Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)*, BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . 21 | 22 | [ISO 9241-11] International Standards Organization, ISO/IEC 9241-11 *Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability*, 1998, available at: . 23 | 24 | [OIDC] Sakimura, N., Bradley, B., Jones, M., de Medeiros, B., and C. Mortimore, *OpenID Connect Core 1.0 incorporating errata set 1*, November, 2014. Available at: . 25 | 26 | [RFC 4120] IETF, *The Kerberos Network Authentication Service (V5)*, RFC 4120, DOI 10.17487/RFC4120, July 2005, . 27 | 28 | [RFC 6113] IETF, *A Generalized Framework for Kerberos Pre-Authentication*, RFC 6113, DOI 10.17487/RFC6113, April 2011, . 29 | 30 | [RFC 7591] IETF, *OAuth 2.0 Dynamic Client Registration Protocol*, RFC 7591, DOI 10.17487/RFC7591, July 2015, . 31 | 32 | [RFC 7636] IETF, *Proof Key For Code Exchange*, RFC 7636, DOI 10.17487/RFC7636, September 2015, . 33 | 34 | [SAML] OASIS, *Security Assertion Markup Language (SAML) V2.0 Technical Overview*, March 2008, available at: . 35 | 36 | ### 12.3 NIST Special Publications 37 | NIST 800 Series Special Publications are available at: . The following publications may be of particular interest to those implementing systems of applications requiring digital authentication. 38 | 39 | [SP 800-53] NIST Special Publication 800-53 Revision 4, *Recommended Security and Privacy Controls for Federal Information Systems and Organizations*, April 2013 (updated January 22, 2015), . 40 | 41 | [SP 800-63-3] NIST Special Publication 800-63-3, *Digital Identity Guidelines*, June 2017, . 42 | 43 | [SP 800-63A] NIST Special Publication 800-63A, *Digital Identity Guidelines: Enrollment and Identity Proofing Requirements*, June 2017, . 44 | 45 | [SP 800-63B] NIST Special Publication 800-63B, *Digital Identity Guidelines: Authentication and Lifecycle Management*, June 2017, . 46 | 47 | ### 12.4 Federal Information Processing Standards 48 | 49 | [FIPS 140-2] Federal Information Processing Standard Publication 140-2, *Security Requirements for Cryptographic Modules*, May 25, 2001 (with Change Notices through December 3, 2002), . 50 | -------------------------------------------------------------------------------- /sp800-63a/sec10_references.md: -------------------------------------------------------------------------------- 1 | 2 | 3 |
4 | 5 | ## 10 References 6 | 7 | *This section is informative.* 8 | 9 | ### 10.1 General References 10 | 11 | [A-130] OMB Circular A-130, *Managing Federal Information as a Strategic Resource*, July 28, 2016, available at: . 12 | 13 | [COPPA] *Children's Online Privacy Protection Act of 1998 ("COPPA")*, 15 U.S.C. 6501-6505, 16 CFR Part 312, available at: . 14 | 15 | [EO 9397] Executive Order 9397, *Numbering System for Federal Accounts Relating to Individual Persons*, November 22, 1943, available at: . 16 | 17 | [DMF] National Technical Information Service, *Social Security Death Master File*, available at: . 18 | 19 | [E-Gov] *E-Government Act of 2002* \(includes FISMA) (P.L. 107-347), December 2002, available at: . 20 | 21 | [FBCACP] *X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA)*, Version 2.30, October 5, 2016, available at: . 22 | 23 | [FBCASUP] *FBCA Supplementary Antecedent, In-Person Definition*, July 16, 2009. 24 | 25 | [FEDRAMP] General Services Administration, *Federal Risk and Authorization Management Program*, available at: . 26 | 27 | [GPG 45] UK Cabinet Office, Good Practice Guide 45, *Identity proofing and verification of an individual*, November 3, 2014, available at: . 28 | 29 | [M-03-22] OMB Memorandum M-03-22, *OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002*, September 26, 2003, available at: . 30 | 31 | [M-04-04] OMB Memorandum M-04-04, *E-Authentication Guidance for Federal Agencies*, December 16, 2003, available at: . 32 | 33 | [NISTIR8062] NIST Internal Report 8062, *An Introduction to Privacy Engineering and Risk Management in Federal Systems*, January 2017, available at: . 34 | 35 | [Privacy Act] *Privacy Act of 1974* (P.L. 93-579), December 1974, available at: . 36 | 37 | [Red Flags Rule] 15 U.S.C. 1681m(e)(4), Pub. L. 111-319, 124 Stat. 3457, *Fair and Accurate Credit Transaction Act of 2003*, December 18, 2010, available at: . 38 | 39 | [Section 508] Section 508 Law and Related Laws and Policies (January 30, 2017), available at: . 40 | 41 | ### 10.2 Standards 42 | 43 | [Canada] Government of Canada, *Guideline on Identity Assurance*, available at: . 44 | 45 | [ISO 9241-11] International Standards Organization, ISO/IEC 9241-11 *Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability*, March 1998, available at: . 46 | 47 | ### 10.3 NIST Special Publications 48 | 49 | NIST 800 Series Special Publications are available at: . The following publications may be of particular interest to those implementing systems of applications requiring e-authentication. 50 | 51 | [SP 800-53] NIST Special Publication 800-53 Revision 4, *Recommended Security and Privacy Controls for Federal Information Systems and Organizations*, April 2013 (updated January 22, 2015), . 52 | 53 | [SP 800-63-3] NIST Special Publication 800-63-3, *Digital Identity Guidelines*, June 2017, . 54 | 55 | [SP 800-63B] NIST Special Publication 800-63B, *Digital Identity Guidelines: Authentication and Lifecycle Management*, June 2017, . 56 | 57 | [SP 800-63C] NIST Special Publication 800-63C, *Digital Identity Guidelines: Assertions and Federation*, June 2017, . 58 | 59 | [SP 800-157] NIST Special Publication 800-157, *Guidelines for Derived Personal Identity Verification (PIV) Credentials*, December 2014, . 60 | -------------------------------------------------------------------------------- /sp800-63b/sec9_privacy.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## 9 Privacy Considerations 4 | 5 | *These privacy considerations supplement the guidance in Section 4. This section is informative.* 6 | 7 | ### 9.1 Privacy Risk Assessment 8 | 9 | [Sections 4.1.5](#aal1records), [4.2.5](#aal2records), and [4.3.5](#aal3records) require the CSP to conduct a privacy risk assessment for records retention. Such a privacy risk assessment would include: 10 | 11 | 1. The likelihood that the records retention could create a problem for the subscriber, such as invasiveness or unauthorized access to the information. 12 | 2. The impact if such a problem did occur. 13 | 14 | CSPs should be able to reasonably justify any response they take to identified privacy risks, including accepting the risk, mitigating the risk, and sharing the risk. The use of subscriber consent is a form of sharing the risk, and therefore appropriate for use only when a subscriber could reasonably be expected to have the capacity to assess and accept the shared risk. 15 | 16 | ### 9.2 Privacy Controls 17 | 18 | [Section 4.4](#aal_privacy) requires CSPs to employ appropriately-tailored privacy controls. [SP 800-53](#SP800-53) provides a set of privacy controls for CSPs to consider when deploying authentication mechanisms. These controls cover notices, redress, and other important considerations for successful and trustworthy deployments. 19 | 20 | ### 9.3 Use Limitation 21 | 22 | [Section 4.4](#aal_privacy) requires CSPs to use measures to maintain the objectives of predictability (enabling reliable assumptions by individuals, owners, and operators about PII and its processing by an information system) and manageability (providing the capability for granular administration of PII, including alteration, deletion, and selective disclosure) commensurate with privacy risks that can arise from the processing of attributes for purposes other than identity proofing, authentication, authorization, or attribute assertion, related fraud mitigation, or to comply with law or legal process [NISTIR8062](#NISTIR8062). 23 | 24 | CSPs may have various business purposes for processing attributes, including providing non-identity services to subscribers. However, processing attributes for other purposes than those specified at collection can create privacy risks when individuals are not expecting or comfortable with the additional processing. CSPs can determine appropriate measures commensurate with the privacy risk arising from the additional processing. For example, absent applicable law, regulation or policy, it may not be necessary to get consent when processing attributes to provide non-identity services requested by subscribers, although notices may help subscribers maintain reliable assumptions about the processing (predictability). Other processing of attributes may carry different privacy risks that call for obtaining consent or allowing subscribers more control over the use or disclosure of specific attributes (manageability). Subscriber consent needs to be meaningful; therefore, as stated in [Section 4.4](#aal_privacy), when CSPs use consent measures, acceptance by the subscriber of additional uses SHALL NOT be a condition of providing authentication services. 25 | 26 | Consult your SAOP if there are questions about whether the proposed processing falls outside the scope of the permitted processing or the appropriate privacy risk mitigation measures. 27 | 28 | ### 9.4 Agency-Specific Privacy Compliance 29 | 30 | [Section 4.4](#aal_privacy) covers specific compliance obligations for federal CSPs. It is critical to involve your agency's SAOP in the earliest stages of digital authentication system development in order to assess and mitigate privacy risks and advise the agency on compliance requirements, such as whether or not the collection of PII to issue or maintain authenticators triggers the *Privacy Act of 1974* [Privacy Act](#PrivacyAct) or the *E-Government Act of 2002* [E-Gov](#E-Gov) requirement to conduct a PIA. For example, with respect to centralized maintenance of biometrics, it is likely that the Privacy Act requirements will be triggered and require coverage by either a new or existing Privacy Act system of records due to the collection and maintenance of PII and any other attributes necessary for authentication. The SAOP can similarly assist the agency in determining whether a PIA is required. 31 | 32 | These considerations should not be read as a requirement to develop a Privacy Act SORN or PIA for authentication alone. In many cases it will make the most sense to draft a PIA and SORN that encompasses the entire digital authentication process or include the digital authentication process as part of a larger programmatic PIA that discusses the service or benefit to which the agency is establishing online. 33 | 34 | Due to the many components of digital authentication, it is important for the SAOP to have an awareness and understanding of each individual component. For example, other privacy artifacts may be applicable to an agency offering or using federated CSP or RP services (e.g., Data Use Agreements, Computer Matching Agreements). The SAOP can assist the agency in determining what additional requirements apply. Moreover, a thorough understanding of the individual components of digital authentication will enable the SAOP to thoroughly assess and mitigate privacy risks either through compliance processes or by other means. 35 | -------------------------------------------------------------------------------- /sp800-63c/sec8_security.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## 8 Security 4 | 5 | *This section is informative.* 6 | 7 | Since the federated authentication process involves coordination between multiple components, including the CSP which now acts as an IdP, there are additional opportunities for attackers to compromise federated identity transactions. This section summarizes many of the attacks and mitigations applicable to federation. 8 | 9 | ### 8.1 Federation Threats 10 | 11 | As in non-federated authentication, attackers' motivations is typically to gain access (or a greater level of access) to a resource or service provided by an RP. Attackers may also attempt to impersonate a subscriber. Rogue or compromised IdPs, RPs, user agents (e.g., browsers), and parties outside of a typical federation transaction are potential attackers. To accomplish their attack, they might intercept or modify assertions and assertion references. Further, two or more entities may attempt to subvert federation protocols by directly compromising the integrity or confidentiality of the assertion data. For the purpose of these types of threats, any authorized parties who attempt to exceed their privileges are considered attackers. 12 | 13 | In some cases, the subscriber is issued some secret information so they can be recognized by the RP. Knowledge of this information distinguishes the subscriber from attackers who wish to impersonate them. In the case of holder-of-key assertions, this secret could have been established with the IdP prior to the initiation of the federation protocol. 14 | 15 |
16 | 17 | **Table 8-1 Federation Threats** 18 | 19 |
20 | 21 | | **Federation Threats/Attacks** | **Description** | **Examples** | 22 | |---------------------------------|------------------|--------------| 23 | | Assertion Manufacture or Modification | The attacker generates a false assertion | Compromised IdP asserts identity of a claimant who has not properly authenticated | 24 | | | The attacker modifies an existing assertion | Compromised proxy that changes AAL of an authentication assertion | 25 | | Assertion Disclosure | Assertion visible to third party | Network monitoring reveals subscriber address of record to an outside party | 26 | | Assertion Repudiation by the IdP | IdP later claims not to have signed transaction | User engages in fraudulent credit card transaction at RP, IdP claims not to have logged them in | 27 | | Assertion Repudiation by the Subscriber | Subscriber claims not to have performed transaction | User agreement (e.g., contract) cannot be enforced | 28 | | Assertion Redirect | Assertion can be used in unintended context | Compromised user agent passes assertion to attacker who uses it elsewhere | 29 | | Assertion Reuse | Assertion can be used more than once with same RP | Intercepted assertion used by attacker to authenticate their own session | 30 | | Assertion Substitution | Attacker uses an assertion intended for a different subscriber | Session hijacking attack between IdP and RP | 31 | 32 | ### 8.2 Federation Threat Mitigation Strategies 33 | 34 | Mechanisms that assist in mitigating the above threats are identified in Table 8-2. 35 | 36 |
37 | 38 | **Table 8-2 Mitigating Federation Threats** 39 | 40 |
41 | 42 | | **Federation Threat/Attack** | **Threat Mitigation Mechanisms** | **Normative Reference(s)** | 43 | |------------------------------|----------------------------------|---| 44 | | Assertion Manufacture or Modification | Cryptographically sign the assertion at IdP and verify at RP | [4.1](#key-mgmt), [6](#assertions) | 45 | | | Send assertion over an authenticated protected channel authenticating the IdP | [7.1](#back-channel), [7.2](#front-channel) | 46 | | | Include a non-guessable random identifier in the assertion | [6.2.1](#assertion-id) | 47 | | Assertion Disclosure | Send assertion over an authenticated protected channel authenticating the RP | [7.1](#back-channel), [7.2](#front-channel) | 48 | | | Encrypt assertion for a specific RP (may be accomplished by use of a mutually authenticated protected channel) | [6.2.3](#encrypted-assertion) | 49 | | 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) | 50 | | Assertion Repudiation by the Subscriber | Issue holder-of-key assertions; proof of possession of presented key verifies subscriber's participation | [6.1.2](#holderofkey) | 51 | | 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) | 52 | | Assertion Reuse | Include an issuance timestamp with short validity period in the signed content of the assertion; RP verifies validity | [6](#assertions), [7.1](#back-channel), [7.2](#front-channel) | 53 | | | RP keeps track of assertions consumed within a configurable time window to ensure that a given assertion is not used more than once. | [6.2.1](#assertion-id) | 54 | | Assertion Substitution | Ensure that assertions contain a reference to the assertion request or some other nonce that was cryptographically bound to the request by the RP | [6](#assertions) | 55 | | | Send assertions in the same authenticated protected channel as the request, such as in the back-channel model |[7.1](#back-channel)| 56 | 57 | -------------------------------------------------------------------------------- /sp800-63a/sec1_2_introduction.md: -------------------------------------------------------------------------------- 1 | 2 | 3 |
4 | 5 | ## 1 Purpose 6 | 7 | _This section is informative._ 8 | 9 | This document provides requirements for enrollment and identity proofing of applicants that wish to gain access to resources at each Identity Assurance Level (IAL). The requirements detail the acceptability, validation, and verification of identity evidence that will be presented by a subscriber to support their claim of identity. This document also details the responsibilities of Credential Service Providers (CSPs) with respect to establishing and maintaining enrollment records and binding authenticators (either CSP-issued or subscriber-provided) to the enrollment record. 10 | 11 | 12 | 13 | ## 2 Introduction 14 | 15 | _This section is informative._ 16 | 17 | One of the challenges associated with digital identity is the association of a 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., the financial industry's 'Know Your Customer' requirements, established in the implementation of the USA PATRIOT Act of 2001) or to establish accountability for high-risk actions (e.g., changing the release rate of water from a dam). 18 | 19 | There are also instances where it is desirable for a relying party (RP) to know something about a subscriber executing a transaction, but not know their real-life identity. For example, it may be desirable to only know a subscriber's home ZIP code for purposes of census-taking or petitioning an elected official. In both instances, the ZIP code is sufficient to deliver the service; it is not necessary or desirable to know the underlying identity of the person. 20 | 21 | The following table states which sections of this document are normative and which are informative: 22 | 23 | |Section Name|Normative/Informative| 24 | |----|:--:| 25 | |1. Purpose|Informative| 26 | |2. Introduction|Informative| 27 | |3. Definitions and Abbreviations|Informative| 28 | |4. Identity Assurance Level Requirements|Normative| 29 | |5. Identity Resolution, Validation, and Verification|Normative| 30 | |6. Derived Credentials|Informative| 31 | |7. Threats and Security Considerations|Informative| 32 | |8. Privacy Considerations|Informative| 33 | |9. Usability Considerations|Informative| 34 | |10. References|Informative| 35 | 36 | ## 2.1 Expected Outcomes of Identity Proofing 37 | 38 | When a subject is identity proofed, the expected outcomes are: 39 | 40 | * Resolve a claimed identity to a single, unique identity within the context of the population of users the CSP serves. 41 | * Validate that all supplied evidence is correct and genuine (e.g., not counterfeit or misappropriated). 42 | * Validate that the claimed identity exists in the real world. 43 | * Verify that the claimed identity is associated with the real person supplying the identity evidence. 44 | 45 | ## 2.2 Identity Assurance Levels 46 | 47 | Assurance in a subscriber's identity is described using one of three IALs: 48 | 49 | **IAL1**: There is no requirement to link the applicant to a specific real-life identity. Any attributes provided in conjunction with the subject's activities are self-asserted or should be treated as self-asserted (including attributes a CSP asserts to an RP). Self-asserted attributes are neither validated nor verified. 50 | 51 | **IAL2**: Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL2 introduces the need for either remote or physically-present identity proofing. Attributes could be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes. A CSP that supports IAL2 can support IAL1 transactions if the user consents. 52 | 53 | **IAL3**: Physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained CSP representative. As with IAL2, attributes could be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes. A CSP that supports IAL3 can support IAL1 and IAL2 identity attributes if the user consents. 54 | 55 | At IAL2 and IAL3, pseudonymity in federated environments is enabled by limiting the number of attributes sent from the CSP to the RP, or the way they are presented. For example, if a RP needs a valid birthdate but no other personal details, the RP should leverage a CSP to request just the birthdate of the subscriber. Wherever possible, the RP should ask the CSP for an attribute reference. For example, if a RP needs to know if a claimant is older than 18 they should request a boolean value, not the entire birthdate, to evaluate age. Conversely, it may be beneficial to the user that uses a high assurance CSP for transactions at lower assurance levels. For example, a user may maintain an IAL3 identity, yet should be able to use their CSP for IAL2 and IAL1 transactions. 56 | 57 | Since the individual will have undergone an identity proofing process at enrollment, transactions with respect to individual interactions with the CSP may not necessarily be pseudonymous. 58 | 59 | Detailed requirements for each of the IALs are given in [Section 4](#ial-section) and [Section 5](#ipv-section). 60 | -------------------------------------------------------------------------------- /sp800-63b/sec1_2_introduction.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## 1 Purpose 4 | 5 | _This section is informative._ 6 | 7 | This document and its companion documents, [Special Publication (SP) 800-63](sp800-63-3.html), [SP 800-63A](sp800-63a.html), and [SP 800-63C](sp800-63c.html), provide technical guidelines to agencies for the implementation of digital authentication. 8 | 9 | 10 | 11 | ## 2 Introduction 12 | 13 | _This section is informative._ 14 | 15 | Digital identity is the unique representation of a subject engaged in an online transaction. A digital identity is always unique in the context of a digital service, but does not necessarily need to be traceable back to a specific real-life subject. In other words, accessing a digital service may not mean that the underlying subject's real-life representation is known. Identity proofing establishes that a subject is actually who they claim to be. Digital authentication is the process of determining the validity of one or more authenticators used to claim a digital identity. Authentication establishes that a subject attempting to access a digital service is in control of the technologies used to authenticate. For services in which return visits are applicable, successfully authenticating provides reasonable risk-based assurances that the subject accessing the service today is the same as the one who accessed the service previously. Digital identity presents a technical challenge because it often involves the proofing of individuals over an open network and always involves the authentication of individuals over an open network. This presents multiple opportunities for impersonation and other attacks which can lead to fraudulent claims of a subject's digital identity. 16 | 17 | The ongoing authentication of subscribers is central to the process of associating a subscriber with their online activity. Subscriber authentication is performed by verifying that the claimant controls one or more *authenticators* (called *tokens* in earlier versions of SP 800-63) associated with a given subscriber. A successful authentication results in the assertion of an identifier, either pseudonymous or non-pseudonymous, and optionally other identity information, to the relying party (RP). 18 | 19 | This document provides recommendations on types of authentication processes, including choices of authenticators, that may be used at various *Authenticator Assurance Levels* (AALs). It also provides recommendations on the lifecycle of authenticators, including revocation in the event of loss or theft. 20 | 21 | This technical guideline applies to digital authentication of subjects to systems over a network. It does not address the authentication of a person for physical access (e.g., to a building), though some credentials used for digital access may also be used for physical access authentication. This technical guideline also requires that federal systems and service providers participating in authentication protocols be authenticated to subscribers. 22 | 23 | The strength of an authentication transaction is characterized by an ordinal measurement known as the AAL. Stronger authentication (a higher AAL) requires malicious actors to have better capabilities and expend greater resources in order to successfully subvert the authentication process. Authentication at higher AALs can effectively reduce the risk of attacks. A high-level summary of the technical requirements for each of the AALs is provided below; see [Sections 4](#sec4) and [5](#sec5) of this document for specific normative requirements. 24 | 25 | **Authenticator Assurance Level 1**: AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber's account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol. 26 | 27 | **Authenticator Assurance Level 2**: AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber's account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above. 28 | 29 | **Authenticator Assurance Level 3**: AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber's account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication requires a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device may fulfill both these requirements. In order to authenticate at AAL3, claimants are required to prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required. 30 | 31 | The following table states which sections of the document are normative and which are informative: 32 | 33 | |Section Name|Normative/Informative| 34 | |----|:--:| 35 | |1. Purpose|Informative| 36 | |2. Introduction|Informative| 37 | |3. Definitions and Abbreviations|Informative| 38 | |4. Authenticator Assurance Levels|Normative| 39 | |5. Authenticator and Verifier Requirements|Normative| 40 | |6. Authenticator Lifecycle Management|Normative| 41 | |7. Session Management|Normative| 42 | |8. Threat and Security Considerations|Informative| 43 | |9. Privacy Considerations|Informative| 44 | |10. Usability Considerations|Informative| 45 | |11. References|Informative| 46 | |Appendix A — Strength of Memorized Secrets|Informative| 47 | -------------------------------------------------------------------------------- /static/css/NISTPages.css: -------------------------------------------------------------------------------- 1 | .nist { 2 | margin: 0; 3 | padding: 0; 4 | } 5 | .nist-header { 6 | box-sizing: border-box; 7 | background: #000; 8 | color: #fff; 9 | padding: 10px 20px 4px; 10 | font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; 11 | position: relative; 12 | margin-bottom: 0px; 13 | } 14 | .nist-header:after { 15 | content: ""; 16 | display: table; 17 | clear: both; 18 | } 19 | .nist-header * { 20 | box-sizing: inherit; 21 | } 22 | .nist-header a, .nist-header a:link, .nist-header a:visited { 23 | color: #EEE; 24 | text-decoration: none; 25 | } 26 | .nist-header h1 { 27 | margin: 0 10px 0 0; 28 | float: left; 29 | font-size: 0; 30 | } 31 | .nist-header h1 a { 32 | font-weight: normal; 33 | font-size: 20px; 34 | height: 40px; 35 | width: 280px; 36 | background: url('nist_logo.png') no-repeat; 37 | background-size: 280px auto; 38 | text-indent: -9999px; 39 | overflow: hidden; 40 | display: inline-block; 41 | } 42 | .nist-header-text { 43 | position: absolute; 44 | left: -9999px; 45 | background: yellow; 46 | } 47 | .nist-links { 48 | float: right; 49 | } 50 | a.nist-links-button { 51 | display: inline-block; 52 | padding: 6px; 53 | margin: 0 2px; 54 | border-radius: 3px; 55 | border: 1px solid #666; 56 | font-size: 14px; 57 | } 58 | .nist-header a.nist-links-button:hover, 59 | .nist-header a.nist-links-button:focus { 60 | background: #ccc; 61 | color: #333; 62 | } 63 | 64 | /* Custom styling */ 65 | 66 | section.home { 67 | text-align: left; 68 | } 69 | 70 | section.home ul, section.home ol { 71 | text-align: left; 72 | } 73 | 74 | ul.audiences li { 75 | text-align: center; 76 | } 77 | 78 | .navbar-fixed-left { 79 | width: 160px; 80 | position: fixed; 81 | border-radius: 0; 82 | height: calc(100% - 56px); /*56px for the header*/ 83 | overflow-y: scroll; 84 | } 85 | 86 | .navbar-fixed-left .navbar-nav > li { 87 | float: none; /* Cancel default li float: left */ 88 | width: 139px; 89 | } 90 | 91 | .container { 92 | padding-left: 160px; 93 | } 94 | 95 | .nist-header + .container { 96 | padding-left: 15px; 97 | } 98 | 99 | /* On using dropdown menu (To right shift popuped) */ 100 | .navbar-fixed-left .navbar-nav > li > .dropdown-menu { 101 | margin-top: -50px; 102 | margin-left: 100px; 103 | } 104 | 105 | .nav>li>a.icon { 106 | display: inline-block; 107 | } 108 | 109 | .nav>li>a.icon.icon-fa { 110 | padding: 0; 111 | } 112 | 113 | .navbar-fixed-left .navbar-nav .subnav { 114 | font-size: smaller; 115 | line-height: 1.1em; 116 | } 117 | 118 | .navbar-fixed-left .navbar-nav .subnav>li { 119 | list-style: none; 120 | padding-bottom: 4px; 121 | } 122 | 123 | .navbar-fixed-left .navbar-nav .subnav>li.active { 124 | font-weight: bold; 125 | list-style: disc; 126 | } 127 | 128 | .navbar-fixed-left .navbar-nav .subnav a { 129 | color: black; 130 | } 131 | 132 | /* Style default/base tables since we are using markdown */ 133 | table{ 134 | width:100%; 135 | margin-bottom:20px 136 | } 137 | 138 | table>thead>tr>th,table>tbody>tr>th,table>tfoot>tr>th,table>thead>tr>td,table>tbody>tr>td,table>tfoot>tr>td{ 139 | padding:8px; 140 | line-height:1.42857143; 141 | vertical-align:top; 142 | border:1px solid #ddd 143 | } 144 | 145 | table>thead>tr>th{ 146 | vertical-align:bottom; 147 | border-bottom:2px solid #ddd; 148 | } 149 | 150 | table>caption+thead>tr:first-child>th,table>colgroup+thead>tr:first-child>th,table>thead:first-child>tr:first-child>th,table>caption+thead>tr:first-child>td,table>colgroup+thead>tr:first-child>td,table>thead:first-child>tr:first-child>td{ 151 | border-top:1px solid #ddd; 152 | } 153 | 154 | table>tbody+tbody{ 155 | border-top:2px solid #ddd 156 | } 157 | 158 | table table{ 159 | background-color:#fff 160 | } 161 | 162 | table.authors{ 163 | border:hidden; 164 | } 165 | 166 | table.authors td{ 167 | border:hidden; 168 | } 169 | 170 | 171 | 172 | @media screen and (max-width: 767px) { 173 | .nist-header { 174 | padding: 6px 10px; 175 | } 176 | .nist-header h1 a { 177 | height: 26px; 178 | width: 80px; 179 | background: url('nist_logo_mark.png') 0 4px no-repeat; 180 | background-size: 80px auto; 181 | } 182 | .mobile-hide { 183 | display: none !important; 184 | } 185 | 186 | .navbar-fixed-left { 187 | width: 100%; 188 | position: static; 189 | height: auto; 190 | } 191 | 192 | .navbar-nav { 193 | margin: 0; 194 | } 195 | 196 | .navbar-fixed-left .navbar-nav > li { 197 | float: left; 198 | width: auto; 199 | font-size: smaller; 200 | border-right: 1px #555555 solid; 201 | border-bottom: 1px #333333 solid; 202 | margin: 2px; 203 | padding: 2px; 204 | border-radius: 4px; 205 | } 206 | 207 | .navbar-fixed-left .navbar-nav > li.active { 208 | background-color: #e7e7e7; 209 | width: 100%; 210 | margin: 0; 211 | border: 0; 212 | border-radius: 0; 213 | } 214 | 215 | .navbar-fixed-left .navbar-nav > li.active > a, 216 | .navbar-fixed-left .navbar-nav .subnav > li.active > a { 217 | font-weight: bold; 218 | } 219 | 220 | .navbar-fixed-left .navbar-nav > li > a, 221 | .navbar-fixed-left .navbar-nav .subnav > li > a { 222 | margin: 2px; 223 | padding: 2px; 224 | font-weight: normal; 225 | } 226 | 227 | .navbar-fixed-left .navbar-nav .subnav { 228 | padding: 0; 229 | } 230 | 231 | .navbar-fixed-left .navbar-nav .subnav>li { 232 | float: left; 233 | width: auto; 234 | margin: 2px; 235 | padding: 2px; 236 | border-radius: 4px; 237 | background-color: #f8f8f8; 238 | } 239 | 240 | .navbar-fixed-left .navbar-nav .subnav>li > a { 241 | font-size: larger; /* this undoes the "font-size: smaller" in the normal-width render */ 242 | } 243 | 244 | .navbar-fixed-left .navbar-nav .subnav>li.active { 245 | font-weight: bold; 246 | list-style: none; 247 | background-color: #d6d6d6; 248 | } 249 | 250 | .navbar-fixed-left .navbar-nav .subnav>li.active a { 251 | background-color: #d6d6d6; 252 | } 253 | 254 | .container { 255 | padding-left: 5px; 256 | padding-right: 5px; 257 | } 258 | 259 | .row { 260 | margin-right: 0px; 261 | margin-left: 0px; 262 | } 263 | 264 | img { 265 | max-width: 100% !important; 266 | max-height: auto !important; 267 | min-width: auto !important; 268 | min-height: auto !important; 269 | width: auto !important; 270 | height: auto !important; 271 | } 272 | 273 | a { 274 | word-break: break-all; 275 | text-overflow: ellipsis; 276 | } 277 | 278 | } 279 | 280 | -------------------------------------------------------------------------------- /sp800-63-3/sec8_references.md: -------------------------------------------------------------------------------- 1 | ## 8 References 2 | 3 | *This section is informative.* 4 | 5 | ### 8.1 General References 6 | 7 | [A-130] OMB Circular A-130, *Managing Federal Information as a Strategic Resource*, July 28, 2016, available at: . 8 | 9 | [eIDAS] European Union, *REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL*, July 23, 2014, available at: . 10 | 11 | [EO 13681] Executive Order 13681, *Improving the Security of Consumer Financial Transactions*, October 17, 2014, available at: . 12 | 13 | [ESIG] Federal CIO Council, *Use of Electronic Signatures in Federal Organization Transactions*, January 25, 2013, 14 | available at: . 15 | 16 | [FISMA] *Federal Information Security Modernization Act of 2014*, available at: . 17 | 18 | [GPG 44] UK Cabinet Office, Good Practice Guide 44, *Authentication and Credentials for use with HMG Online Services*, August 8, 2016, available at: . 19 | 20 | [GPG 45] UK Cabinet Office, Good Practice Guide 45, *Identity proofing and verification of an individual*, November 3, 2014, available at: . 21 | 22 | [HSPD-12] Department of Homeland Security, *Homeland Security Presidential Directive 12: Policy for a Common Identification Standard for Federal Employees and Contractors*, August 27, 2004, available at: . 23 | 24 | [M-03-22] OMB Memorandum M-03-22, *OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002*, September 26, 2003, available at: . 25 | 26 | [M-04-04] OMB Memorandum M-04-04, *E-Authentication Guidance for Federal Agencies*, December 16, 2003, available at: . 27 | 28 | [NSTIC] *National Strategy for Trusted Identities in Cyberspace*, April 2011, available at: . 29 | 30 | [NISTIR8062] NIST Internal Report 8062, *An Introduction to Privacy Engineering and Risk Management in Federal Systems*, January 2017, available at: . 31 | 32 | [NIST RMF] Risk Management Framework Overview, available at . 33 | 34 | [RSDOPS] UK Cabinet Office, Good Practice Guide 43, *Requirements for Secure Delivery of Online Public Services (RSDOPS)*, November 3, 2014, available at: . 35 | 36 | [Steiner] Steiner, Peter. "On the Internet, nobody knows you're a dog", *The New Yorker*, July 5, 1993. 37 | 38 | [STORK 2.0] European Union, *Secure idenTity acrOss boRders linKed 2.0*, 2014, available at: . 39 | 40 | ### 8.2 Standards 41 | 42 | [BCP 195] Sheffer, Y., Holz, R., and P. Saint-Andre, *Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)*, BCP 195, RFC 7525,DOI 10.17487/RFC7525, May 2015, . 43 | 44 | [Canada] Government of Canada, *Standard on Identity and Credential Assurance*, February 1, 2013, available at: . 45 | 46 | [ISO 9241-11] International Standards Organization, ISO/IEC 9241-11 *Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability*, March 1998, available at: . 47 | 48 | [ISO 29003] International Standards Organization, ISO/IEC DTS 29003 *Information technology — Security techniques — Identity proofing*. 49 | 50 | [ISO 29115] International Standards Organization, ISO/IEC 29115 *Information technology — Security techniques — Entity authentication assurance framework*, April 1, 2013, available at: . 51 | 52 | [OIDC] Sakimura, N., Bradley, B., Jones, M., de Medeiros, B., and C. Mortimore, *OpenID Connect Core 1.0 incorporating errata set 1*, November, 2014, available at: . 53 | 54 | ### 8.3 NIST Special Publications 55 | NIST 800 Series Special Publications are available at: . The following publications may be of particular interest to those implementing systems of applications requiring digital authentication. 56 | 57 | [SP 800-30] NIST Special Publication 800-30 Revision 1, *Guide for Conducting Risk Assessments*, September 2012, . 58 | 59 | [SP 800-37] NIST Special Publication 800-37 Revision 1, *Guide for Applying the Risk Management Framework to Federal Information Systems, A Security Life Cycle Approach*, February 2010 (updated June 5, 2014), . 60 | 61 | [SP 800-52] NIST Special Publication 800-52 Revision 1, *Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, April 2014, . 62 | 63 | [SP 800-53A] NIST Special Publication 800-53A Revision 4, *Assessing Security and Privacy Controls in Federal Information Systems and Organizations, Building Effective Assessment Plans*, December 2014 (updated December 18, 2014), . 64 | 65 | ### 8.4 Federal Information Processing Standards 66 | 67 | [FIPS 199] Federal Information Processing Standard 199, *Standards for Security Categorization of Federal Information and Information Systems*, February 2004, . 68 | 69 | [FIPS 201] Federal Information Processing Standard Publication 201-2, *Personal Identity Verification (PIV) of Federal Employees and Contractors*, August 2013, . 70 | -------------------------------------------------------------------------------- /sp800-63b/appA_memorized.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## Appendix A—Strength of Memorized Secrets 4 | 5 | *This appendix is informative.* 6 | 7 | Throughout this appendix, the word "password" is used for ease of discussion. Where used, it should be interpreted to include passphrases and PINs as well as passwords. 8 | 9 | ### A.1 Introduction 10 | 11 | Despite widespread frustration with the use of passwords from both a usability and security standpoint, they remain a very widely used form of authentication [[Persistence]](#persistence). Humans, however, have only a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed. To address the resultant security concerns, online services have introduced rules in an effort to increase the complexity of these memorized secrets. The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought [[Policies]](#policies), although the impact on usability and memorability is severe. 12 | 13 | Complexity of user-chosen passwords has often been characterized using the information theory concept of entropy [[Shannon]](#shannon). While entropy can be readily calculated for data having deterministic distribution functions, estimating the entropy for user-chosen passwords is difficult and past efforts to do so have not been particularly accurate. For this reason, a different and somewhat simpler approach, based primarily on password length, is presented herein. 14 | 15 | Many attacks associated with the use of passwords are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy, complex passwords as simple ones. These attacks are outside the scope of this Appendix. 16 | 17 | ### A.2 Length 18 | 19 | Password length has been found to be a primary factor in characterizing password strength [[Strength]](#strength) [[Composition]](#composition). Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords. 20 | 21 | The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted. In order to prevent an attacker (or a persistent claimant with poor typing skills) from easily inflicting a denial-of-service attack on the subscriber by making many incorrect guesses, passwords need to be complex enough that rate limiting does not occur after a modest number of erroneous attempts, but does occur before there is a significant chance of a successful guess. 22 | 23 | Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users' passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks. 24 | 25 | Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit. 26 | 27 | ### A.3 Complexity 28 | 29 | As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [[Policies]](#policies). For example, a user that might have chosen "password" as their password would be relatively likely to choose "Password1" if required to include an uppercase letter and a number, or "Password1!" if a symbol is also required. 30 | 31 | Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases. Spaces themselves, however, add little to the complexity of passwords and may introduce usability issues (e.g., the undetected use of two spaces rather than one), so it may be beneficial to remove repeated spaces in typed passwords prior to verification. 32 | 33 | Users' password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the "Password1!" example above. For this reason, it is recommended that passwords chosen by users be compared against a "black list" of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement. 34 | 35 | Highly complex memorized secrets introduce a new potential vulnerability: they are less likely to be memorable, and it is more likely that they will be written down or stored electronically in an unsafe manner. While these practices are not necessarily vulnerable, statistically some methods of recording such secrets will be. This is an additional motivation not to require excessively long or complex memorized secrets. 36 | 37 | ### A.4 Randomly-Chosen Secrets 38 | 39 | Another factor that determines the strength of memorized secrets is the process by which they are generated. Secrets that are randomly chosen (in most cases by the verifier or CSP) and are uniformly distributed will be more difficult to guess or brute-force attack than user-chosen secrets meeting the same length and complexity requirements. Accordingly, at LOA2, SP 800-63-2 permitted the use of randomly generated PINs with 6 or more digits while requiring user-chosen memorized secrets to be a minimum of 8 characters long. 40 | 41 | As discussed above, the threat model being addressed with memorized secret length requirements includes rate-limited online attacks, but not offline attacks. With this limitation, 6 digit randomly-generated PINs are still considered adequate for memorized secrets. 42 | 43 | ### A.5 Summary 44 | 45 | Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blacklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed. 46 | -------------------------------------------------------------------------------- /sp800-63c/sec4_fal.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## 4 Federation Assurance Level (FAL) 4 | 5 | *This section is normative.* 6 | 7 | This section defines allowable Federation Assurance Levels, or FAL. The FAL describes requirements for how assertions are constructed and secured for a given transaction. These levels can be requested by an RP or required by the configuration of both the RP and the IdP for a given transaction. 8 | 9 | All assertions SHALL be used with a federation protocol as described in [Section 4](#federation). All assertions SHALL comply with the detailed requirements in [Section 6](#assertions). All assertions SHALL be presented using one of the methods described in [Section 7](#presentation). While many different federation implementation options are possible, the FAL is intended to provide clear implementation recommendations representing increasingly secure deployment options. Combinations of aspects not found in the FAL table are possible but outside the scope of this volume. See [SP 800-63 Section 6.3](sp800-63-3.html#FAL_CYOA) for details on how to choose the most appropriate FAL. 10 | 11 | This table presents different requirements for each FAL. Each successive level subsumes and fulfills all requirements of lower levels. Federations presented through a proxy SHALL be represented by the lowest level used during the proxied transaction. 12 | 13 | 14 | 15 |
16 | 17 | 18 | **Table 4-1 Federation Assertion Levels** 19 | 20 |
21 | 22 | |FAL|Requirement| 23 | |:--:|----|----| 24 | |1|Bearer assertion, signed by IdP.| 25 | |2|Bearer assertion, signed by IdP and encrypted to RP.| 26 | |3|Holder of key assertion, signed by IdP and encrypted to RP.| 27 | 28 | For example, FAL1 maps to the OpenID Connect Basic Client profile or Security Assertion Markup Language (SAML) Web SSO Artifact Binding profile with no additional features. FAL2 additionally requires that the assertion (e.g., the OpenID Connect ID Token or SAML Assertion) be encrypted to a public key representing the RP in question. FAL3 requires the subscriber to cryptographically prove possession of a key bound to the assertion (e.g., the use of a cryptographic authenticator) along with all requirements of FAL2. The additional key presented at FAL3 need not be the same key used by the subscriber to authenticate to the IdP. 29 | 30 | Regardless of what the RP requests or what the protocol requires, the RP can easily detect the FAL in use by observing the nature of the assertion as it is presented as part of the federation protocol. Therefore, the RP is responsible for determining which FALs it is willing to accept for a given authentication transaction and ensuring that the transaction meets that FAL's requirements. 31 | 32 | If the RP is using a front-channel presentation mechanism, as defined in [Section 7.2](#front-channel) (e.g., the OpenID Connect Implicit Client profile or the SAML Web SSO profile), it SHALL require FAL2 or greater in order to protect the information in the assertion from disclosure to the browser or other parties in the transaction other than the intended RP. 33 | 34 | Additionally, the IdP SHALL employ appropriately-tailored security controls (to include control enhancements) from the moderate or high baseline of security controls defined in [SP 800-53](#SP800-53) or equivalent federal (e.g., [FEDRAMP](#FEDRAMP)) or industry standard. 35 | 36 | ### 4.1 Key Management 37 | 38 | At any FAL, the IdP SHALL ensure that an RP is unable to impersonate the IdP at another RP by protecting the assertion with a signature and key using approved cryptography. If the assertion is protected by a digital signature using an asymmetric key, the IdP MAY use the same public and private key pair to sign assertions to multiple RPs. The IdP MAY publish its public key in a verifiable fashion, such as at an HTTPS-protected URL at a well-known location. If the assertion is protected by a MAC using a shared key, the IdP SHALL use a different shared key for each RP. 39 | 40 | Government-operated IdPs asserting authentication at AAL2 and all IdPs asserting authentication at AAL3 SHALL protect keys used for signing or encrypting those assertions with mechanisms validated at [FIPS 140](#FIPS140) Level 1 or higher. 41 | 42 | ### 4.2 Runtime Decisions 43 | 44 | The fact that parties have federated SHALL NOT be interpreted as permission to pass information. The decision of whether an authentication can occur or attributes may be passed can be determined by the use of a whitelist, a blacklist, or a runtime decision by an authorized party. 45 | 46 | IdPs MAY establish whitelists of RPs authorized to receive authentication and attributes from the IdP without a runtime decision from the subscriber. All RPs in an IdP's whitelist SHALL abide by the provisions and requirements in the SP 800-63 suite. IdPs SHALL make whitelists available to subscribers as described in [Section 9.2](#notice). IdPs MAY also establish blacklists of RPs not authorized to receive authentication or attributes from the IdP, even when requested by the subscriber. Both whitelists and blacklists identify RPs by their domain or other sufficiently unique identifier, depending on the federation protocol in use. Every RP not on a whitelist or a blacklist SHALL be placed by default in a gray area where runtime authorization decisions will be made by an authorized party, usually the subscriber. The IdP MAY remember a subscriber's decision to authorize a given RP, provided that the IdP SHALL allow the subscriber to revoke such remembered access at a future time. 47 | 48 | RPs MAY establish whitelists of IdPs that the RP will accept authentication and attributes from without a runtime decision from the subscriber. All IdPs in an RP's whitelist SHALL abide by the provisions and requirements in the 800-63 suite. RPs MAY also establish blacklists of IdPs that the RP will not accept authentication or attributes from, even when requested by the subscriber. Both whitelists and blacklists identify IdPs by their domain or other sufficiently unique identifier, depending on the federation protocol in use. Every IdP that is not on a whitelist or a blacklist SHALL be placed by default in a gray area where runtime authorization decisions will be made by an authorized party, usually the subscriber. The RP MAY remember a subscriber's decision to authorize a given IdP, provided that the RP SHALL allow the subscriber to revoke such remembered access at a future time. 49 | 50 | A subscriber's information SHALL be transmitted between IdP and RP only for identity federation transactions or support functions such as identification of compromised accounts as discussed in [Section 5.2](#privacy-reqs). A subscriber's information SHALL NOT be transmitted for any other purposes, even when those parties are whitelisted. 51 | 52 | To mitigate the risk of unauthorized exposure of sensitive information (e.g., shoulder surfing), the IdP SHALL, by default, mask sensitive information displayed to the subscriber. The IdP SHALL provide mechanisms for the subscriber to temporarily unmask such information in order for the subscriber to view full values. The IdP SHALL provide effective mechanisms for redress of applicant complaints or problems (e.g., subscriber identifies an inaccurate attribute value). For more details on masking and redress, please see [Section 10](#usability) on usability considerations. 53 | 54 | When the subscriber is involved in a runtime decision, the subscriber SHALL receive explicit notice and be able to provide positive confirmation before any attributes about the subscriber are transmitted to any RP. At a minimum, the notice SHOULD be provided by the party in the position to provide the most effective notice and obtain confirmation, consistent with [Section 9.2](#notice). If the protocol in use allows for optional attributes, the subscriber SHALL be given the option to decide whether to transmit those attributes to the RP. An IdP MAY employ mechanisms to remember and re-transmit the exact attribute bundle to the same RP. 55 | -------------------------------------------------------------------------------- /sp800-63c/sec11_examples.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 | ## 11 Examples 5 | 6 | *This section is informative.* 7 | 8 | Three types of assertion technologies are discussed below: SAML assertions, Kerberos tickets, and OpenID Connect tokens. This list is not inclusive of all possible assertion technologies, but does represent those commonly used in federated identity systems. 9 | 10 | ### 11.1 Security Assertion Markup Language (SAML) 11 | 12 | SAML is an XML-based framework for creating and exchanging authentication and attribute information between trusted entities over the internet. As of this writing, the latest specification for [SAML](#SAML) is SAML v2.0, issued 15 March 2005. 13 | 14 | The building blocks of SAML include: 15 | 16 | - The Assertions XML schema, which defines the structure of the assertion. 17 | - The SAML Protocols, which are used to request assertions and artifacts (the assertion references used in the indirect model described in [Section 7.1](#back-channel)). 18 | - The Bindings, which define the underlying communication protocols (such as HTTP or SOAP), and can be used to transport the SAML assertions. 19 | 20 | The three components above define a SAML profile that corresponds to a particular use case such as "Web Browser SSO". 21 | 22 | SAML Assertions are encoded in an XML schema and can carry up to three types of statements: 23 | 24 | - *Authentication statements* include information about the assertion issuer, the authenticated subscriber, validity period, and other authentication information. For example, an Authentication Assertion would state the subscriber "John" was authenticated using a password at 10:32pm on 06-06-2004. 25 | 26 | - *Attribute statements* contain specific additional characteristics related to the subscriber. For example, subject "John" is associated with attribute "Role" with value "Manager". 27 | 28 | - *Authorization statements* identify the resources the subscriber has permission to access. These resources may include specific devices, files, and information on specific web servers. For example, subject "John" for action "Read" on "Webserver1002" given evidence "Role". 29 | 30 | Authorization statements are beyond the scope of this document and will not be discussed. 31 | 32 | ### 11.2 Kerberos Tickets 33 | 34 | The Kerberos Network Authentication Service [[RFC 4120]](#RFC4120) was designed to provide strong authentication for client/server applications using symmetric-key cryptography on a local, shared network. Extensions to Kerberos can support the use of public key cryptography for selected steps of the protocol. Kerberos also supports confidentiality and integrity protection of session data between the subscriber and the RP. Even though Kerberos uses assertions, it was designed for use on shared networks and, therefore, is not truly a federation protocol. 35 | 36 | Kerberos supports authentication of a subscriber over an untrusted, shared local network using one or more IdPs. The subscriber implicitly authenticates to the IdP by demonstrating the ability to decrypt a random session key encrypted for the subscriber by the IdP. (Some Kerberos variants also require the subscriber to explicitly authenticate to the IdP, but this is not universal.) In addition to the encrypted session key, the IdP also generates another encrypted object called a Kerberos ticket. The ticket contains the same session key, the identity of the subscriber to whom the session key was issued, and an expiration time after which the session key is no longer valid. The ticket is confidentiality and integrity protected by a pre-established key that is shared between the IdP and the RP during an explicit setup phase. 37 | 38 | To authenticate using the session key, the subscriber sends the ticket to the RP along with encrypted data that proves that the subscriber possesses the session key embedded within the Kerberos ticket. Session keys are either used to generate new tickets or to encrypt and authenticate communications between the subscriber and the RP. 39 | 40 | To begin the process, the subscriber sends an authentication request to the Authentication Server (AS). The AS encrypts a session key for the subscriber using the subscriber's long-term credential. The long-term credential may either be a secret key shared between the AS and the subscriber, or in the PKINIT variant of Kerberos, a public key certificate. Most variants of Kerberos based on a shared secret key between the subscriber and IdP derive this key from a user-generated password. As such, they are vulnerable to offline dictionary attacks by passive eavesdroppers, unless Flexible Authentication Secure Tunneling (FAST) \[[RFC 6113](#RFC6113)\] or some other tunneling and armoring mechanism is used. 41 | 42 | In addition to delivering the session key to the subscriber, the AS also issues a ticket using a key it shares with the Ticket Granting Server (TGS). This ticket is referred to as a Ticket Granting Ticket (TGT), since the verifier uses the session key in the TGT to issue tickets rather than to explicitly authenticate the verifier. The TGS uses the session key in the TGT to encrypt a new session key for the subscriber and uses a key it shares with the RP to generate a ticket corresponding to the new session key. The subscriber decrypts the session key and uses the ticket and the new session key together to authenticate to the RP. 43 | 44 | When Kerberos authentication is based on passwords, the protocol is known to be vulnerable to offline dictionary attacks by eavesdroppers who capture the initial user-to-KDC exchange. Longer password length and complexity provide some mitigation to this vulnerability, although sufficiently long passwords tend to be cumbersome for users. However, when Kerberos password-based authentication is used in a FAST (or similar) tunnel, a successful Man-in-the-Middle attack is additionally required in order to perform the dictionary attack. 45 | 46 | ### 11.3 OpenID Connect 47 | 48 | OpenID Connect \[[OIDC](#OIDC)\] is an internet-scale federated identity and authentication protocol built on top of the OAuth 2.0 authorization framework and the JSON Object Signing and Encryption (JOSE) cryptographic system. 49 | 50 | OpenID Connect builds on top of the OAuth 2.0 authorization protocol to enable the subscriber to authorize the RP to access the subscriber's identity and authentication information. The RP in both OpenID Connect and OAuth 2.0 is known as the client. 51 | 52 | In a successful OpenID Connect transaction, the IdP issues an ID Token, which is a signed assertion in JSON Web Token (JWT) format. The client parses the ID Token to learn about the subscriber and primary authentication event at the IdP. This token contains at minimum the following information about the subscriber and authentication event: 53 | 54 | - `iss` - An HTTPS URL identifying the IdP that issued the assertion. 55 | - `sub` - An IdP-specific subject identifier representing the subscriber. 56 | - `aud` - An IdP-specific audience identifier, equal to the OAuth 2.0 client identifier of the client at the IdP. 57 | - `exp` - The timestamp at which the ID Token expires and after which SHALL NOT be accepted the client. 58 | - `iat` - The timestamp at which the ID Token was issued and before which SHALL NOT be accepted by the client. 59 | 60 | In addition to the ID Token, the IdP also issues the client an OAuth 2.0 access token which can be used to access the UserInfo Endpoint at the IdP. This endpoint returns a JSON object representing a set of attributes about the subscriber, including but not limited to their name, email address, physical address, phone number, and other profile information. While the information inside the ID Token is reflective of the authentication event, the information in the UserInfo Endpoint is generally more stable and could be more general purpose. Access to different attributes from the UserInfo Endpoint is governed by the use of a specially-defined set of OAuth scopes, `openid`, `profile`, `email`, `phone`, and `address`. An additional scope, `offline_access`, is used to govern the issuance of refresh tokens, which allow the RP to access the UserInfo Endpoint when the subscriber is not present. Access to the UserInfo Endpoint is structured as an API and may be available when the subscriber is not present. Therefore, access to the UserInfo Endpoint is not sufficient for proving a subscriber's presence and establishing an authenticated session at the RP. 61 | -------------------------------------------------------------------------------- /sp800-63b/sec7_session.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## 7 Session Management 4 | 5 | _This section is normative._ 6 | 7 | Once an authentication event has taken place, it is often desirable to allow the subscriber to continue using the application across multiple subsequent interactions without requiring them to repeat the authentication event. This requirement is particularly true for federation scenarios — described in [SP 800-63C](sp800-63c.html) — where the authentication event necessarily involves several components and parties coordinating across a network. 8 | 9 | To facilitate this behavior, a *session* MAY be started in response to an authentication event, and continue the session until such time that it is terminated. The session MAY be terminated for any number of reasons, including but not limited to an inactivity timeout, an explicit logout event, or other means. The session MAY be continued through a reauthentication event — described in [Section 7.2](#sessionreauthn) — wherein the user repeats some or all of the initial authentication event, thereby re-establishing the session. 10 | 11 | Session management is preferable over continual presentation of credentials as the poor usability of continual presentation often creates incentives for workarounds such as cached unlocking credentials, negating the freshness of the authentication event. 12 | 13 | ### 7.1 Session Bindings 14 | 15 | A session occurs between the software that a subscriber is running — such as a browser, application, or operating system (i.e., the session subject) — and the RP or CSP that the subscriber is accessing (i.e., the session host). A session secret SHALL be shared between the subscriber's software and the service being accessed. This secret binds the two ends of the session, allowing the subscriber to continue using the service over time. The secret SHALL be presented directly by the subscriber's software or possession of the secret SHALL be proven using a cryptographic mechanism. 16 | 17 | The secret used for session binding SHALL be generated by the session host in direct response to an authentication event. A session SHOULD inherit the AAL properties of the authentication event which triggered its creation. A session MAY be considered at a lower AAL than the authentication event but SHALL NOT be considered at a higher AAL than the authentication event. 18 | 19 | Secrets used for session binding: 20 | 21 | 1. SHALL be generated by the session host during an interaction, typically immediately following authentication. 22 | 2. SHALL be generated by an approved random bit generator [[SP 800-90Ar1]](#SP800-90Ar1) and contain at least 64 bits of entropy. 23 | 3. SHALL be erased or invalidated by the session subject when the subscriber logs out. 24 | 4. SHOULD be erased on the subscriber endpoint when the user logs out or when the secret is deemed to have expired. 25 | 5. SHOULD NOT be placed in insecure locations such as HTML5 Local Storage due to the potential exposure of local storage to cross-site scripting (XSS) attacks. 26 | 6. SHALL be sent to and received from the device using an authenticated protected channel. 27 | 7. SHALL time out and not be accepted after the times specified in [Sections 4.1.4](#aal1reauth), [4.2.4](#aal2reauth), and [4.3.4](#aal3reauth), as appropriate for the AAL. 28 | 8. SHALL NOT be available to insecure communications between the host and subscriber's endpoint. Authenticated sessions SHALL NOT fall back to an insecure transport, such as from https to http, following authentication. 29 | 30 | URLs or POST content SHALL contain a session identifier that SHALL be verified by the RP to ensure that actions taken outside the session do not affect the protected session. 31 | 32 | There are several mechanisms for managing a session over time. The following sections give different examples along with additional requirements and considerations particular to each example technology. Additional informative guidance is available in the OWASP *Session Management Cheat Sheet* [[OWASP-session]](#OWASP-session). 33 | 34 | #### 7.1.1 Browser Cookies 35 | 36 | Browser cookies are the predominant mechanism by which a session will be created and tracked for a subscriber accessing a service. 37 | 38 | Cookies: 39 | 40 | 1. SHALL be tagged to be accessible only on secure (HTTPS) sessions. 41 | 2. SHALL be accessible to the minimum practical set of hostnames and paths. 42 | 3. SHOULD be tagged to be inaccessible via JavaScript (HttpOnly). 43 | 4. SHOULD be tagged to expire at, or soon after, the session's validity period. This requirement is intended to limit the accumulation of cookies, but SHALL NOT be depended upon to enforce session timeouts. 44 | 45 | #### 7.1.2 Access Tokens 46 | 47 | An access token — such as found in OAuth — is used to allow an application to access a set of services on a subscriber's behalf following an authentication event. The presence of an OAuth access token SHALL NOT be interpreted by the RP as presence of the subscriber, in the absence of other signals. The OAuth access token, and any associated refresh tokens, MAY be valid long after the authentication session has ended and the subscriber has left the application. 48 | 49 | #### 7.1.3 Device Identification 50 | 51 | Other methods of secure device identification — including but not limited to mutual TLS, token binding, or other mechanisms — MAY be used to enact a session between a subscriber and a service. 52 | 53 | ### 7.2 Reauthentication 54 | 55 | Continuity of authenticated sessions SHALL be based upon the possession of a session secret issued by the verifier at the time of authentication and optionally refreshed during the session. The nature of a session depends on the application, including: 56 | 57 | 1. A web browser session with a "session" cookie, or 58 | 2. An instance of a mobile application that retains a session secret. 59 | 60 | Session secrets SHALL be non-persistent. That is, they SHALL NOT be retained across a restart of the associated application or a reboot of the host device. 61 | 62 | Periodic reauthentication of sessions SHALL be performed to confirm the continued presence of the subscriber at an authenticated session (i.e., that the subscriber has not walked away without logging out). 63 | 64 | A session SHALL NOT be extended past the guidelines in Sections [4.1.3](#aal1reauth), [4.2.3](#aal2reauth), and [4.3.3](#aal3reauth) (depending on AAL) based on presentation of the session secret alone. Prior to session expiration, the reauthentication time limit SHALL be extended by prompting the subscriber for the authentication factor(s) specified in [Table 7-1](#63bSec7-Table1). 65 | 66 | When a session has been terminated, due to a time-out or other action, the user SHALL be required to establish a new session by authenticating again. 67 | 68 | 69 | 70 |
71 | 72 | **Table 7-1 AAL Reauthentication Requirements** 73 | 74 |
75 | 76 | 77 | |AAL|Requirement| 78 | |----|----| 79 | |1|Presentation of any one factor| 80 | |2|Presentation of a memorized secret or biometric| 81 | |3|Presentation of all factors| 82 | 83 | >Note: At AAL2, a memorized secret or biometric, and not a physical authenticator, is required because the session secret is *something you have*, and an additional authentication factor is required to continue the session. 84 | 85 | #### 7.2.1 Reauthentication from a Federation or Assertion 86 | 87 | When using a federation protocol as described in [SP 800-63C](sp800-63c.html), Section 5 to connect the CSP and RP, special considerations apply to session management and reauthentication. The federation protocol communicates an authentication event between the CSP and the RP but establishes no session between them. Since the CSP and RP often employ separate session management technologies, there SHALL NOT be any assumption of correlation between these sessions. Consequently, when an RP session expires and the RP requires reauthentication, it is entirely possible that the session at the CSP has not expired and that a new assertion could be generated from this session at the CSP without reauthenticating the user. 88 | 89 | An RP requiring reauthentication through a federation protocol SHALL — if possible within the protocol — specify the maximum acceptable authentication age to the CSP, and the CSP SHALL reauthenticate the subscriber if they have not been authenticated within that time period. The CSP SHALL communicate the authentication event time to the RP to allow the RP to decide if the assertion is sufficient for reauthentication and to determine the time for the next reauthentication event. 90 | -------------------------------------------------------------------------------- /sp800-63c/sec7_presentation.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## 7 Assertion Presentation 4 | 5 | *This section is normative.* 6 | 7 | Assertions MAY be presented in either a *back-channel* or *front-channel* manner from the IdP to the RP. There are tradeoffs with each model, but each requires the proper validation of the assertion. Assertions MAY also be proxied to facilitate federation between IdPs and RPs under specific circumstances, as discussed in [Section 5.1.4](#proxied). 8 | 9 | The IdP SHALL transmit only those attributes that were explicitly requested by the RP. RPs SHALL conduct a privacy risk assessment when determining which attributes to request. 10 | 11 | ### 7.1 Back-Channel Presentation 12 | 13 | In the *back-channel* model, the subscriber is given an assertion reference to present to the RP, generally through the front channel. The assertion reference itself contains no information about the subscriber and SHALL be resistant to tampering and fabrication by an attacker. The RP presents the assertion reference to the IdP, usually along with authentication of the RP itself, to fetch the assertion. 14 | 15 | 16 | 17 |
18 | Back-channel Presentation 19 | 20 | **Figure 7-1 Back Channel Presentation** 21 | 22 |
23 | 24 | As shown in [Figure 7-1](#63cSec7-Figure1), the back-channel presentation model consists of three steps: 25 | 26 | 1. The IdP sends an assertion reference to the subscriber through the front channel. 27 | 2. The subscriber sends the assertion reference to the RP through the front channel. 28 | 3. The RP presents the assertion reference and its RP credentials to the IdP through the back channel. The IdP validates the credentials and returns the assertion. 29 | 30 | The assertion reference: 31 | 32 | 1. SHALL be limited to use by a single RP. 33 | 2. SHALL be single-use. 34 | 3. SHOULD be time limited with a short lifetime of seconds or minutes. 35 | 4. SHOULD be presented along with authentication of the RP. 36 | 37 | In this model, the RP directly requests the assertion from the IdP, minimizing chances of interception and manipulation by a third party (including the subscriber themselves). 38 | 39 | This method also allows the RP to query the IdP for additional attributes about the subscriber not included in the assertion itself, since back-channel communication can continue to occur after the initial authentication transaction has been completed without sending the user back to the IdP. This query occurs using an authorization component issued alongside the assertion, as described in [Section 6](#assertions). 40 | 41 | More network transactions are required in the back-channel method, but the information is limited to only those parties that need it. Since an RP is expecting to get an assertion only from the IdP directly, the attack surface is reduced. Consequently, it is more difficult to inject assertions directly into the RP. 42 | 43 | The RP SHALL protect itself against injection of manufactured or captured assertion references by use of cross-site scripting protection or other accepted techniques. 44 | 45 | Elements within the assertion SHALL be validated by the RP, including: 46 | 47 | - *Issuer verification*: ensuring the assertion was issued by the IdP the RP expects it to be from. 48 | - *Signature validation*: ensuring the signature of the assertion corresponds to the key related to the IdP sending the assertion. 49 | - *Time validation*: ensuring the expiration and issue times are within acceptable limits of the current timestamp. 50 | - *Audience restriction*: ensuring this RP is the intended recipient of the assertion. 51 | 52 | Conveyance of the assertion reference from the IdP to the subscriber, as well as from the subscriber to the RP, SHALL be made over an authenticated protected channel. Conveyance of the assertion reference from the RP to the IdP, as well as the assertion from the IdP to the RP, SHALL be made over an authenticated protected channel. 53 | 54 | When assertion references are presented, the IdP SHALL verify that the party presenting the assertion reference is the same party that requested the authentication. The IdP can do this by requiring the RP to authenticate itself when presenting the assertion reference to the IdP or through other similar means (see [RFC 7636](#RFC7636) for one protocol's method of RP identification). 55 | 56 | Note that in a federation proxy described in [Section 5.1.4](#proxied), the IdP audience restricts the assertion reference and assertion to the proxy, and the proxy restricts any newly-created assertion references or assertions to the downstream RP. 57 | 58 | ### 7.2 Front-Channel Presentation 59 | 60 | In the *front-channel* model, the IdP creates an assertion and sends it to the subscriber after successful authentication. The assertion is used by the subscriber to authenticate to the RP, often through mechanisms within the subscriber's browser. 61 | 62 | 63 | 64 | 65 |
66 | Front-channel Presentation 67 | 68 | **Figure 7-2 Front Channel Presentation** 69 | 70 |
71 | 72 | An assertion is visible to the subscriber in the front-channel method, which could potentially cause leakage of system information included in the assertion. Further, it is more difficult in this model for the RP to query the IdP for additional attributes after the presentation of the assertion. 73 | 74 | Since the assertion is under the subscriber's control, the front-channel presentation method also allows the subscriber to submit a single assertion to unintended parties, perhaps by a browser replaying an assertion at multiple RPs. Even if the assertion is audience-restricted and rejected by unintended RPs, its presentation at unintended RPs could lead to leaking information about the subscriber and their online activities. Though it is possible to intentionally create an assertion designed to be presented to multiple RPs, this method can lead to lax audience restriction of the assertion itself, which in turn could lead to privacy and security breaches for the subscriber across these RPs. Such multi-RP use is not recommended. Instead, RPs are encouraged to fetch their own individual assertions. 75 | 76 | The RP SHALL protect itself against injection of manufactured or captured assertions by use of cross-site scripting protection or other accepted techniques. 77 | 78 | Elements within the assertion SHALL be validated by the RP including: 79 | 80 | - *Issuer verification*: ensuring the assertion was issued by the expected IdP. 81 | - *Signature validation*: ensuring the signature of the assertion corresponds to the key related to the IdP making the assertion. 82 | - *Time validation*: ensuring the expiration and issue times are within acceptable limits of the current timestamp. 83 | - *Audience restriction*: ensuring this RP is the intended recipient of the assertion. 84 | 85 | Conveyance of the assertion from the IdP to the subscriber, as well as from the subscriber to the RP, SHALL be made over an authenticated protected channel. 86 | 87 | Note that in a federation proxy described in [Section 5.1.4](#proxied), the IdP audience restricts the assertion to the proxy, and the proxy restricts any newly-created assertions to the downstream RP. 88 | 89 | ### 7.3 Protecting Information 90 | 91 | Communications between the IdP and the RP SHALL be protected in transit using an authenticated protected channel. Communications between the subscriber and either the IdP or the RP (usually through a browser) SHALL be made using an authenticated protected channel. 92 | 93 | Note that the IdP may have access to information that may be useful to the RP in enforcing security policies, such as device identity, location, system health checks, and configuration management. If so, it may be a good idea to pass this information along to the RP within the bounds of the subscriber's privacy preferences described in [Section 9.2](#notice). 94 | 95 | Additional attributes about the user MAY be included outside of the assertion itself as part of a separate authorized request from the RP to the IdP. The authorization for access to these attributes MAY be issued alongside the assertion itself. Splitting user information in this manner can aid in protecting user privacy and allow for limited disclosure of identifying attributes on top of the essential information in the authentication assertion itself. 96 | 97 | The RP SHALL, where feasible, request attribute references rather than full attribute values as described in [Section 9.3](#minimization). The IdP SHALL support attribute references. 98 | 99 | -------------------------------------------------------------------------------- /sp800-63a/sec8_privacy.md: -------------------------------------------------------------------------------- 1 | 2 | 3 |
4 | 5 | ## 8 Privacy Considerations 6 | 7 | _This section is informative._ 8 | 9 | These privacy considerations provide information regarding the General Requirements set forth in [Section 4.2](#genProofReqs). 10 | 11 | ### 8.1 Collection and Data Minimization 12 | 13 | [Section 4.2 requirement 2](#4.2-r2) permits the collection of only the PII necessary to validate the existence of the claimed identity and associate the claimed identity to the applicant, based on best available practices for appropriate identity resolution, validation, and verification. Collecting unnecessary PII can create confusion regarding why information not being used for the identity proofing service is being collected. This leads to invasiveness or overreach concerns, which can lead to loss of applicant trust. Further, PII retention can become vulnerable to unauthorized access or use. Data minimization reduces the amount of PII vulnerable to unauthorized access or use, and encourages trust in the identity proofing process. 14 | 15 | #### 8.1.1 Social Security Numbers 16 | 17 | [Section 4.2 requirement 13](#4.2-r13) does not permit the CSP to collect the SSN unless it is necessary for performing identity resolution, when resolution cannot be accomplished by collection of another attribute or combination of attributes. Overreliance on the SSN can contribute to misuse and place the applicant at risk of harm, such as through identity theft. Nonetheless, the SSN may achieve identity resolution for RPs in particular federal agencies that use SSNs to correlate a subscriber to existing records. Thus, this document recognizes the role of the SSN as an identifier and makes appropriate allowance for its use. 18 | > Note: Evidence requirements at the higher IALs preclude using the SSN or the Social Security Card as acceptable identity evidence. 19 | 20 | Prior to collecting the SSN for identity proofing, organizations need to consider any legal obligation to collect the SSN, the necessity of using the SSN for interoperability with third party processes and systems, or operational requirements. Operational requirements can be demonstrated by an inability to alter systems, processes, or forms due to cost or unacceptable levels of risk. Operational necessity is not justified by ease of use or unwillingness to change. 21 | 22 | For federal agencies, the initial requirement in [Executive Order (EO) 9397] (#9397) to use the SSN as a primary means of identification for individuals working for, with, or conducting business with their agency, has since been eliminated. Accordingly, EO 9397 cannot be referenced as the sole authority establishing the collection of the SSN as necessary. 23 | 24 | Federal agencies need to review any decision to collect the SSN relative to their obligation to reduce the collection and unnecessary use of SSNs under Office of Management and Budget policy. 25 | 26 | ### 8.2 Notice and Consent 27 | 28 | [Section 4.2 requirement 3](4.2-r3) requires the CSP provide explicit notice to the applicant at the time of collection regarding the purpose for collecting and maintaining a record of the attributes necessary for identity proofing, including whether such attributes are voluntary or mandatory in order to complete the identity proofing transactions, and the consequences for not providing the attributes. 29 | 30 | An effective notice will take into account user experience design standards and research, and an assessment of privacy risks that may arise from the collection. Various factors should be considered, including incorrectly inferring that applicants understand why attributes are collected, that collected information may be combined with other data sources, etc. An effective notice is never only a pointer leading to a complex, legalistic privacy policy or general terms and conditions that applicants are unlikely to read or understand. 31 | 32 | ### 8.3 Use Limitation 33 | 34 | [Section 4.2 requirement 4](#4.2-r4) requires CSPs to use measures to maintain the objectives of predictability (enabling reliable assumptions by individuals, owners, and operators about PII and its processing by an information system) and manageability (providing the capability for granular administration of PII, including alteration, deletion, and selective disclosure) commensurate with privacy risks that can arise from the processing of attributes for purposes other than identity proofing, authentication, authorization, or attribute assertion, related fraud mitigation, or to comply with law or legal process [NISTIR8062]](#NISTIR8062). 35 | 36 | CSPs may have various business purposes for processing attributes, including providing non-identity services to subscribers. However, processing attributes for other purposes than those specified at collection can create privacy risks when individuals are not expecting or comfortable with the additional processing. CSPs can determine appropriate measures commensurate with the privacy risk arising from the additional processing. For example, absent applicable law, regulation or policy, it may not be necessary to get consent when processing attributes to provide non-identity services requested by subscribers, although notices may help subscribers maintain reliable assumptions about the processing (predictability). Other processing of attributes may carry different privacy risks that call for obtaining consent or allowing subscribers more control over the use or disclosure of specific attributes (manageability). Subscriber consent needs to be meaningful; therefore, when CSPs do use consent measures, they cannot make acceptance by the subscriber of additional uses a condition of providing the identity service. 37 | 38 | Consult your SAOP if there are questions about whether the proposed processing falls outside the scope of the permitted processing or the appropriate privacy risk mitigation measures. 39 | 40 | ### 8.4. Redress 41 | 42 | [Section 4.2 requirement 5](#4.2-r5) requires the CSP to provide effective mechanisms for redressing applicant complaints or problems arising from the identity proofing, and make the mechanisms easy for applicants to find and access. 43 | 44 | The Privacy Act requires federal CSPs that maintain a system of records to follow procedures to enable applicants to access and, if incorrect, amend their records. Any Privacy Act Statement should include a reference to the applicable SORN(s), which provide the applicant with instructions on how to make a request for access or correction. Non-federal CSPs should have comparable procedures, including contact information for any third parties if they are the source of the information. 45 | 46 | CSPs should make the availability of alternative methods for completing the process clear to users (e.g., in person at a customer service center, if available) in the event an applicant is unable to establish their identity and complete the registration process online. 47 | 48 | > Note: If the ID proofing process is not successful, CSPs should inform the applicant of the procedures to address the issue but should not inform the applicant of the specifics of why the registration failed (e.g., do not inform the applicant, "Your SSN did not match the one that we have on record for you"), as doing so could allow fraudulent applicants to gain more knowledge about the accuracy of the PII. 49 | 50 | 51 | ### 8.5 Privacy Risk Assessment 52 | 53 | [Section 4.2 requirement 7](#4.2-r7) and [10](#4.2-r13) require the CSP to conduct a privacy risk assessment. In conducting a privacy risk assessment, CSPs should consider: 54 | 55 | 1. The likelihood that the action it takes (e.g., additional verification steps or records retention) could create a problem for the applicant, such as invasiveness or unauthorized access to the information; and 56 | 2. The impact if a problem did occur. CSPs should be able to justify any response it takes to identified privacy risks, including accepting the risk, mitigating the risk, and sharing the risk. The use of applicant consent should be considered a form of sharing the risk, and therefore should only be used when an applicant could reasonably be expected to have the capacity to assess and accept the shared risk. 57 | 58 | ### 8.6 Agency Specific Privacy Compliance 59 | 60 | [Section 4.2 requirement 12](#4.2-r12) covers specific compliance obligations for federal CSPs. It is critical to involve your agency's SAOP in the earliest stages of digital authentication system development to assess and mitigate privacy risks and advise the agency on compliance requirements, such as whether or not the PII collection to conduct identity proofing triggers the Privacy Act of 1974 [[Privacy Act]](#PrivacyAct) or the E-Government Act of 2002 [[E-Gov]](#E-Gov) requirement to conduct a Privacy Impact Assessment. For example, with respect to identity proofing, it is likely that the Privacy Act requirements will be triggered and require coverage by either a new or existing Privacy Act system of records due to the collection and maintenance of PII or other attributes necessary to conduct identity proofing. 61 | 62 | The SAOP can similarly assist the agency in determining whether a PIA is required. These considerations should not be read as a requirement to develop a Privacy Act SORN or PIA for identity proofing alone; in many cases it will make the most sense to draft a PIA and SORN that encompasses the entire digital authentication process or include the digital authentication process as part of a larger programmatic PIA that discusses the program or benefit the agency is establishing online access to. 63 | 64 | Due to the many components of digital authentication, it is important for the SAOP to have an awareness and understanding of each individual component. For example, other privacy artifacts may be applicable to an agency offering or using proofing services such as Data Use Agreements, Computer Matching Agreements, etc. The SAOP can assist the agency in determining what additional requirements apply. Moreover, a thorough understanding of the individual components of digital authentication will enable the SAOP to thoroughly assess and mitigate privacy risks either through compliance processes or by other means. 65 | -------------------------------------------------------------------------------- /sp800-63a/cover.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | # NIST Special Publication 800-63A 4 | 5 | ![](sp800-63-3/media/div-1.png) 6 | 7 | # Digital Identity Guidelines 8 | 9 | ### _Enrollment and Identity Proofing Requirements_ 10 | 11 | ![](sp800-63-3/media/div-2.png) 12 | 13 | Paul A. Grassi 14 | James L. Fenton 15 | 16 | **Privacy Authors:** 17 | Naomi B. Lefkovitz 18 | Jamie M. Danker 19 | 20 | **Usability Authors:** 21 | Yee-Yin Choong 22 | Kristen K. Greene 23 | Mary F. Theofanos 24 | 25 | This publication is available free of charge from: 26 | https://doi.org/10.6028/NIST.SP.800-63a 27 | 28 | ![](sp800-63-3/media/csd.png) 29 | ![](sp800-63-3/media/nist_logo.png) 30 | 31 |
32 | 33 | # NIST Special Publication 800-63A 34 | 35 | # Digital Identity Guidelines 36 | 37 | ### Enrollment and Identity Proofing Requirements 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 |
Paul A. Grassi
Applied Cybersecurity Division
Information Technology Laboratory		James L. Fenton
Altmode Networks
Los Altos, Calif.
Privacy Authors:
Naomi B. Lefkovitz
Applied Cybersecurity Division
Information Technology Laboratory

Jamie M. Danker
National Protection and Programs Directorate
Department of Homeland Security		Usability Authors:
Yee-Yin Choong
Kristen K. Greene
Information Access Division
Information Technology Laboratory

Mary F. Theofanos
Office of Data and Informatics
Material Measurement Laboratory
49 | 50 | 51 | This publication is available free of charge from: 52 | https://doi.org/10.6028/NIST.SP.800-63a 53 | 54 | 55 | June 2017 56 | Includes [updates](#errata) as of 03-02-2020 57 | 58 | ![](sp800-63-3/media/commerce_logo.png) 59 | 60 | U.S. Department of Commerce 61 | *Wilbur L. Ross, Jr., Secretary* 62 | 63 | National Institute of Standards and Technology 64 | *Kent Rochford, Acting NIST Director and Under Secretary of Commerce for Standards and 65 | Technology* 66 | 67 |
68 | 69 |
70 | 71 |
72 | 73 | ### Authority 74 | 75 |
76 | 77 | This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. 78 | 79 | Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST. 80 | 81 |
82 | 83 | National Institute of Standards and Technology Special Publication 800-63-3 84 | Natl. Inst. Stand. Technol. Spec. Publ. 800-63A, 45 pages (June 2017) 85 | CODEN: NSPUE2 86 | 87 | 88 | 89 | This publication is available free of charge from: 90 | https://doi.org/10.6028/NIST.SP.800-63a 91 | 92 |
93 | 94 |
95 | >Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. 96 |

97 | >There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST. 98 |

99 | >Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at [http://csrc.nist.gov/publications/](http://csrc.nist.gov/publications/). 100 |
101 | 102 |
103 | 104 | **Comments on this publication may be submitted to:** 105 | 106 | National Institute of Standards and Technology 107 | Attn: Applied Cybersecurity Division, Information Technology Laboratory 108 | 100 Bureau Drive (Mail Stop 2000) Gaithersburg, MD 20899-2000 109 | Email: 110 | 111 | All comments are subject to release under the Freedom of Information Act (FOIA). 112 |
113 | 114 |
115 | 116 | ### Reports on Computer Systems Technology 117 | 118 |
119 | 120 | The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation's measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL's responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL's research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations. 121 | 122 |
123 | 124 | ### Abstract 125 | 126 |
127 | 128 | These guidelines provide technical requirements for federal agencies implementing digital identity services and are not intended to constrain the development or use of standards outside of this purpose. This guideline focuses on the enrollment and verification of an identity for use in digital authentication. Central to this is a process known as *identity proofing* in which an applicant provides evidence to a credential service provider (CSP) reliably identifying themselves, thereby allowing the CSP to assert that identification at a useful identity assurance level. This document defines technical requirements for each of three identity assurance levels. This publication supersedes corresponding sections of NIST Special Publication (SP) 800-63-2. 129 | 130 |
131 | 132 | ### Keywords 133 | 134 |
135 | 136 | authentication; credential service provider; electronic authentication; digital authentication; electronic credentials; digital credentials; identity proofing; federation. 137 | 138 |
139 | 140 | ### Acknowledgements 141 | 142 |
143 | 144 | The authors would like to acknowledge the contributions and guidance of our international peers, including Adam Cooper, Alastair Treharne, and Julian White from the Cabinet Office, United Kingdom, and Tim Bouma from the Treasury Board of Canada Secretariat, Government of Canada, Kaitlin Boeckl for her artistic contributions to all volumes in the SP 800-63 suite, and the contributions of our many reviewers, including Joni Brennan from the Digital ID & Authentication Council of Canada (DIACC), Ben Piccarreta and Ellen Nadeau from NIST, and Danna Gabel O'Rourke from Deloitte & Touche LLP. In addition, special thanks to the Federal Privacy Council's Digital Authentication Task Force for the contributions to the development of privacy requirements and considerations. 145 | 146 | The authors would also like to acknowledge the thought leadership and innovation of the original authors: Donna F. Dodson, Elaine M. Newton, Ray A. Perlner, W. Timothy Polk, Sarbari Gupta, and Emad A. Nabbus. Without their tireless efforts, we would not have had the incredible baseline from which to evolve 800-63 to the document it is today. 147 | 148 |
149 | 150 | ### Requirements Notation and Conventions 151 | 152 |
153 | 154 | The terms "SHALL" and "SHALL NOT" indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted. 155 | 156 | The terms "SHOULD" and "SHOULD NOT" indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited. 157 | 158 | The terms "MAY" and "NEED NOT" indicate a course of action permissible within the limits of the publication. 159 | 160 | The terms "CAN" and "CANNOT" indicate a possibility and capability, whether material, physical or causal or, in the negative, the absence of that possibility or capability. 161 | 162 |
163 | 164 |
165 | ## Table of Contents 166 |
167 | 168 | [1. Purpose](#sec1) 169 | 170 | [2. Introduction](#sec2) 171 | 172 | [3. Definitions and Abbreviations](#sec3) 173 | 174 | [4. Identity Assurance Level Requirements](#sec4) 175 | 176 | [5. Identity Resolution, Validation and Verification](#sec5) 177 | 178 | [6. Derived Credentials](#sec6) 179 | 180 | [7. Threats and Security Considerations](#sec7) 181 | 182 | [8. Privacy Considerations](#sec8) 183 | 184 | [9. Usability Considerations](#sec9) 185 | 186 | [10. References](#references) 187 | -------------------------------------------------------------------------------- /sp800-63c/cover.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | # NIST Special Publication 800-63C 4 | 5 | ![](sp800-63-3/media/div-1.png) 6 | 7 | # Digital Identity Guidelines 8 | 9 | ### _Federation and Assertions_ 10 | 11 | ![](sp800-63-3/media/div-2.png) 12 | 13 | Paul A. Grassi 14 | Justin P. Richer 15 | Sarah K. Squire 16 | James L. Fenton 17 | Ellen M. Nadeau 18 | 19 | **Privacy Authors:** 20 | Naomi B. Lefkovitz 21 | Jamie M. Danker 22 | 23 | **Usability Authors:** 24 | Yee-Yin Choong 25 | Kristen K. Greene 26 | Mary F. Theofanos 27 | 28 | This publication is available free of charge from: 29 | https://doi.org/10.6028/NIST.SP.800-63c 30 | 31 | ![](sp800-63-3/media/csd.png) 32 | ![](sp800-63-3/media/nist_logo.png) 33 | 34 |
35 | 36 | # NIST Special Publication 800-63C 37 | 38 | # Digital Identity Guidelines 39 | 40 | ### Federation and Assertions 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 50 | 51 | 52 | 53 | 54 | 55 | 56 |
Paul A. Grassi
Ellen M. Nadeau
Applied Cybersecurity Division
Information Technology Laboratory		James L. Fenton
Altmode Networks
Los Altos, Calif.
49 | Justin P. Richer
Sarah K. Squire
Bespoke Engineering
Billerica, Mass.		 
Privacy Authors:
Naomi B. Lefkovitz
Applied Cybersecurity Division
Information Technology Laboratory

Jamie M. Danker
National Protection and Programs Directorate
Department of Homeland Security		Usability Authors:
Yee-Yin Choong
Kristen K. Greene
Information Access Division
Information Technology Laboratory

Mary F. Theofanos
Office of Data and Informatics
Material Measurement Laboratory
57 | 58 | This publication is available free of charge from: 59 | https://doi.org/10.6028/NIST.SP.800-63c 60 | 61 | 62 | June 2017 63 | Includes [updates](#errata) as of 03-02-2020 64 | 65 | ![](sp800-63-3/media/commerce_logo.png) 66 | 67 | U.S. Department of Commerce 68 | *Wilbur L. Ross, Jr., Secretary* 69 | 70 | National Institute of Standards and Technology 71 | *Kent Rochford, Acting NIST Director and Under Secretary of Commerce for Standards and 72 | Technology* 73 | 74 |
75 | 76 |
77 | 78 | ### Authority 79 | 80 |
81 | 82 | This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. 83 | 84 | Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST. 85 | 86 |
87 | 88 | National Institute of Standards and Technology Special Publication 800-63C 89 | Natl. Inst. Stand. Technol. Spec. Publ. 800-63C, 48 pages (June 2017) 90 | CODEN: NSPUE2 91 | 92 | 93 | 94 | This publication is available free of charge from: 95 | https://doi.org/10.6028/NIST.SP.800-63c 96 | 97 |
98 | 99 |
100 | >Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. 101 |

102 | >There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST. 103 |

104 | >Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at [http://csrc.nist.gov/publications/](http://csrc.nist.gov/publications/). 105 |
106 | 107 |
108 | **Comments on this publication may be submitted to:** 109 | 110 | National Institute of Standards and Technology 111 | Attn: Applied Cybersecurity Division, Information Technology Laboratory 112 | 100 Bureau Drive (Mail Stop 2000) Gaithersburg, MD 20899-2000 113 | Email: 114 | 115 | All comments are subject to release under the Freedom of Information Act (FOIA). 116 | 117 |
118 | 119 |
120 | 121 | ### Reports on Computer Systems Technology 122 | 123 |
124 | 125 | The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation's measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL's responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL's research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations. 126 | 127 |
128 | 129 | ### Abstract 130 | 131 |
132 | 133 | This document and its companion documents, SP 800-63, SP 800-63A, and SP 800-63B, provide technical and procedural guidelines to agencies for the implementation of federated identity systems and for assertions used by federations. This publication supersedes corresponding sections of SP 800-63-2. 134 | 135 | These guidelines provide technical requirements for federal agencies implementing digital identity services and are not intended to constrain the development or use of standards outside of this purpose. This guideline focuses on the use of federated identity and the use of assertions to implement identity federations. Federation allows a given credential service provider to provide authentication attributes and (optionally) subscriber attributes to a number of separately-administered relying parties. Similarly, relying parties may use more than one credential service provider. 136 | 137 |
138 | 139 | ### Keywords 140 | 141 |
142 | 143 | assertions; authentication; credential service provider; 144 | digital authentication; electronic authentication; electronic credentials; federations. 145 | 146 |
147 | 148 | ### Acknowledgements 149 | 150 |
151 | 152 | The authors gretefully acknowledge Kaitlin Boeckl for her artistic graphics contributions to all vulumed in the SP 800-63 suite and the contributions of our many reviewers, including Joni Brennan from the Digital ID & Authentication Council of Canada (DIACC), Kat Megas and Ben Piccarreta from NIST, and Christine Abruzzi and Danna Gabel O'Rourke from Deloitte & Touche LLP. 153 | 154 | The authors would also like to acknowledge the thought leadership and innovation of the original authors: Donna F. Dodson, Elaine M. Newton, Ray A. Perlner, W. Timothy Polk, Sarbari Gupta, and Emad A. Nabbus. Without their tireless efforts, we would not have had the incredible baseline from which to evolve 800-63 to the document it is today. In addition, special thanks to the Federal Privacy Council's Digital Authentication Task Force for the contributions to the development of privacy requirements and considerations. 155 | 156 |
157 | 158 | ### Requirements Notation and Conventions 159 | 160 |
161 | 162 | The terms "SHALL" and "SHALL NOT" indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted. 163 | 164 | The terms "SHOULD" and "SHOULD NOT" indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited. 165 | 166 | The terms "MAY" and "NEED NOT" indicate a course of action permissible within the limits of the publication. 167 | 168 | The terms "CAN" and "CANNOT" indicate a possibility and capability, whether material, physical or causal or, in the negative, the absence of that possibility or capability. 169 | 170 |
171 | 172 |
173 | ## Table of Contents 174 |
175 | 176 | [1. Purpose](#purpose) 177 | 178 | [2. Introduction](#introduction) 179 | 180 | [3. Definitions and Abbreviations](#definitions) 181 | 182 | [4. Federation Assurance Levels](#fal) 183 | 184 | [5. Federation](#federation) 185 | 186 | [6. Assertions](#assertions) 187 | 188 | [7. Assertion Presentation](#presentation) 189 | 190 | [8. Security](#security) 191 | 192 | [9. Privacy Requirements and Considerations](#privacy) 193 | 194 | [10. Usability Considerations](#usability) 195 | 196 | [11. Assertion Examples](#examples) 197 | 198 | [12. References](#references) 199 | -------------------------------------------------------------------------------- /sp800-63b/cover.md: -------------------------------------------------------------------------------- 1 | 2 |
3 | 4 | # NIST Special Publication 800-63B 5 | 6 | ![](sp800-63-3/media/div-1.png) 7 | 8 | # Digital Identity Guidelines 9 | 10 | ### _Authentication and Lifecycle Management_ 11 | 12 | ![](sp800-63-3/media/div-2.png) 13 | 14 | Paul A. Grassi 15 | James L. Fenton 16 | Elaine M. Newton 17 | Ray A. Perlner 18 | Andrew R. Regenscheid 19 | William E. Burr 20 | Justin P. Richer 21 | 22 | **Privacy Authors:** 23 | Naomi B. Lefkovitz 24 | Jamie M. Danker 25 | 26 | **Usability Authors:** 27 | Yee-Yin Choong 28 | Kristen K. Greene 29 | Mary F. Theofanos 30 | 31 | This publication is available free of charge from: 32 | https://doi.org/10.6028/NIST.SP.800-63b 33 | 34 | 35 | ![](sp800-63-3/media/csd.png) 36 | ![](sp800-63-3/media/nist_logo.png) 37 | 38 |
39 | 40 | # NIST Special Publication 800-63B 41 | 42 | # Digital Identity Guidelines 43 | 44 | ### Authentication and Lifecycle Management 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 |
Paul A. Grassi
Elaine M. Newton
Applied Cybersecurity Division
Information Technology Laboratory		Ray A. Perlner
Andrew R. Regenscheid
Computer Security Division
Information Technology Laboratory
James L. Fenton
Altmode Networks
Los Altos, Calif.		William E. Burr
Dakota Consulting, Inc.
Silver Spring, Md.
Justin P. Richer
Bespoke Engineering
Billerica, Mass.
Privacy Authors:
Naomi B. Lefkovitz
Applied Cybersecurity Division
Information Technology Laboratory		Usability Authors:
Yee-Yin Choong
Kristen K. Greene
Information Access Division
Information Technology Laboratory
Jamie M. Danker
National Protection and Programs Directorate
Department of Homeland Security		Mary F. Theofanos
Office of Data and Informatics
Material Measurement Laboratory
71 | 72 | 73 | 74 | 75 | This publication is available free of charge from: 76 | https://doi.org/10.6028/NIST.SP.800-63b 77 | 78 | June 2017 79 | Includes [updates](#errata) as of 03-02-2020 80 | 81 | ![](sp800-63-3/media/commerce_logo.png) 82 | 83 | U.S. Department of Commerce 84 | *Wilbur L. Ross, Jr., Secretary* 85 | 86 | National Institute of Standards and Technology 87 | *Kent Rochford, Acting NIST Director and Under Secretary of Commerce for Standards and 88 | Technology* 89 | 90 |
91 | 92 |
93 | 94 |
95 | 96 | ### Authority 97 | 98 |
99 | 100 | This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. 101 | 102 | Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST. 103 | 104 |
105 | 106 | National Institute of Standards and Technology Special Publication 800-63B 107 | Natl. Inst. Stand. Technol. Spec. Publ. 800-63B, 78 pages (June 2017) 108 | CODEN: NSPUE2 109 | 110 | This publication is available free of charge from: 111 | https://doi.org/10.6028/NIST.SP.800-63b 112 | 113 |
114 | 115 |
116 | >Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. 117 |

118 | >There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST. 119 |

120 | >Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at [http://csrc.nist.gov/publications/](http://csrc.nist.gov/publications/). 121 |
122 | 123 |
124 | **Comments on this publication may be submitted to:** 125 | 126 | National Institute of Standards and Technology 127 | Attn: Applied Cybersecurity Division, Information Technology Laboratory 128 | 100 Bureau Drive (Mail Stop 2000) Gaithersburg, MD 20899-2000 129 | Email: 130 | 131 | All comments are subject to release under the Freedom of Information Act (FOIA). 132 | 133 |
134 | 135 |
136 | 137 | ### Reports on Computer Systems Technology 138 | 139 |
140 | 141 | The Information Technology Laboratory (ITL) at the National Institute of 142 | Standards and Technology (NIST) promotes the U.S. economy and public 143 | welfare by providing technical leadership for the Nation's measurement 144 | and standards infrastructure. ITL develops tests, test methods, 145 | reference data, proof of concept implementations, and technical analyses 146 | to advance the development and productive use of information technology. 147 | ITL's responsibilities include the development of management, 148 | administrative, technical, and physical standards and guidelines for the 149 | cost-effective security and privacy of other than national 150 | security-related information in federal information systems. The Special 151 | Publication 800-series reports on ITL's research, guidelines, and 152 | outreach efforts in information system security, and its collaborative 153 | activities with industry, government, and academic organizations. 154 | 155 |
156 | 157 | ### Abstract 158 | 159 |
160 | 161 | These guidelines provide technical requirements for federal agencies implementing digital identity services and are not intended to constrain the development or use of standards outside of this purpose. These guidelines focus on the authentication of subjects interacting with government systems over open networks, establishing that a given claimant is a subscriber who has been previously authenticated. The result of the authentication process may be used locally by the system performing the authentication or may be asserted elsewhere in a federated identity system. This document defines technical requirements for each of the three authenticator assurance levels. This publication supersedes corresponding sections of NIST Special Publication (SP) 800-63-2. 162 | 163 |
164 | 165 | ### Keywords 166 | 167 |
168 | 169 | authentication; credential service provider; digital authentication; digital credentials; electronic authentication; electronic credentials, federation. 170 | 171 |
172 | 173 | ### Acknowledgements 174 | 175 |
176 | 177 | The authors gratefully acknowledge Kaitlin Boeckl for her artistic graphics contributions to all volumes in the SP 800-63 suite and the contributions of our many reviewers, including Joni Brennan from the Digital ID & Authentication Council of Canada (DIACC), Kat Megas, Ellen Nadeau, and Ben Piccarreta from NIST, and Ryan Galluzzo and Danna Gabel O'Rourke from Deloitte & Touche LLP. 178 | 179 | The authors would also like to acknowledge the thought leadership and innovation of the original authors: Donna F. Dodson, W. Timothy Polk, Sarbari Gupta, and Emad A. Nabbus. Without their tireless efforts, we would not have had the incredible baseline from which to evolve 800-63 to the document it is today. In addition, special thanks to the Federal Privacy Council's Digital Authentication Task Force for the contributions to the development of privacy requirements and considerations. 180 | 181 |
182 | 183 | ### Requirements Notation and Conventions 184 | 185 |
186 | 187 | The terms "SHALL" and "SHALL NOT" indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted. 188 | 189 | The terms "SHOULD" and "SHOULD NOT" indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited. 190 | 191 | The terms "MAY" and "NEED NOT" indicate a course of action permissible within the limits of the publication. 192 | 193 | The terms "CAN" and "CANNOT" indicate a possibility or capability, whether material, physical or causal or, in the negative, the absence of that possibility or capability. 194 | 195 |
196 | 197 |
198 | ## Table of Contents 199 |
200 | 201 | [1. Purpose](#sec1) 202 | 203 | [2. Introduction](#sec2) 204 | 205 | [3. Definitions and Abbreviations](#sec3) 206 | 207 | [4. Authenticator Assurance Levels](#sec4) 208 | 209 | [5. Authenticator and Verifier Requirements](#sec5) 210 | 211 | [6. Authenticator Lifecycle Requirements](#sec6) 212 | 213 | [7. Session Management](#sec7) 214 | 215 | [8. Threats and Security Considerations](#sec8) 216 | 217 | [9. Privacy Considerations](#sec9) 218 | 219 | [10. Usability Considerations](#sec10) 220 | 221 | [11. References](#references) 222 | 223 | [Appendix A — Strength of Memorized Secrets](#appA) 224 | -------------------------------------------------------------------------------- /sp800-63c/sec9_privacy.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## 9 Privacy Considerations 4 | 5 | *This section is informative.* 6 | 7 | ### 9.1 Minimizing Tracking and Profiling 8 | 9 | Federation offers numerous benefits to RPs and subscribers, but requires subscribers to have trust in the federation participants. [Sections 5](#federation), [5.1.4](#proxied), and [6.3](#ppi) cover a number of technical requirements, the objective of which is to minimize privacy risks arising from increased capabilities to track and profile subscribers. For example, a subscriber using the same IdP to authenticate to multiple RPs allows the IdP to build a profile of subscriber transactions that would not have existed absent federation. The availability of such data makes it vulnerable to uses that may not be anticipated or desired by the subscriber and may inhibit subscriber adoption of federated services. 10 | 11 | [Section 5.2](#privacy-reqs) requires IdPs to use measures to maintain the objectives of predictability (enabling reliable assumptions by individuals, owners, and operators about PII and its processing by an information system) and manageability (providing the capability for granular administration of PII, including alteration, deletion, and selective disclosure) commensurate with privacy risks that can arise from the processing of attributes for purposes other than identity proofing, authentication, authorization, or attribute assertions, related fraud mitigation, or to comply with law or legal process [[NISTIR8062](#NISTIR8062)]. 12 | 13 | IdPs may have various business purposes for processing attributes, including providing non-identity services to subscribers. However, processing attributes for different purposes from the original collection purpose can create privacy risks when individuals are not expecting or comfortable with the additional processing. IdPs can determine appropriate measures commensurate with the privacy risk arising from the additional processing. For example, absent applicable law, regulation or policy, it may not be necessary to get consent when processing attributes to provide non-identity services requested by subscribers, although notices may help subscribers maintain reliable assumptions about the processing (predictability). Other processing of attributes may carry different privacy risks that call for obtaining consent or allowing subscribers more control over the use or disclosure of specific attributes (manageability). Subscriber consent needs to be meaningful; therefore, when IdPs do use consent measures, they cannot make acceptance by the subscriber of additional uses a condition of providing the identity service. 14 | 15 | Consult the SAOP if there are questions about whether the proposed processing falls outside the scope of the permitted processing or the appropriate privacy risk mitigation measures. 16 | 17 | [Section 5.2](#privacy-reqs) also encourages the use of technical measures to provide disassociability (enabling the processing of PII or events without association to individuals or devices beyond the operational requirements of the system) and prevent subscriber activity tracking and profiling [NISTIR8062](#NISTIR8062). Technical measures, such as those outlined in [Section 5.1.4](#proxied) for proxied federation and [Section 6.3](#ppi) for pairwise pseudonymous identifiers, can increase the effectiveness of policies by making it more difficult to track or profile subscribers beyond operational requirements. 18 | 19 | ### 9.2 Notice and Consent 20 | 21 | To build subscriber trust in federation, subscribers need to be able to develop reliable assumptions about how their information is being processed. For instance, it can be helpful for subscribers to understand what information will be transmitted, which attributes for the transaction are required versus optional, and to have the ability to decide whether to transmit optional attributes to the RP. Accordingly, [Section 7](#presentation) requires that positive confirmation be obtained from the subscriber before any attributes about the subscriber are transmitted to any RP. In determining when a set of RPs should share a common pairwise pseudonymous identifier as in [Section 6.3.2](#ppi-gen), the IdP considers the subscriber's understanding of such a grouping of RPs and the role of notice in assisting such understanding. An effective notice will take into account user experience design standards and research, as well as an assessment of privacy risks that may arise from the information processing. There are various factors to be considered, including the reliability of the assumptions subscribers may have about the processing and the role of different entities involved in federation. However, a link to a complex, legalistic privacy policy or general terms and conditions that a substantial number of subscribers do not read or understand is never an effective notice. 22 | 23 | [Section 7](#presentation) does not specify which party should provide the notice. In some cases, a party in a federation may not have a direct connection to the subscriber in order to provide notice and obtain consent. Although multiple parties may elect to provide notice, it is permissible for parties to determine in advance, either contractually or through trust framework policies, which party will provide the notice and obtain confirmation, as long as the determination is being based upon factors that center on enabling the subscriber to pay attention to the notice and make an informed choice. 24 | 25 | If an IdP is using a whitelist of RPs as described in [Section 4.2](#runtime-decisions), any RPs on that list are not presented to the subscriber during an authentication transaction. Since the IdP does not provide notice to the subscriber at runtime, the IdP makes its list of whitelisted RPs available to the subscriber so that the subscriber can see which RPs on the whitelist have access to which of the subscriber's attributes in an authentication transaction. Since IdPs can not share a subscriber's authentication information or attributes with a whitelisted RP outside of an authentication transaction involving the subscriber (see [Section 5.2](#privacy-reqs)), the existence of an RP on a list of IdPs does not indicate that the subscriber's information will be shared. However, if the subscriber logs into any of the whitelisted RPs using the IdP, the attributes indicated will be shared as part of the authentication transaction. 26 | 27 | If a subscriber's runtime decisions were stored by the IdP to facilitate future transactions, the IdP also needs to allow the subscriber to view and revoke any RPs that were previously approved during a runtime decision. This list includes information on which attributes were approved. 28 | 29 | ### 9.3 Data Minimization 30 | 31 | Federation enables the data exposed to an RP to be minimized — resultantly, the subscriber's privacy is enhanced. Although an IdP may collect additional attributes beyond what the RP requires for its use case, only those attributes that were explicitly requested by the RP are to be transmitted by the IdP. In some instances, an RP does not require a full value of an attribute. For example, an RP may need to know whether the subscriber is over 13 years old, but has no need for the full date of birth. To minimize collection of potentially sensitive PII, the RP may request an attribute reference (e.g., Question: Is the subscriber over 13 years old? Response: Y/N or Pass/Fail). This minimizes the RP's collection of potentially sensitive and unnecessary PII. Accordingly, [Section 7.3](#protecting-information) requires the RP to, where feasible, request attribute references rather than full attribute values. To support this RP requirement IdPs are, in turn, required to support attribute references. 32 | 33 | ### 9.4 Agency-Specific Privacy Compliance 34 | 35 | [Section 5.2](#privacy-reqs) identifies agency requirements to consult their SAOP to determine privacy compliance requirements. It is critical to involve the agency's SAOP in the earliest stages of digital authentication system development to assess and mitigate privacy risks and advise the agency on compliance obligations such as whether the federation triggers the Privacy Act of 1974 or the E-Government Act of 2002 requirement to conduct a PIA. For example, if the Agency is serving as an IdP in a federation, it is likely that the Privacy Act requirements will be triggered and require coverage by either a new or existing Privacy Act system of records since credentials would be maintained at the IdP on behalf of any RP it federates with. If, however, the agency is an RP and using a third-party IdP, digital authentication may not trigger the requirements of the Privacy Act, depending on what data passed from the RP is maintained by the agency as the RP (in such instances the agency may have a broader programmatic SORN that covers such data). 36 | 37 | The SAOP can similarly assist the agency in determining whether a PIA is required. These considerations should not be read as a requirement to develop a Privacy Act SORN or PIA for use of a federated credential alone. In many cases it will make the most sense to draft a PIA and SORN that encompasses the entire digital authentication process or includes the digital authentication process as part of a larger programmatic PIA that discusses the program or benefit the agency is establishing online access. 38 | 39 | Due to the many components of digital authentication, it is important for the SAOP to have an awareness and understanding of each individual component. For example, other privacy artifacts may be applicable to an agency offering or using federated IdP or RP services, such as Data Use Agreements, Computer Matching Agreements, etc. The SAOP can assist the agency in determining what additional requirements apply. Moreover, a thorough understanding of the individual components of digital authentication will enable the SAOP to thoroughly assess and mitigate privacy risks either through compliance processes or by other means. 40 | 41 | 42 | ### 9.5 Blinding in Proxied Federation 43 | 44 | While some proxy structures — typically those that exist primarily to simplify integration — may not offer additional subscriber privacy protection, others offer varying levels of privacy to the subscriber through a range of blinding technologies. Privacy policies may dictate appropriate use of the subscriber attributes and authentication transaction data (e.g., identities of the ultimate IdP and RP) by the IdP, RP, and the federation proxy. Technical means such as blinding can increase effectiveness of these policies by making the data more difficult to obtain. As the level of blinding increases, the technical and operational implementation complexity may increase. Proxies need to map transactions to the appropriate parties on either side as well as manage the keys for all parties in the transaction. 45 | 46 | Even with the use of blinding technologies, a blinded party may still infer protected subscriber information through released attribute data or metadata, such as by analysis of timestamps, attribute bundle sizes, or attribute signer information. The IdP could consider additional privacy-enhancing approaches to reduce the risk of revealing identifying information of the entities participating in the federation. 47 | 48 | The following table illustrates a spectrum of blinding implementations used in proxied federation. This table is intended to be illustrative, and is neither comprehensive nor technology-specific. 49 | 50 |
51 | 52 | **Table 9-1 Federation Proxies** 53 | 54 |
55 | 56 | 57 | |Proxy Type|RP knows IdP|IdP knows RP|Proxy can track subscriptions between RP and IdP|Proxy can see attributes of Subscriber| 58 | |---|:---:|:---:|:---:|:---:| 59 | |Non-Blinding Proxy with Attributes|Yes|Yes|Yes|Yes| 60 | |Non-Blinding Proxy|Yes|Yes|Yes|N/A| 61 | |Double Blind Proxy with Attributes|No|No|Yes|Yes| 62 | |Double Blind Proxy|No|No|Yes|N/A| 63 | |Triple Blind Proxy with or without Attributes|No|No|No|No| 64 | 65 | --------------------------------------------------------------------------------