Personal Address Manager Service

This Standard is being developed according to the VRM Use Case guidelines.

When possible, elements of the Requirements Model are incorporated directly herein. Otherwise, a link is provided for downloading supporting documents.

Status

Working Draft

Schedule

Proposed Schedule for First Draft

Item	Who?	Comment	2/20	3/5	3/19	4/2	4/16	4/30	5/14	5/28
Use Case Description	J. Andrieu		XXX
Actors	J. Andrieu		XXX
Roles	J. Andrieu		XXX
Role Map	J. Andrieu			XXX
Role Profiles	J. Andrieu			XXX
High Level Use Cases	TBD				XXX
Scenarios	TBD				XXX
Abstract Use Case Narratives	TBD					XXX
Specific Use Case Narratives	TBD					XXX
Use Case Diagrams	TBD						XXX
Use Case Maps	TBD						XXX
Constraints and Requirements	TBD							XXX
Technology Review	TBD								XXX
Formats and Protocols	TBD									XXX

Target date for announcing first complete draft: VRM Workshop June 2008

Description

The Personal Address Manager Service (PAM Service or PAM) allows individuals (and organizations) to manage their postal address in one place and have it automatically be propagated and/or used by others, as authorized.

Actors

A list of all Actors supported by the system.

Individuals

people who use a postal address as a point of contact for receiving correspondence. Also individuals who wish to contact others through a postal address.

Organizations

entities who rely on a postal address as a way to reach individuals with whom they have existing relationships. Could be a for-profit corporation, sole proprietorship, non-profit, or government agency. Also entities who wish to contact others through a postal address.

Note that this service is specifically NOT designed to support organizations who rely on postal addresses as a way to reach individuals with whom the want to create a relationship, who we will refer to as "Direct Marketers" for lack of a better term. For this Service, Use Cases which support Direct Marketers are explicitly out of scope.

Roles

Addressee

Anyone who use a postal address as a point of contact.

Addressor

Anyone who wants to reach an Addressee at their postal address.

AddresseeDelegate

Anyone authorized by an Addressee to act on their behalf. Specializes Addressee.

AddressorDelegate

Anyone authorized by an Addressor to act on their behalf. Specializes Addressor.

AddressRequester

Individuals or organizations who request a postal address on demand for either immediate or perpetual use. Specializes Addressor.

AddressSubscriber

Individuals or organizations who subscribe for updates to an individual's address. Specializes Addressor.

OnlineAddressSubscriber

AddressSubscribers who will receive updates electronically. Specializes AddressSubscriber

OfflineAddressSubscriber

AddressSubscribers who will receive updates via postal service. SpecializesAddressSubscriber

Role Map

A visual representation of the supported Roles and their relationships to one another.

Profiles

A detailed description of each Role's expectations, capability, and requirements for the system. Developed to enough detail to distinguish what this particular user needs from the system design.

Addressee

• Average Internet user. Understands websites, email, etc., but doesn't necessarily understand any of the underlying technology (HTML, http, SMTP, etc.). Web friendly but not especially tech savvy.
• Updates address on average once/year, although many users will spend years in between usage.
• Authorizations occur more frequently, so that interface is more familiar.
• Has list of authorized Requestors/Subscribers for address updates in various formats and for various services (DMV, utilities, magazine subscriptions, websites, etc.)
• Could have addresses anywhere on the planet.

Addressee Delegate

• Specializes Addressee
• Authorized by the Addressee to manage authorizations and edit addresses.
• May serve as delegate for multiple addressees
• Can be expected to be moderately more tech-savvy than the average Addressee, but they could have the role just because they are the person in the household with the most geek skills.

Addressor

• Anyone who wants to reach the addressee via their current postal address as managed in the Personal Address manager.
• May be offline or online.
• Selected by virtue of the Addressee's desire to use the Personal Address Manager for this Addressor.
• Could be anywhere on the planet.

Addressor Delegate

• Anyone authorized by an Addressor to act on their behalf.
• Typically this is a shipping or mailing service
• High technical sophistication
• Likely to have automated systems for managing large numbers of Addressees and Addressors.

AddressRequester

• Specializes Addressor
• Internet-savvy entity who wants to make sure they always have the latest postal address for contacting users. Capable of implementing (or using) fairly sophisticated web services
• Manages tens to millions of users... small or large organization or individual.
• Will use the Personal Address Manager for on-demand queries.
• Sometimes handles mailings in-house, sometimes through third-party mailing house.

