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.
|Use Case Description||J. Andrieu||Complete?||XXX|
|High Level Use Cases||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|
Target date for announcing first complete draft: Internet Identity Workshop 5/12/2008
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.
A list of all Users supported by the system, specifying one or two focal users.
- Individuals who use a postal address as a point of contact for vendors.
- 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.
A visual representation of the supported users and their relationship to one another.
- 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.
- 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.
High Level Use Cases
- AddressChanger Changes Address (base case)
- AddressChanger Manages Address Holder Permissions (and data subsets)
- AddressChanger Accesses Audit Report
- AddressChanger Reviews Address
- AddressUser Gets Current Address (pull)
- AddressUser Subscribes to Address Changes (push)
AddressChanger Changes Address
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.
New User verses returning user? Address changes initiated by a visit to a vendor rather than the CoA service?
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
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
Use Case Diagrams
Use Case Maps
Constraints & Requirements
- Address stored independently of any particular service provider
- AddressChanger can choose who stores canonical source (self-storage ok)
- Data should be in an open format and portable without data or service loss
- Data transfer and use is always under user control
- AddressUsers can discover the appropriate CoA service for each user