Authentication for Enrollment in a Financial Service

Title:
Authentication for Enrollment in a Financial Service

Use Case Description:
The purpose of this use case is to enable a bank / financial institution that’s a member of a consortium or trust community of banks / FIs to establish the identity of someone seeking to enroll in a new financial service by relying on a credential issued by another bank / FI that’s also a member of a consortium or trust community, provided that such a credential exists. The consortium / trust community is assumed to be governed by a common trust framework. As an identity theft prevention measure, the use case also includes a discovery process to determine whether an enrollee is attempting to impersonate someone else who has already been issued a credential by another member of the consortium / trust community.

Use Case Category:
Authentication

Contributor:
Bob Pinheiro (nstic@bobpinheiro.com)

Use Case Details

Actors:
A Consortium or “trust community” of banks and/or other financial institutions (FIs) that exists for the purpose of (a) helping Consortium members to establish the identities of new enrollees in financial accounts; (b) preventing identity fraud by helping Consortium members to discover fraudulent identity claims during enrollment. The Consortium is governed by a common Trust Framework that specifies a set of rules, definitions, criteria, and agreements that define the nature of the trust relationship between Consortium members.

Identity Provider: A Consortium member that has verified an individual’s identity to an appropriate level of assurance by means of an identity proofing procedure, and has issued an NSTIC-compliant Credential to that individual. For the purposes of this use case, an individual’s “identity” is defined as a minimum set of personal information needed to enroll an individual in a new account. Most likely this information consists of name, address, birthdate, and Social Security Number.

Credential: An object or data structure that authoritatively binds an individual’s identity (and optionally, additional attributes) to a Token possessed and controlled by that individual (aka “Credential Holder”).

Credential Holder: An individual whose identity has been verified by an Identity Provider, and who has been issued a Credential by that Identity Provider.

Token: Something that the Credential Holder possesses and controls that is used to authenticate the Credential Holder’s identity. A Token binds a Credential Holder to a particular Credential.

Claimant: An individual who claims a particular identity for the purpose of enrolling in a new financial account. [This use case assumes that Claimants are individuals acting on their own behalf, and not on behalf of an employer or other entity.]

Relying Party: A Consortium member that relies on a Credential or Assertion issued by another Consortium member to establish the identity of a Claimant.

Assertion: A secure electronic message containing verified identity information pertaining to a Credential Holder that is sent from a Consortium member acting as an Identity Provider to another member acting as a Relying Party (via the Consortium). An Assertion is generated only if a Claimant is able to authenticate to the Identity Provider by means of a Token bound to a Credential previously issued by the Identity Provider.

Goals:
To establish the identity of a Claimant seeking to enroll online in a new financial service by relying on a Credential issued by another Consortium member acting as an Identity Provider (if such a Credential exists).

• Allows a financial institution acting as a Relying Party to establish the identity of a Claimant (at an appropriate assurance level) during the enrollment process without performing identity proofing, if the Claimant controls an appropriate Token bound to a Credential issued by another Consortium member at the same (or higher) assurance level.

To help prevent identity theft/impersonation of existing Credential Holders.

• Allows a financial institution to discover, during the enrollment process, whether a Claimant is attempting to impersonate a Credential Holder who has previously been issued a Credential by a Consortium member.

Assumptions:
This use case pertains to individuals seeking to enroll in personal financial accounts at a bank/FI. It is assumed that banks require a minimal set of personal information for identifying individuals enrolling in new accounts. Most likely this information consists of name, address, birthdate, Social Security Number. Depending on the nature of the account, additional information may also be required by the enrolling bank/FI.

A Consortium of financial institutions exists and is governed by a common Trust Framework that specifies a set of rules, definitions, criteria, and agreements that define the nature of the trust relationship between Consortium members.

Consortium members do not gain competitive advantage over other members by their participation in the Consortium.

Individuals who engage in online banking at financial institutions that are Consortium members will be issued an NSTIC-compliant Credential that binds a Token controlled by the individual to that individual’s identity. The purpose of the Token / Credential pair is to allow the individual to authenticate to his/her account at the bank/FI that issued the Credential. These Credentials / Tokens are deployed in such a way that multiple Credentials / Tokens may reside on a single physical device.

Once a customer has enrolled online in a new financial account, neither the consortium nor any third party bank plays any active role in ongoing authentication of that customer to the new account. It’s possible that the consortium may issue credentials or tokens for such authentication, but the consortium will have no role in the actual authentication transaction. Hence neither the consortium, nor any third party bank, will maintain any records of when a customer authenticates to any of his/her online banking accounts.

Upon enrolling in a new financial account at a bank/FI that is a Consortium member, the customer will be given an option to participate in an Identity Theft Prevention program that provides the customer with a certain degree of assurance against being impersonated at other Consortium member banks/FIs. This Identity Theft Prevention program will be free to customers.

There will exist within the Consortium a discovery process to determine whether personally identifiable information (PII) provided by a Claimant to establish the Claimant’s identity when enrolling in a new financial service identifies a Credential Holder to whom a Credential has been previously issued by a Consortium member, and who has chosen to participate in the Identity Theft Prevention program.

