Group Admins

  • Avatar Image

Online Constituent Identity Working Group

Public Group active 6 years, 5 months ago

Best Practices

Last edited by Wayne on 17 December, 2010 at 20:17

This is version 1.0 of this document. It was sketched out at the Workshop and re-written by Josh Tauberer. Now, we are seeking your input so that we can move it to the next level. Follow one of these links to comment.

Goal Statement 

To provide congressional offices with a method for trusting that incoming emails (online incoming communications) are from unique constituents. 

 Disclaimer: This document is speculation only and does not represent the opinions of the employers of any of its authors.


Technology is providing new methods for constituents to communicate with their representatives in Congress. In 1993, Sen. Chuck Robb was the first Member of Congress to have an email address. With the cost of an electronic communication so cheap, not the least of which in terms of effort on the part of the constituent, the number of electronic letters to Congress has skyrocketed. The Congressional Management Foundation (CMF) reported that nearly half of all Americans wrote a letter to Congress between 2003 and 2008. While at first, back in the 1990s, email addresses became more popular for Congressional offices, eventually web forms took over as for most offices the only method for a constituent to send a letter to their representatives using the Internet. 

 Web forms provide a first level of screening to ensure offices receive letters that they can process: those that contain a name and a physical postal address in their district (or state). This highlight’s the importance to Members of Congress of knowing whether a letter is coming from a constituent. Of course, in any given case they do not know whether the name and address provided was that of the sender of the message — they do not check when the message is received. At best, and this is in fact a public relations worst, they may find out when a letter is returned by the unhappy constituent whose identity was stolen. But in practice, identity spoofing is thought to be extremely rare.

  Or at least, it is rare for now. Names and addresses of registered voters can be relatively easily obtained from local elections boards, and as the volume of constituent communication rises it becomes more and more likely that someone would use this information to spoof the identities of constituents to influence the perceived public opinion as it appears to the Member of Congress. We may see in the coming years Members of Congress needing a means to preemptively verify the identity of the sender. 

 Importantly, what will concern Members of Congress is not what checks are in place but what the overall error rate is, i.e. the number of times a non-constituent’s message gets treated as a constituent’s (and conversely when a constituent’s message gets rejected because it was classified as a non-constituent’s). There is no fool-proof verification; the error rate will never be zero and verification becomes more costly as the error rate is pushed down. Currently, whatever the error rate is for validating that the address is within the representative’s district, it must be low enough that there is little current motivation to perform additional verification steps. Any technology applied to verifying constituent identity must be below a desired error rate, but not much more. (Another way to think about this problem is not as a discrete yes-no verification with a global error rate, but instead that each identity could have associated with it a likelihood of being correct. For simplicity, we stick with yes-no verification in this document.) 

 The problem is made worse by the fact that we are on the verge of another technological change in message delivery. The vast majority of those contacting Congress did so at the request of a third-party, such as an advocacy organization which they subscribe to, according to CMF. Advocacy organizations act in an important role of providing research and performing and coordinating advocacy on behalf of their members. And to advance their cause, they have a strong interest in providing to their members the easiest means by which their voices can be heard by government officials. Directing their members to the web forms of their Congressional representatives has been tried, and advocacy organizations now instead turn to a new class of vendors who provide the technological solution to collect constituent messages in one place more familiar to constituents and then deliver them to Members of Congress by essentially circumventing the web form. Many of these electronic letter delivery vendors have in turn come together through CMF’s Communicating with Congress project to develop a set of standards for delivering messages to Congress. The rationale is to be able to provide more information about the letters in a format that Congressional offices can process, but one end result is that there may be a proliferation of message delivery vendors.  

 From the point of view of constituent identity, the message delivery vendor separates the sender and recipient and puts the Member of Congress at a disadvantage by no longer being able to take any steps to verify the original sender. Whatever verification or digital identity information needed to check the constituent-hood of the sender must be acquired by the delivery vendor and then passed on to the Congressional office.


Purpose and Definitions

The purpose of this document was to outline the agents and the interaction between the agents in a technological solution to verifying unique constituent identity in online communications. For online communications, we have in mind letters in the form of an “email” in a general sense (independent of how those letters are delivered), sent from a constituent to their representative. A constituent is someone who is a resident of an electoral district, bearing in mind that not all constituents will have postal addresses. Finally, in terms of unique identity we mean that a Congressional office should be able to determine the constituent-hood of the sender and to be able to group together all letters sent by the same sender so that a single sender cannot send many letters that appear to come from many constituents (all subject to an error rate).

Additionally, this document will make use of the term identity attribute. This is meant to be a technical term which refers to a claim about some aspect of the sender’s identity combined with who is asserting the claim. In the current constituent letter process, the constituent asserts his own name and physical postal address. The problem Congressional offices face is that the sender cannot be trusted. The solution proposed here is to involve new agents who can assert identity information and be trusted.



Benefits for Congressional Offices

This document addresses the following limitations in current office constituent mail processing:

  • Lack of constituent-hood verification. Although offices can verify that the submitted address is within a Congressional district, they cannot verify that the sender lives at that address.
  • Lack of identity verification, meaning a single sender can create messages that appear to come from many constituents.
  • By requiring submissions through web forms, Congressional offices limit their ability to quickly aggregate messages for the purposes of sending replies and deriving counts. By opening the door for more technological help, third-parties delivering messages will be able to deliver messages that are more helpful for Congressional offices.

This document outlines the beginnings of a system which addresses the above problems. To adopt this system, Congressional offices should seek software vendors that implement and comply with this specification.



The Agents

The following diagrams illustrates the relationships between the agents, the constituent, and the Congressional office.



