Difference between revisions of "Assurance"
(→Assurance in Verticals)
(→Assurance in Credentials)
|Line 54:||Line 54:|
===Assurance in Credentials===
===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.
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
===Assurance in Verticals===
===Assurance in Verticals===
Latest revision as of 10:54, 24 August 2021
- 1 Full Title or Meme
- 2 Context
- 3 Problems
- 4 Solutions
- 5 References
Full Title or Meme
- 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.
- Previous version of SP 800-63-2 described level of Assurance or LOA that are still part of ISO standards. NIST has published a FAQ to describe the reasons for the upgrade.
- New version of SP 800-63-3 with Assurance separated out from the other Authentication Attributes.
- 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 Attributes, especially health care data
- The Assurance level measures the quality of the Binding:
- 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.
- 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.
A rather facile mapping of the NIST 800-63-3 levels of Assurance to the processes known today is:
- LOA1, AAL1 ==> password
- LOA2, AAL2 ==> 2FA (two (or more) factors of authentication).
- LOA3, AAL3 ==> U2F
A summary of the 3 categories now in NIST 800-63-3
A summary of each of the identity, authenticator, 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.
- 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 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.
- 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.
- 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.
- 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.
- 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
- 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]
- Jack Nicas, Oprah, Is That You? Most Likely, It's Not. 2018-07-08 New York Times page BU1