As a condition of joining the Consortium, and as an identity theft prevention measure, financial institutions enrolling new customers who present only PII to assert their identity will “submit” that information to the discovery process to determine whether the PII corresponds to someone already holding a Credential issued within the Consortium who has chosen to participate in the voluntary Identity Theft Prevention program. If the PII identifies such a person, the enrolling financial institution will not accept the enrollee’s/Claimant’s identity claim unless that Claimant can authenticate his/her identity to another Consortium member using an appropriate Token/Credential pair. If the Claimant presents PII that is not associated with a participant in the Identity Theft Prevention program, the enrolling financial institution will verify the Claimant’s identity by a process conformant to the identity proofing criteria defined in the Trust Framework.

Privacy is protected within the Consortium to the extent that: (a) a Relying Party does not know which Identity Provider is asserting the identity of the Claimant, (b) an Identity Provider does not know which Relying Party is receiving the assertion it issues, and (c) knowledge of which banking customers are also Credential Holders will not be discoverable outside of the Consortium.

In addition to the above privacy protections, any information about where an individual maintains financial accounts that the Consortium may obtain as a result of its activities in helping to establish the individual's identity will remain strictly confidential and may not be sold or made available to others without express consent of the individual involved.

Any Trust Framework(s) developed by the Consortium will be compatible with government regulations under which Consortium members operate. In particular, a protocol whereby a Relying Party bank that is a member of the Consortium can establish the identity of a new customer by means of a trusted Assertion received from another member of the Consortium acting as an Identity Provider is compatible with the “Know Your Customer” rules. See Discussion tab for more details.

This use case must still be evaluated within the financial services community for issues such as liability, regulatory concerns, privacy, and economic viability.

Requirements:
Some criteria adopted from NIST SP 800-63

“Know Your Customer” requirements for banks

Adherence to the NSTIC Guiding Principles.

Process Flow:
A Claimant visits the website of a bank or financial institution that is a Consortium member, and seeks to enroll in a financial service. The bank/FI either (a) automatically discovers whether the Claimant’s computing device contains a Credential / Token that can be used to authenticate to another Consortium member; or (b) presents a list of other banks/FIs that are members of the Consortium, and asks whether the Claimant has a Token / Credential that is used for access to an existing account at one of these banks/FIs. In either case, if such a Token / Credential exists, the Claimant is asked whether his/her Token / Credential should be used for identity verification purposes. If the Claimant responds Yes, the bank/FI requests that the Claimant authenticate to the other Consortium member by means of an appropriate Token/Credential pair. [This use case does not describe, nor depend upon, the specifics of this authentication procedure.]

If the Claimant is able to successfully authenticate to another Consortium member, that member asks permission of the Claimant to release certain verified identity information, in an appropriate electronic format, to the Relying Party bank/FI. Assuming that permission is granted, an Assertion is generated and transmitted to the Relying Party bank/FI. This Assertion provides sufficient information about the Claimant to allow the Relying Party bank/FI to establish the Claimant’s identity for the purposes of enrolling in the new financial service.

If authentication is not successful, or if the Claimant indicates that he/she is not already enrolled at another Consortium bank/FI, then the enrolling bank/FI will request sufficient PII from the Claimant to establish the Claimant’s identity. The kind of information requested, as well as any authentication procedures the bank/FI may use to verify/validate that PII, will be specified in the identity proofing procedures contained within the Trust Framework, and will be consistent with the “Know Your Customer” regulations that banks/FIs must comply with. Most likely, this information will minimally consist of name, address, birthdate, and Social Security Number.

Any PII provided by a Claimant to establish the Claimant’s identity will be submitted to the Consortium’s discovery process, to determine whether the PII corresponds to someone who already possesses an NSTIC-compliant Credential previously issued within the Consortium and who has chosen to participate in the voluntary Identity Theft Prevention program. If the PII identifies such a person, the Relying Party bank/FI will accept the Claimant’s identity claim only if the Claimant is able to authenticate to another Consortium member. Otherwise, the bank/FI will take measures to verify the Claimant’s identity consistent with the identity proofing criteria specified in the Trust Framework. A Claimant whose identity is verified in such a manner will be issued an NSTIC-compliant Credential bound to an appropriate Token, provided that issuance of such a Credential on the basis of PII that is provided online conforms to criteria specified in the Trust Framework.

Success Scenario:
The enrolling bank/FI will have successfully utilized the Consortium to verify a Claimant’s identity during the enrollment process if the Claimant can authenticate to another Consortium member bank/FI, acting as an Identity Provider, by means of an appropriate Token/Credential pair.

The enrolling bank/FI will have successfully utilized the Consortium to prevent a case of identity theft if: (a) PII presented by the Claimant identifies a Credential Holder who was previously issued a Credential within the Consortium, (b) the Claimant cannot satisfactorily authenticate to the Credential issuer, (c) the enrolling bank/FI does not accept the Claimant’s unverified identity claim.

Error Conditions:
The discovery process cannot determine whether PII presented by a Claimant corresponds to another Credential Holder within the Consortium, or falsely determines that the PII represents another Credential Holder when it actually does not.

Verified personal information released by a Consortium member acting as an Identity Provider does not satisfy the minimal identity requirements of the Consortium member acting as the Relying Party.

Any aspects of a Trust Framework are incompatible with regulations that govern the operation of financial institutions that are members of the Consortium governed by the Trust Framework.

Any of the privacy assumptions are violated.