Difference between revisions of "NIST SP 800-63-3C"
From MgmtWiki
(→References) |
(→Problems) |
||
| Line 7: | Line 7: | ||
==Problems== | ==Problems== | ||
Listed by Section | Listed by Section | ||
| − | * | + | * Section 4 |
| + | # The term "Bearer Assertions" is used but not defined until sexton 6.1 on Assertion Binding. It is an unfortunate term in the sense that it looks like it might reference a Bearer Token of OAuth which is known to be a security risk if captured and reused by an attacker. It isn't until section 6.1.2 paragraph 2 that is clearly defined in a back-handed sort of way. That is by way of errata which asserts that the assertion must be signed by the IdP. It would be clearer if this requirement were presented front and center as ''THE KEY FEATURE'' of an assertion. | ||
| + | |||
==References== | ==References== | ||
<references /> | <references /> | ||
Revision as of 20:47, 31 March 2020
Contents
Full Title
NIST Special Publication 800-63-3C -- Digital Identity Guidelines -- Federation and Assertions
Context
- The context for these comments is the first revision of this specification published on 2017-06.
- Federation is largely limited to the identity of the industry association that has created a set of specifications to be verified by the Identifier.
Problems
Listed by Section
- Section 4
- The term "Bearer Assertions" is used but not defined until sexton 6.1 on Assertion Binding. It is an unfortunate term in the sense that it looks like it might reference a Bearer Token of OAuth which is known to be a security risk if captured and reused by an attacker. It isn't until section 6.1.2 paragraph 2 that is clearly defined in a back-handed sort of way. That is by way of errata which asserts that the assertion must be signed by the IdP. It would be clearer if this requirement were presented front and center as THE KEY FEATURE of an assertion.
References
- The wiki page NIST SP 800-63-3