As you can see in the top diagram, there are four types of agents that play a role in a framework for verifying identity: 

 Congressional constituent communications software is the final receiving point for constituent communications. Known in the House of Representatives as Constituent Management Systems (CMSs) and in the Senate as Constituent Service Systems (CSSs), we call them here Congressional CRM Systems. The primary role of the Congressional CRM System is to receive a message and to check that any identity attributes provided can be trusted. 

 So-called “outside vendors” provide advocacy organizations with tools to encourage their members to write letters to Congress. These tools typically provide a form for individuals to compose their message — i.e. in place of Congressional web forms — and then in turn sends the message to the Congressional office. These software applications are called Message Originating Systems here. 

 Identity Providers are vendors who provide a means for individuals to authenticate themselves and then share information about themselves to a third-party. Examples include OpenID/OAuth providers such as Google and Facebook which provide third-party websites with information about the user’s account on Google (e.g. their email address) or on Facebook (e.g. posted photos). Other Identity Providers are able to provide the physical postal addresses of their clients. 

 The Trust Framework Provider is a single agent who helps Congressional CRM Systems determine who to trust by performing regular audits of Identity Providers and publishing the results. The Trust Framework Provider must be trusted in the off-line world to perform its duty.



 More details on each of these agents is provided in the following four sections.

Identity Providers

Identity Providers are vendors who are able to assert claims about a user’s identity. Such claims may be a user’s physical postal address, his phone number, or a unique identifier that identifies the user as distinct from other users known to the Identity Provider. In other words, an Identity Provider provides identity attributes.

Identity Providers must establish and maintain a relationship with the Trust Framework Provider described below.

Identity Providers will verify the indivdual at NIST Level of Assurance 2, which generally means the use of a username and password.



Trust Framework Provider

The Trust Framework Provider is the keeper and protector of this specification. It is responsible for auditing the agents so that the agents can make an informed judgement about which other agents to trust. 

The responsibilities of the Trust Framework Provider are to:

  • Maintain this specification and develop criteria for auditing Identity Providers and categorizing audit results on a spectrum of identity quality, such as based on error rates.
  • Audit the other agents — the Congressional CRM Systems, the Message Originating Systems, and the Identity Providers — to see that they are compliant with this specification.
  • Publish the audit results to the other agents electronically.
  • Document and publish the methods Identity Providers are using to assert their identity claims.



Message Originating Systems

The Message Originating System is that piece of software which interfaces with the sender of the message. It passes the message on to the Congressional CMS System. Message Originating Systems can be the web forms of Congressional offices themselves but may also be external web forms placed on the websites of advocacy organizations. (In principle, a Message Originating System may also be standard email software that has added functionality to add identity attributes to the message.)

The responsibilities of the Message Originating System are to:

  • Accept messages from constituents.
  • Collect identity attributes from Identity Providers and place the identity attributes in the message.
    • In this way, the Message Originating System is acting as a “relaying party” for the Identity Provider.
    • Recall that the identity attribute contains both information about the sender and who asserted it. The Message Originating System may send the user to several Identity Providers in order to gather multiple aspects of the sender’s identity. Each aspect is associated with the Identity Provider that asserted it.
    • When the Message Originating System collects information from the sender but does not verify it with an Identity Provider, it acts as the Identity Provider for that piece of information. That is, it is the asserting Identity Provider for that information attribute.
    • The Message Originating System must not add false identity attributes, i.e. identity claims not made by Identity Providers.
  • Add to the message identity attributes.
    • Three identity attributes are required:
      • The name of the sender
      • Either the sender’s Congressional District or his physical postal address
      • A unique identifier for the individual local to the Identity Provider that distinguishes him from other individuals known to the Identity Provider
    • When a physical postal address is used, the Congressional CMS System is responsible for determining the Congressional District of the address.
  • Send messages to the appropriate Congressional CRM System.
    • The Message Originating System must be able to handle the case of a rejected message.
  • Establish and maintain a relationship with the Trust Provider.


Congressional CRM Systems

The Congressional CRM System is that piece of software which processes the completed incoming messages for Congressional offices. It has the following responsibilities to be compliant with this specification:

  • It must accept messages from third-party Message Originating Systems.
    • In this way, it is acting as a “relying party” to accept identity attributes regarding constituent identity sent by the Message Originating System.
    • It must check that the sending Message Originating System meets its local trust policy, using information provided by the Trust Framework Provider.
    • It must check that the identity attributes present in the message are claimed by Identity Providers that meet its local trust policy, using information provided by the Trust Framework Provider.
    • It must send verification of receipt or refusal to the Message Originating System. Refusal may the the result of:
      • refusal to trust the Message Originating System
      • refusal to trust the provided attributes
      • malformed messages (such as missing identity attributes)
  • Accept messages from their own web forms, in which case the web form is acting as the message originating system.
    • In this case, the web form might provide the user the ability to add identity attributes to his message using locally trusted Identity Providers, such as by interfacing with Identity Providers in the same manner as a Message Originating System.
  • Process the identity attributes
    • When a physical postal address identity attribute used in place of a Congressional District attribute, the Congressional CMS System is responsible for determining the Congressional District of the address.
    • The unique identifier attribute allows the Congressional CMS System to identify multiple messages sent by the same sender.
  • When the Congressional CRM System is shared by multiple Congressional offices, provide Congressional offices with a method of granting and revoking trust to particular Message Originating Systems and Identity Providers as it sees fit.
  • Establish and maintain a relationship with the Trust Framework Provider.


Post Revisions Summary (8)

Only 6 of 8 revisions shown. Select the 'Revision History' button to view a list of all revisions.