The first step – verifying the identity of an individual consumer to an acceptable level of certainty – is typically the most difficult, expensive, and important.

• Recommendation 1A: Consider in-person proofing as appropriate in some, but not all, cases: By in-person proofing, we generally mean requiring a face-to-face encounter in which the consumer presents a verified current primary government ID that contains a picture and either address of record or nationality (e.g., driver's license or passport). This option is an acceptable industry practice that is particularly appropriate when the organization performing the identity proofing:

  1. Has no prior relationship with the consumer, and/or,
  2. Has the infrastructure and budget necessary to conduct face-to-face encounters with consumers.
  Discussion:

  A key presumed advantage of requiring face-to-face identity proofing encounters is that it lowers the risk of mass or automatic attacks to obtain false credentials. In the virtual world, in which people can easily pose as others online, a requirement for in-person proofing has a strong appeal: It seems like the best way to establish a baseline identity of an individual. It raises the presumed commitment of the individual submitting to the proofing process. It raises the cost of a conducting a fraudulent "attack" on an individual identity, and it reduces the likelihood of remote, automated attacks from many sources or on many identities at once. Requiring presentation of commonly used documents (e.g., birth certificates, driver's licenses, and passports) sets a hurdle for registrants and brings into play a variety of laws that may be useful at a later time for enforcement or prosecution, if necessary.

  Caveats:

  However, this option comes with three critical caveats:

  • First, although dissuading misuse is a key goal for any such system, these same hurdles dissuade legitimate use as well. In-person proofing carries a cost and inconvenience burden for consumers, particularly those who face mobility or transportation barriers. Given the potential utility of providing consumers with electronic access to their health information and services, this outcome is not ideal and risks systematic underuse of PHRs. In-person proofing may be in tension with Principle 1, above, that the authentication process be available to as much of the population as possible.
  • Secondly, in-person identity proofing is a significantly costly and labor-intensive process, which many organizations are not well-positioned to perform. If in-person identity proofing were required of all organizations on the network, it would keep organizations that could offer potentially useful data or services from participating. This affects both large and small organizations. For example, the Centers for Medicare & Medicaid Services (CMS) – the nation's largest payer – has no direct way currently to conduct face-to-face identity proofing of its beneficiaries. Nor do most technology companies or web portals ever conduct in-person encounters with their customers.
  • The third – and most critical – caveat is that, although in-person processes are a widely accepted starting point for identity proofing, we could not find (much less validate) any measurement of their effectiveness. If there were such a measurement (in the manner of "errors per 100,000" or similar), it would enable useful comparisons between various forms of in-person proofing, and between in-person and remote forms of proofing. Our Work Group found a dearth of publicly available research backing up the accuracy of in-person proofing. The assumption that in-person proofing is acceptably accurate is not based on empirical understanding. And certainly, the stringency of methods for in-person proofing varies from one organization to another. In fact, the existence of an in-person proofing process may create a false sense of security if those checking credentials are not well-trained or audited. Recommendations 1B, 1C and 1D below attempt to address this problem.

• Approach 1B: Consider 'bootstrapping' of in-person proofing by other organizations: We recommend that entities in the health sector consider "bootstrapping" other in-person encounters by third-parties to establish the consumer's identity at acceptable levels of accuracy. We recommend that both current and potential holders of clinical data consider partnering with institutions that have effective authentication processes.

  Discussion:

  For many reasons, individual doctors' offices are not well-equipped to authenticate 300 million Americans. (Their main authentication procedures relate to confirming eligibility for health benefits.) However, there are other common places where in-person proofing can occur, including post offices, retail pharmacies, notary publics, and financial institutions. In the bootstrapping model, a laboratory could accept the authenticated identity of a consumer who had first been authenticated by another one of these parties. The entity would pass at least the assertion that the patient has authorized a copy of the medical records to be transferred. Note that if a system passes demographic details, it should never re-use existing identifiers. It would be potentially catastrophic, for example, to bind a consumer's PHR directly to a bank account number, as publication of the number would then compromise both categories of data.

  This is not a general-purpose solution, as the issues of transparency and liability will have to be worked out as business relationships between the authenticator and the relying party that holds the consumer's health data. However, it would allow new interfaces to be offered to consumers for access to their records, and would do so without creating new proofing hurdles. (These kinds of relationships will probably form as point-to-point business agreements, rather than multilateral networks, at least at first.)

• Approach 1C: Consider alternatives to in-person proofing: Because there are no metrics to evaluate the quality of existing proofing systems, the data holder is, de facto, left to judge the acceptability of various methods. We recommend that data sources consider adopting remote proofing on their own, or rely on remote proofing from acceptable third parties (see Component 4 section below), when such proofing methods:

  1. Rely on combinations of at least two alternative methods or sources for validating identity that use separate data (i.e., don't use two different sources relying on Social Security Number or the same account number).
  2. Are optimized to minimize the rate of false positives (i.e., when the wrong person is granted access based on an identity not his own).
  3. Provide an alternative identity-proofing protocol to mitigate false negatives (i.e., when the right person using his correct identity is denied access nonetheless). In such cases, the person denied access in a remote-proofing protocol should be given an alternative means, such as in-person, to establish that he really is who he says he is.
  4. Take precautions to minimize risk to the consumer, including but not limited to:
     • Not requiring consumers to use existing account numbers as identifiers. After the initial proofing step, nothing should be communicated from the consumer to the identity proofer that could provide access to the consumer's account if intercepted by a third party.
     • Securely storing and limiting the number of parties privy to any "shared secrets" to the absolute minimum necessary.
     • Refreshing interrogation questions and "shared secrets" so as to avoid overuse.

  This is not meant to be a list but a guide. Security practices change, and the underlying concern should be to adopt practices that create the necessary security while minimizing the privacy risks of the security methods themselves.

  Discussion:

  Knowing when remote proofing is acceptable suffers from a Catch-22. The obvious threshold for remote proofing should be, at a minimum, "as good as or better than current practice." However, since there are no convincing metrics for current practice, it is impossible to say how any remote proofing system compares. With fake IDs readily available and with harried clerks often doing the checking, in-person identity proofing does not guarantee that any particular individual is who he claims to be. In some cases it is possible that remote proofing actually works better in defending against a determined attacker than current in-person proofing practices.

  There are examples, as with PayPal, where user-proofing is transactional (i.e., based on past or present transactions of information or money that serve to tie a person's identity to a location or service, such as a U.S. Mail box or a bank account), and requires no face-to-face encounter. This method is one of a subset of "Knowledge-based Authentication" (KBA) methods in which a consumer is identified by answering a set of questions only she could reasonably be assumed to know. Sometimes these questions involve historical information (past addresses, use of credit cards for certain transactions) and sometimes they involve information generated as part of the KBA process itself, as with the PayPal technique of generating specific deposits.

  The ideal situation would be to measure effectiveness of proofing by a numerical target, such as: "Wrongful issuance of credentials must be kept to an error rate below one in X," where X would be at least a thousand patients. (This metric would be a 99.9% deflection of false positives, in other words.) In the absence of such precision, for either in-person or remote proofing (see 1D, below), the decision about when and how to use remote proofing will necessarily be in the hands of the person responsible for the security of patient data, to be undertaken with two principles in mind: Minimize false positives, and don't rely on a single method.

  Our recommendation is that at least two methods or sources be used in remote proofing processes. (For example, the consumer presents authentication credentials issued to him by another institution and successfully responds to an online interrogation about information acquired through his relationship with a separate independent service.) This is because two methods are likely to have different strengths and weaknesses, thus raising the cost of an attack while lowering its chance of success. This is true for both defense (i.e., it's less likely that a criminal could fraudulently obtain knowledge or credentials in two places than in one) and for sustainability (i.e., if one method becomes compromised, the system would still have at least one untainted method still running, to which it could add new methods without starting from scratch).

• Approach 1D: Begin Federal research on identity proofing quality: This is not a recommendation to data holders, but to the federal government. We recommend that the National Institute of Standards and Technology (NIST), in collaboration with other interested agencies, study current identity proofing practice wherever consumers are given access to their records remotely to provide or create metrics expressing the effectiveness of those various methods.

  Discussion:

  The current administration has made increasing accessibility of electronic health records to providers and citizens a national goal, and the lack of well-understood and generally agreed-to authentication methods for consumers is clearly a hurdle. This recommendation is intended to lead to a benchmark for future proposed systems to meet or exceed, thus moving us out of the current situation of identity proofing ratified by habit, but uninformed by measurement.

• Recommendation 1E: Do not use clinical data in the proofing process: As a matter of privacy policy, we recommend against using clinical data as validation data in a proofing process. The reasons for this are articulated in the Connecting for Health paper Linking Health Care Information: Proposed Methods for Improving Care and Protecting Privacy.Available online at: http://www.connectingforhealth.org/assets/reports/linking_report_2_2005.pdf.

Upon successful completion of identity proofing, it is necessary to issue acceptable tokens or identifiers to the consumer.

• Recommendation 2A: Bind the consumer's identity in such a way as to facilitate later authentication: At the time of initial proofing, the capture and retention of copies of the documents allows for re-verification if needed at a future time. If in-person visits are used in identity proofing, they present an opportunity to capture a biometric indicator, such as photographs or fingerprints.

  Discussion:

  This process of connecting or binding of particular information or attributes to a particular physical person, when combined with system monitoring, can provide improved ability to discover certain types of fraud attempts in which attributes are used by multiple registrants. However, it is important to note that improved information collection, of any sort, also raises the requirements for securing the database where the records are stored. Improvements in knowledge-based authentication methods generate, as an inevitable side effect, more stored knowledge about the consumer – knowledge that must be held securely to prevent near-term defeat of the authentication system itself and to prevent identity theft. Although database security is not in the scope of this paper, we note that care must be taken to evaluate the security of the data held in aggregate, as well as the security of person-by-person authentication.

  Less reliable, although at times more economically practical, are password reminders as "shared secrets" that can be used to support later authentication, or password reset requests. A common example is for the consumer to be forced to answer questions such as pet names or mother's maiden name. Care must be taken that these not be based on common questions that can be easily guessed or snooped. Another possible source of shared secrets are questions the service asks of the consumer. For example, PayPal makes two small deposits in a new user's account, then asks that the user report those amounts back to PayPal. This removes the risk of trivial guessability, though it requires a higher degree of integration with the financial system.

  Interesting work is being done on "zero-knowledge" authentication systems, which reduce or eliminate the need for knowledge-based secrets to be held by the authenticating party. In a zero-knowledge system, the consumer proves who he is by using a secret that only he knows to perform a task that he could only perform with that secret. (Imagine that you see someone unlock a door that you know can open with only one key. You could conclude that the person has that particular key without you needing to see a copy of the key yourself.) "Zero-knowledge"-based systems have not yet been widely deployed, and have significant management issues in their current implementations. Still, they should be watched closely, as they may provide a way to increase authentication security without also increasing the privacy risk to consumers that comes with knowledge being held about them in various authentication databases.

• Recommendation 2B: Choose an appropriate token or identifier: There are a variety of credentials available. PINs, cards, tokens, fobs with RF chips, antennas, and fingerprints are a few examples of a rapidly growing array of tokens.

  Discussion:

  Many different types of tokens or identifiers can be used to good effect in authentication processes. Much depends on the budget and infrastructure of the token-issuer and the tolerance of consumers to remember and use the token appropriately.

• Recommendation 2C: If using passwords as tokens, enforce 'strong' passwords: Requiring and enforcing rules to create strong passwords The following documents contain useful information about the issuing of tokens, including strong passwords:
  
  NIST Special Publication 800-63: Appendix A-Estimating Password Strength and Entropy, pp. 46-53. Table A-1: Estimated Password Guessing Entropy in bits vs. Password Length, p. 53. Accessed online on May 3, 2007, at: http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf.
  
  Password Strength, Wikipedia. Available at: http://en.wikipedia.org/w/index.php?title=Password_strength&oldid=154706929.
  
  National Institutes for Health, Password Policy for eRA. Accessed online on May 3, 2007, at: http://era.nih.gov/docs/NIH_eRA_Password_Policy.pdf.
  
  NIST Special Publication 800-12: Chapter Sixteen - An Introduction to Computer Security - The NIST Handbook: Identification and Authentication. Accessed online on May 3, 2007, at: http://csrc.nist.gov/publications/nistpubs/800-12/800-12-html/chapter16-printable.html. – i.e., passwords that are not easily guessable – is one of the first relatively easy steps that will dramatically increase the security of the username and password token.

  Discussion:

  The username and password combination is the most commonly used token. Extremely valuable and potentially risky transactions are conducted millions of times each day employing the protection of username and password. Many of the tokens and identifiers listed in Recommendation 2B are essentially variations on the concept of username and password, incorporating a variety of technologies to improve on the basic concept. Used appropriately, the username and password combination provides significant protection at very moderate cost and user inconvenience. However, if unguided by a set of guidelines or password requirements, many consumers tend to create easily guessable passwords and otherwise create the opportunities for compromise of their identity.

  Many systems now prevent the use of dictionary terms as passwords, or consecutive or repeating strings of numbers or letters or other easily guessable phrases. Some require the use of at least one number, a letter and another keyboard character. Some systems will provide a rating of the strength of the password as it is created by the user. The fundamental challenge with strong password requirements is that they not only make it harder for illegitimate users to guess a password, they can make it harder for the legitimate user to remember it. If strong password requirements are too onerous, they may encourage legitimate users to compensate through insecure practices, such as writing down a password and leaving it next to an unattended computer.

  It is increasingly common to supplement the username and password combination with monitoring of the requesting machine (e.g., source IP address, machine and browser characteristics). Such monitoring, which we discuss further below, requires no additional issuing of tokens to the user.

• Recommendation 2D: Limit attempts on passwords: Given sufficient time, access, and attempts, any password will eventually succumb to attempts to guess it. Limiting the number of consecutive and total attempts to enter a password, requiring periodic changes to the password, and other relatively low-cost, relatively low-inconvenience requirements for use of passwords make password guessing an unacceptably difficult approach to compromising tokens.

• Recommendation 2E: Establish a clear policy on requirements for password changes: Although an inconvenience to end users, it may be reasonable to require consumers to create new passwords at regular intervals. Each system should decide locally whether to enforce a policy requiring that consumers change their passwords over time. However, if such policies are enforced, it's critical that consumers be given clear explanations on the methods and reasons for resetting their passwords.

  Discussion:

  The value of tokens can diminish over time. For example, many private and government organizations still use Social Security numbers not only as identifiers but also as tokensThe principal reason Social Security Numbers (SSNs) should not be used as tokens is that, if this approach is taken, then one number is used to provide the public and secret parts of authentication (i.e., you have an SSN that points uniquely to you, but you must reveal it as proof that you have it.) Without being accompanied by a second, secret token such as a PIN, the SSN is damaged in regard to authentication by the very use that makes it otherwise worthwhile. In addition, no one token should be relied on too heavily, as such ubiquitous use will increase the focus of malevolent actors on compromising that token, and any compromising of such a token will have disproportionately negative effects., and it is precisely because of this ubiquity of uses that Social Security numbers have been a boon to identity thieves. Similarly, if a consumer uses the same password and password reminder at every site visited, it is much less secure than if the consumer uses different secret codes at each site's login. On the other hand, consumers may have trouble coming up with strong passwords that they can remember, and the burden of having to do so frequently could drive down utilization. The value of forcing consumers to change passwords is hotly debated, and our work group did not feel strongly about making a recommendation one way or the other.

It is important to perform periodic or ongoing processes to continually improve upon the initial proofing and to weed out compromised identities.

• Recommendation 3A: Conduct appropriate ongoing monitoring: Ongoing monitoring is an essential third component of appropriate authentication because of inherent weaknesses in the first two components (i.e., identity proofing and issuing of tokens). Given the widespread compromise of documents used for initial identity proofing and the large and growing incidence of identity crimes, the function of authentication should be thought of as an ongoing process rather than a gateway to be passed through one time. Once the consumer's identity is proofed and the token is issued, systems should establish the behavior patterns of individuals and alert authorized parties when behavior falls out of the established pattern. For example, credit card companies have algorithms to detect sudden changes in charging behavior, triggering a telephone call to the consumer to investigate possible fraud.

  Discussion:

  Identity proofing is often used as a "gateway" process. It is merely a perimeter defense, performed once and not revisited. Once identity proofing is completed, a registrant is an "insider" of the system. And there is often much secondary reliance on this initial proofing, such as airport security relying on a state-issued driver's license. In the Digital Age, the outside/inside relationships change continually. Allowing network access to partners, customers, users, and some unintended participants quickly renders perimeter defenses insufficient. Additionally, much of the fraud and abuse comes from people accurately identified or from identities that were compromised after the initial proofing process, as well as from "inside" authorized users.

  There is a robust and active population that continually probes and prods for opportunities to compromise systems and almost immediately shares with others any new intelligence gained. The risks and threats to systems change continuously. The practices and processes to respond to these threats must likewise change.

  The automated ability to monitor individual behavior for fraud varies significantly from organization to organization, depending in part on the type of organization, what data it captures, and what it is permitted to do with the data. Valuable techniques include analysis of transaction history and location, keystroke patterns, and others. Detailed recommendations would rapidly become dated and ineffective. Decisions about an ongoing monitoring process must be made locally. The U.S. government provides some guidance for ongoing monitoring as an integral part of an authentication process in the NIST Special Publication 800-100, Information Security Handbook: A Guide for Managers.NIST Special Publication 800-100 - Information Security Handbook: A Guide for Managers, pp. 14-15. Accessed online on May 3, 2007, at: http://csrc.nist.gov/publications/nistpubs/800-100/SP800-100-Mar07-2007.pdf.

  Behavior pattern monitoring can include information about the method of login (e.g., consumer's usual IP address, machine and browser type, etc.), or information about the types of resources or data that the consumer typically accesses.

• Recommendation 3B: Enable consumers to view an immutable audit trail: Consumers can become powerful allies in detecting identity fraud when they have access to the transaction history of their accounts. We recommend that Consumer Access Services and PHR offerers provide authenticated consumers with online access to an immutable audit log displaying all accesses and data transactions involving their account.

  Discussion:

  Consumers now are able to review their own credit reports online, providing an important and highly invested check on potential fraud or errors. This recommendation is in keeping with Principle No. 3 of this document. The Connecting for Health Common Framework document, Auditing Access to and Use of Health Information Exchange, provides some guidance in this area of immutable audit.Available online at: http://www.connectingforhealth.org/commonframework/docs/P7_Auditing_Access.pdf.

When relying on a third party to perform proofing or issuing of tokens, or both, some mechanism of audit and redress is essential to establishing a chain of trust.

• Recommendation 4A: Ensure that third parties are "observable" in how and how well they are performing identity proofing, token-issuing, and ongoing monitoring or any related services to authenticate consumers: One recommended practice is to have a contractual commitment for the parties to notify each other if either detects system compromise above a certain threshold or fails to comply with agreed procedures.

  Discussion:

  A fundamental premise of the Common Framework for Networked Personal Health Information paper is that Consumer Access Services will emerge to help consumers "network" their PHRs with connections to multiple sources of health data and services. In order to facilitate the consumer's requests for digital copies of his information from Health Data Sources, all parties must be assured of the individual's identity and bona fide authorization to share data. Simply put, such transactions require "trust."

  It will be impossible to trust and rely on any third-party's authentication if those third-parties' practices are not observable either directly among contracted parties or via some industry-accepted auditing and validation mechanism.

• Recommendation 4B: Ensure a mechanism for enforcement and redress for bad actions: There needs to be a commonly accepted mechanism, agreed upon in advance, to redress unacceptable practices and eject bad actors.

  Discussion:

  Audit, enforcement, and redress are general issues for Consumer Access Services, not just with the task of authentication. All this is framed against the larger issues of binding Consumer Access Services to policies and accountability generally, and against the general fragmentation of the health care industry (a fragmentation that may increase as Consumer Access Services enter the picture).

• Recommendation 4C: Consider federation and/or other contractual means to address Recommendations 4A and 4B:

  If the Health Data Source:

  • Has not done its own identity proofing and token-issuing for a consumer, and;
  • Is considering a request from a Consumer Access Service to pass information on the consumer's behalf, and;
  • Does not have sufficient direct means to monitor or observe the Consumer Access Service's authentication practices per Recommendations 4A and 4B…

  Then, we recommend that:

  • The Health Data Source should have strong mechanisms in place for identifying the Consumer Access Service itself.
  • The Consumer Access Service should be contractually bound to policies or to a group that sets and enforces shared policies, (e.g., the E-Authentication Federation (EAF), Electronic Authentication Partnership (EAP), or similar.)
  • The Consumer Access Service should use at least EAP Level 2, or equivalent.

  We believe the EAF/EAP is a good framework for a discussion on finding an acceptable degree of authentication certainty and policy enforcement. Although some organizations might choose to join the EAF or the EAP, there is likely no one-size-fits-all answer. Different business relationships and different consumer populations will likely require a variety of authentication services for their transactions. Some consumers may even demand higher-level authentication stringency for certain services.

  Discussion:

  We emphasize that the above scenario is not the only way to approach the problem. (See Appendix F for a draft architecture discussion.) Point-to-point trust is conceptually simplest from the point of view of any given pair of actors, but pairwise trust exposes the system as a whole to daunting complexity. Similarly, a single national actor coordinating trust on behalf of everyone is not feasible at this time, both because of the realities of fragmentation and the business context, and also because the policing problem for a single actor is acute. If these two extremes are in fact impractical, this suggests some sort of chain of trust with mutual policing, with various actors monitoring one another, possibly in contractually arranged groups.