AddressSubscriber

• Specializes Addressor
• Maintains own database and will not be relying on the Personal Address Manager for on-demand usage.

OfflineAddressSubscriber

• Specialized AddressSubscriber
• No Internet access expected or required.
• Will be reached via postal mail.

OnlineAddressSubscriber

• Specialized AddressSubscriber
• Average Internet User
• Has email address
• May have contact manager software capable of more sophisticated processing
  • Or may manually process incoming email updates

High Level Use Cases

A list of all supported use cases in the system, identifying all focal and required use cases by title, ordered by priority.

1. AddressChanger Changes Address (base case)
2. AddressChanger Manages Address Holder Permissions (and data subsets)
3. AddressChanger Accesses Audit Report
4. AddressChanger Reviews Address
5. AddressUser Gets Current Address (pull)
6. AddressUser Subscribes to Address Changes (push)

Scenarios

Prose descriptions of a user's interaction with the system as one example of the Use Case that explains the context, the interaction, and the benefit. Each Use Case requires at least one Scenario.

AddressChanger Changes Address

Scenario 1

Bob just got a new job and is moving from Los Angeles to San Francisco and recently selected his new home. He has an address to send to existing vendors. He visits the Change of Address Service and inputs his new address and all of the vendors he wants outgoing notices for (with appropriate account #s and other identifying information). The service confirms the new address, date of the move, and the vendors it will contact. A few vendors require contact information (they aren't in the system) so Bob provides it. The system sends out the notices and keeps track of delivery so Bob can later verify receipt of the update.

Possible Variations

New User verses returning user? Address changes initiated by a visit to a vendor rather than the CoA service?

Discussion

What is the most efficient and appropriate way for users to manage their account information for each vendor? Telling the DMV (department of Motor Vehicles, the service that provides driver's licenses in California) that John Doe is moving is useless if they don't know the driver's license number as well. Seems like this should be jointly specified by the vendor, when possible. That's easier if the vendor initiates the authorization process (catalyzing the creation of the record in the COA service). However, for real-world, off-line vendors, we probably need a simpler upload or manual entry. What about exports/uploads from bill pay services such as are common at banks or financial management services like Mint or Wesabe? - Joe Andrieu

Also, the scenario presumes outward-bound propagation of the address. However, that doesn't match some scenarios we've discussed where the address is instead provided on-demand to the AddressUser. Since we can't assure that every AddressUser is capable of on-demand, shouldn't we assure that both on-demand and outbound notifications work? -Joe Andrieu

Abstract Use Case Narratives

An implementation and technology-free chronological ordering of user intention and system responsibilities for a particular use case. Based on one or more specific Scenarios, define the specific, yet technology-free, interactions that are required for the use case. These narratives will be normative, that is, they will ultimately define the requirements of the functioning system.

AddressChanger Changes Address

User Intention	System Responsibility
1. AddressChanger decides to move.
2. AddressChanger expresses new address to system (optionally including scheduling information).
	3. System assures AddressUsers get the new address when they need it.

WikiQuestion/suggestion: let's set this up as a template.

Specific Use Case Narratives

Implementation-specific sequences of user action and system response for a use case. These narratives will be illustrative, that is, they will show how a particular set of technologies can implement a particular use care--or how a specific set of technologies might require or suggest changes to the use case.

Use Case Diagrams

Both abstract and specific use cases may be diagramed visually to represent the transaction flow between various system components. For abstract use cases, the diagrams will be normative. For specific use cases, they will be illustrative.

Use Case Maps

A visual representation of the multiple use cases that comprise a particular service and their relationship to one another.

Constraints & Requirements

In addition to responding to specific use cases appropriately, every Service shall define its own set of constraints and requirements to complete the specification of the service. Many requirements will be applicable to most, if not all, VRM services, such as those inspired by tenets of data portability and user-centric identity.

When mapping out the first Change of Address use case, it became clear that the core Use Cases were already substantially met by such online services as Plaxo and LinkedIn, raising the question of what would actually make a Change of Address service VRM-compliant. That led directly to a handful of simple requirements that assure the user and vendors have appropriate access and controls.

1. Address stored independently of any particular service provider
2. AddressChanger can choose who stores canonical source (self-storage ok)
3. Data should be in an open format and portable without data or service loss
4. Data transfer and use is always under user control
5. AddressUsers can discover the appropriate CoA service for each user