Difference between revisions of "NIST SP 800-63-3C"
From MgmtWiki
(→Context) |
(→Problems) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 9: | Line 9: | ||
==Problems== | ==Problems== | ||
Listed by Section | Listed by Section | ||
| + | * Section 2 | ||
| + | # Federation is defined as a process that allows for the conveyance of authentication attributes. While a versifier (the CSP) is mentioned, it should be made clear that the verification of attributes to federation standards is key. (e.g. that attributes specified by HL4 FHIR have been applied and verified for access to patient health records.) | ||
* Section 4 | * 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 | + | # 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. Looking at Section 5.2 the FAL1 description does, in fact, specify that signing is required. It would be clearer if this requirement were presented front and center as ''THE KEY FEATURE'' of an assertion. But it should also note that some assertions will be signed by other parties, in particular by the CSP and the supplier of any authentication protection method. In other word, a compound assertion collected by the IdP and presented to the RP should be an expected solution. |
| + | # While it is not specifically excluded, the possibility that the IdP is hosted by the subscriber should be explicitly described. | ||
==References== | ==References== | ||
Revision as of 22:09, 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.
- All most all of the rest of the document is about assertion made by the IdP.
- No reference to the federations standards, like OpenID, are included. (As this was written the OpenID doc was still in draft form.)
Problems
Listed by Section
- Section 2
- Federation is defined as a process that allows for the conveyance of authentication attributes. While a versifier (the CSP) is mentioned, it should be made clear that the verification of attributes to federation standards is key. (e.g. that attributes specified by HL4 FHIR have been applied and verified for access to patient health records.)
- 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. Looking at Section 5.2 the FAL1 description does, in fact, specify that signing is required. It would be clearer if this requirement were presented front and center as THE KEY FEATURE of an assertion. But it should also note that some assertions will be signed by other parties, in particular by the CSP and the supplier of any authentication protection method. In other word, a compound assertion collected by the IdP and presented to the RP should be an expected solution.
- While it is not specifically excluded, the possibility that the IdP is hosted by the subscriber should be explicitly described.
References
- The wiki page NIST SP 800-63-3
