NIST SP 800-63-3C - Revision history

Tom: /* Problems */

2021-03-25T14:54:07Z

‎Problems

Tom: /* Problems */

2020-04-01T05:09:38Z

‎Problems

Tom: /* Problems */

2020-04-01T04:58:00Z

‎Problems

Tom: /* Problems */

2020-04-01T04:56:04Z

‎Problems

Tom: /* Problems */

2020-04-01T04:53:35Z

‎Problems

Tom: /* Context */

2020-04-01T04:49:03Z

‎Context

Tom: /* Problems */

2020-04-01T04:47:09Z

‎Problems

Tom: /* References */

2020-04-01T04:36:19Z

‎References

Tom: /* References */

2020-04-01T04:36:04Z

‎References

Tom at 04:35, 1 April 2020

2020-04-01T04:35:12Z

@@ Line 12: / Line 12: @@
 # 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.
+# 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.

@@ Line 12: / Line 12: @@
 # 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. 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.
+# 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.

@@ Line 13: / Line 13: @@
 * 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. 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.
 ==References==

@@ Line 12: / Line 12: @@
 # 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. It would be clearer if this requirement were presented front and center as ''THE KEY FEATURE'' of an assertion.
+# 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. 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.
 ==References==

@@ Line 9: / Line 9: @@
 ==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.

@@ Line 4: / Line 4: @@
 *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==

@@ Line 10: / Line 10: @@
 ==References==
 <references />
 * The wiki page [[NIST SP 800-63-3]]
 [[Category:Standard]]
 [[Category:Identifier]]