Personal Address Manager Service

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

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

Description

The Change of Address Service (CoA Service or CoA) allows users to update their postal address once and have it automatically be propagated and/or used by their party "vendors" as authorized by the user.

A note on "vendors": in keeping with the guiding VRM principles, this Service will be defined in terms of how it enables mutually beneficial relationships between buyers and sellers. We will tend to view the focal users as "individuals" and third-party users as "vendors" so that we have a clear perspective as we build the system. However, it is to be understood that "individuals" could easily be business or government agencies, just as "vendors" could be other individuals seeking to use the system to keep in touch with friends.

This particular filter is designed to focus the conversation and accelerate standards development without limiting the ultimate scope of use.

Users

A list of all Users supported by the system, specifying one or two focal users.

AddressUpdater

Individuals who use a postal address as a point of contact for vendors.

AddressUser

Vendors who rely on a postal address as a way to reach individuals with whom they have existing relationships.

Note that this service is specifically NOT designed to support Vendors 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.

User Map

A visual representation of the supported users and their relationship to one another.

User Profiles

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

AddressUpdater

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 Vendor list for updates in various formats in various services: DMV, utilities, magazine subscriptions, websites, etc.

AddressUser

Internet-savvy vendor who wants to make sure they always have the latest postal address for contacting users. Capable of implementing fairly sophisticated web services, preferably using compliant third-party software (either OSS and commercial).

:Manages tens to millions of users... small or large business.
:Currently maintains its own customer database.
:Sometimes handles mailings in-house, sometimes through third-party mailing house.

OfflineAddressUser (proposed)

Non-Internet-savvy vendor, for whom the user wants to send an address update. How do we support this user? I think we should add it to the user list. - Joe Andrieu

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.

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.

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.

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.