Difference between revisions of "Assurance"

From MgmtWiki
Jump to: navigation, search
(→‎Solutions)
(→‎A summary of the 3 categories in NIST SP 800-63-3 and Later)
 
(23 intermediate revisions by the same user not shown)
Line 4: Line 4:
  
 
==Context==
 
==Context==
−
 
 
* Some means for assuring the [[Web Site Security]] is required. See that page for details.
 
* Some means for assuring the [[Web Site Security]] is required. See that page for details.
 
* The rest of this page is about establishing a level of assurance for [[User Information]] about a [[User]] also known as a [[Subject]].
 
* The rest of this page is about establishing a level of assurance for [[User Information]] about a [[User]] also known as a [[Subject]].
Line 10: Line 9:
 
* [https://pages.nist.gov/800-63-3/sp800-63-3.html New version of SP 800-63-3] with [[Assurance]] separated out from the other [[Authentication]] [[Attribute]]s.
 
* [https://pages.nist.gov/800-63-3/sp800-63-3.html New version of SP 800-63-3] with [[Assurance]] separated out from the other [[Authentication]] [[Attribute]]s.
 
* [[Provenance]] is a term that is sometimes used for the level of [[Assurance]] that a [[Data Controller]] has in the origin and reliability of [[User]] [[Attribute]]s, especially health care data
 
* [[Provenance]] is a term that is sometimes used for the level of [[Assurance]] that a [[Data Controller]] has in the origin and reliability of [[User]] [[Attribute]]s, especially health care data
 +
* The [[Assurance]] level measures the quality of the [[Binding]]:
 +
** (63A-IAL) [[Identity]] of the subject to the [[Attribute]]s or [[Claim]]s about that subject.  More details can be found on the wiki page [[Assured Identity]].
 +
** (63B-AAL) [[Authentication]] of the subject to the [[Credential]] used to verify the identity of the subject (which includes attributes from IAL)
 +
** (63C-FAL) [[Federation]] of the subject or issuer to the [[Best_Practice_in_HealthCare#Federated_Trust_Anchor|Trust Anchor]].
  
 
For a [[User]] that wants some [[Assurance]] about a [[Web Site]] see [[Trusted Third Party]].
 
For a [[User]] that wants some [[Assurance]] about a [[Web Site]] see [[Trusted Third Party]].
Line 19: Line 22:
  
 
==Solutions==
 
==Solutions==
−
A rather facile mapping of the [https://pages.nist.gov/800-63-3/sp800-63-3.html NIST 800-63-3] levels of [[Assurance]] to the processes known today is:
+
A rather facile mapping of the [https://pages.nist.gov/800-63-3/sp800-63-3.html NIST 800-63-3] levels of [[Assurance]] to the processes known in NIST SP 800-63-3 is:
 
* LOA1, AAL1 ==> password
 
* LOA1, AAL1 ==> password
−
* LOA2, AAL2 ==> 2FA (Authenticator Assurance Level 2 provides high confidence that the claimant controls an [[Authenticator]] 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
+
* LOA2, AAL2 ==> 2FA (two (or more) factors of authentication).
 
* LOA3, AAL3 ==> U2F
 
* LOA3, AAL3 ==> U2F
  
 
The best source of [[Truth]] about an [[Identity]] is obtained by documentation of the [[Identity Proofing]] process. That is something that can be audited to measure reality against expectations.
 
The best source of [[Truth]] about an [[Identity]] is obtained by documentation of the [[Identity Proofing]] process. That is something that can be audited to measure reality against expectations.
  
−
===A summary of the 3 categories now in NIST 800-63-3===
+
===The 3 categories in NIST SP 800-63-3 and Later===
−
A summary of each of the identity, authenticator, and federation assurance levels is provided below.
+
A summary of each of the [[Identifier]], [[Authentication]], and federation assurance levels is provided below.
 +
 
 +
When described generically or bundled, NIST guidelines refers to IAL, AAL, and FAL as xAL.
  
 
====Identity Assurance Level====
 
====Identity Assurance Level====
 +
Answers the question - how do we know who the subject is in the real-world.
 
#  At IAL1, attributes, if any, are self-asserted or should be treated as self-asserted.
 
#  At IAL1, attributes, if any, are self-asserted or should be treated as self-asserted.
 
#  At IAL2, either remote or in-person identity proofing is required. IAL2 requires identifying attributes to have been verified in person or remotely using, at a minimum, the procedures given in SP 800-63A.
 
#  At IAL2, either remote or in-person identity proofing is required. IAL2 requires identifying attributes to have been verified in person or remotely using, at a minimum, the procedures given in SP 800-63A.
Line 35: Line 41:
  
 
====Authenticator Assurance Level====
 
====Authenticator Assurance Level====
 +
Answers the question - how much should we trust the information that we have been given (supposedly) by the subject.
 
# AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful a AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator(s) through a secure authentication protocol.
 
# AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful a AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator(s) through a secure authentication protocol.
 
#  AAL2 provides high confidence that the claimant controls authenticator(s) registered to the subscriber. Proof of possession and control of two different authentication factors is required through a secure authentication protocol. Approved cryptographic techniques are required at AAL2 and above.
 
#  AAL2 provides high confidence that the claimant controls authenticator(s) registered to the subscriber. Proof of possession and control of two different authentication factors is required through a secure authentication protocol. Approved cryptographic techniques are required at AAL2 and above.
−
#  AAL3 provides very high confidence that the claimant controls authenticator(s) registered to the subscriber. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 is like AAL2 but also requires a “hard” cryptographic authenticator that provides verifier impersonation resistance.
+
#  AAL3 provides very high confidence that the claimant controls authenticator(s) registered to the subscriber. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 is like AAL2 but also requires a “hard” cryptographic authenticator that provides verifier [[Impersonation]] resistance.
  
 
====Federation Assurance Level====
 
====Federation Assurance Level====
 +
Answers the question - how much should we trust the information that we have been given (supposedly) by  some federation server.
 
#  FAL1 permits the RP to receive a bearer assertion from an identity provider (IdP). The IdP must sign the assertion using approved cryptography.
 
#  FAL1 permits the RP to receive a bearer assertion from an identity provider (IdP). The IdP must sign the assertion using approved cryptography.
 
#  FAL2 adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it.
 
#  FAL2 adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it.
 
#  FAL3 requires the subscriber to present proof of possession of a cryptographic key reference to in the assertion and the assertion artifact itself. The assertion must be signed using approved cryptography and encrypted to the RP using approved cryptography.
 
#  FAL3 requires the subscriber to present proof of possession of a cryptographic key reference to in the assertion and the assertion artifact itself. The assertion must be signed using approved cryptography and encrypted to the RP using approved cryptography.
−
When described generically or bundled, NIST guidelines refers to IAL, AAL, and FAL as xAL.
+
 
 +
===Assurance in Credentials===
 +
The [[Verifiable Credential]] standards creators have decided to invest the credential with an assurance level, which actually discusses the assurance of the user (holder) that is needed to acquire the credential and not the credential itself. [https://wiki.trustoverip.org/display/HOME/Classes+of+Verifiable+Credentials This link] gets the document which is a good compendium of the various standards available on 2021-07.
  
 
===Assurance in Verticals===
 
===Assurance in Verticals===
 
====Health Care====
 
====Health Care====
 
====European Financial====
 
====European Financial====
−
*Also known as Know Your Customer, or KYC, the rules are established as Anti-Money Laundering (AML) regulations that are roughly analogous to the IAL levels.
+
*Also known as Know Your Customer, or KYC, the rules are established as Anti-Money Laundering ([[AML]]) regulations that are roughly analogous to the IAL levels.
 
*[file:///C:/Users/Tom/Downloads/LoA-rated%20Attribute%20Framework%20Proposal%20-%2020181017.pdf eKYC FOR REMOTE ON-BOARDING - DATA & LoA eKYC FRAMEWORK - PRIORITY GROUP 2 PROPOSAL FOR DISCUSSION]
 
*[file:///C:/Users/Tom/Downloads/LoA-rated%20Attribute%20Framework%20Proposal%20-%2020181017.pdf eKYC FOR REMOTE ON-BOARDING - DATA & LoA eKYC FRAMEWORK - PRIORITY GROUP 2 PROPOSAL FOR DISCUSSION]
  
 
==References==
 
==References==
 
<references />
 
<references />
−
===External References===
+
===Other Materiel===
 
# Synonyms include: [[Validated]] which typically is used with [[Assurance]] of claims, or [[Attested]] which typically is used with [[Assurance]] of [[User Device]]s.
 
# Synonyms include: [[Validated]] which typically is used with [[Assurance]] of claims, or [[Attested]] which typically is used with [[Assurance]] of [[User Device]]s.
 +
# Also see the wiki page on [[Accuracy]].
  
 
[[Category:Glossary]]
 
[[Category:Glossary]]
Line 61: Line 72:
 
[[Category:Authorization]]
 
[[Category:Authorization]]
 
[[Category:Assurance]]
 
[[Category:Assurance]]
 +
[[Category: Factor]]

Latest revision as of 14:58, 1 November 2024

Full Title or Meme

The level of trust that can be afforded a claim of an Identifier or Attribute.

Context

For a User that wants some Assurance about a Web Site see Trusted Third Party.

Problems

  • In contexts where names are not validated (of low Assurance) the problem arises that trolls many adopt the name of some well-known person to be able to make statements that falsely appear to be from the real person.[1]
  • See discussion on the pages for Ephemeral and Persistent.
  • Most of the existing protocols, like OpenID Connect and SAML 2.0 support the older NIST SP 800-63-2 level of assurance ratings. These are also baked into RFC 6711 "An IANA Registry for Level of Assurance (LoA) Profiles" and ISO/IEC 291151.

Solutions

A rather facile mapping of the NIST 800-63-3 levels of Assurance to the processes known in NIST SP 800-63-3 is:

  • LOA1, AAL1 ==> password
  • LOA2, AAL2 ==> 2FA (two (or more) factors of authentication).
  • LOA3, AAL3 ==> U2F

The best source of Truth about an Identity is obtained by documentation of the Identity Proofing process. That is something that can be audited to measure reality against expectations.

The 3 categories in NIST SP 800-63-3 and Later

A summary of each of the Identifier, Authentication, and federation assurance levels is provided below.

When described generically or bundled, NIST guidelines refers to IAL, AAL, and FAL as xAL.

Identity Assurance Level

Answers the question - how do we know who the subject is in the real-world.

  1. At IAL1, attributes, if any, are self-asserted or should be treated as self-asserted.
  2. At IAL2, either remote or in-person identity proofing is required. IAL2 requires identifying attributes to have been verified in person or remotely using, at a minimum, the procedures given in SP 800-63A.
  3. At IAL3, in-person identity proofing is required. Identifying attributes must be verified by an authorized CSP representative through examination of physical documentation as described in SP 800-63A.

Authenticator Assurance Level

Answers the question - how much should we trust the information that we have been given (supposedly) by the subject.

  1. AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful a AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator(s) through a secure authentication protocol.
  2. AAL2 provides high confidence that the claimant controls authenticator(s) registered to the subscriber. Proof of possession and control of two different authentication factors is required through a secure authentication protocol. Approved cryptographic techniques are required at AAL2 and above.
  3. AAL3 provides very high confidence that the claimant controls authenticator(s) registered to the subscriber. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 is like AAL2 but also requires a “hard” cryptographic authenticator that provides verifier Impersonation resistance.

Federation Assurance Level

Answers the question - how much should we trust the information that we have been given (supposedly) by some federation server.

  1. FAL1 permits the RP to receive a bearer assertion from an identity provider (IdP). The IdP must sign the assertion using approved cryptography.
  2. FAL2 adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it.
  3. FAL3 requires the subscriber to present proof of possession of a cryptographic key reference to in the assertion and the assertion artifact itself. The assertion must be signed using approved cryptography and encrypted to the RP using approved cryptography.

Assurance in Credentials

The Verifiable Credential standards creators have decided to invest the credential with an assurance level, which actually discusses the assurance of the user (holder) that is needed to acquire the credential and not the credential itself. This link gets the document which is a good compendium of the various standards available on 2021-07.

Assurance in Verticals

Health Care

European Financial

  • Also known as Know Your Customer, or KYC, the rules are established as Anti-Money Laundering (AML) regulations that are roughly analogous to the IAL levels.
  • [file:///C:/Users/Tom/Downloads/LoA-rated%20Attribute%20Framework%20Proposal%20-%2020181017.pdf eKYC FOR REMOTE ON-BOARDING - DATA & LoA eKYC FRAMEWORK - PRIORITY GROUP 2 PROPOSAL FOR DISCUSSION]

References

  1. ↑ Jack Nicas, Oprah, Is That You? Most Likely, It's Not. 2018-07-08 New York Times page BU1

Other Materiel

  1. Synonyms include: Validated which typically is used with Assurance of claims, or Attested which typically is used with Assurance of User Devices.
  2. Also see the wiki page on Accuracy.
Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Assurance&oldid=22248"