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
Schedule
| 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 | J. Andrieu | XXX | ||||||||
| Scenarios | J. Andrieu | XXX | ||||||||
| Abstract Use Case Narratives | J. Andrieu | XXX | ||||||||
| Specific Use Case Narratives | J. Andrieu | XXX | ||||||||
| Use Case Diagrams | J. Andrieu | XXX | ||||||||
| Use Case Maps | J. Andrieu | XXX | ||||||||
| Constraints and Requirements | J. Andrieu | XXX | ||||||||
| Policy Requirements | J. Andrieu | XXX | ||||||||
| Technology Review | J. Andrieu | XXX | ||||||||
| Formats and Protocols | J. Andrieu | XXX |
Target date for announcing first complete draft: VRM Workshop June 2008
Description
The Personal Address Manager Service (PAM Service or PAM) allows anyone to manage their postal address in one place and have it automatically be propagated and 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
- Administrator
- An individual with "administrator" privileges at the PAM service provider.
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, forming an operational context for that particular role. Developed to enough detail to distinguish what this particular role 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 required use cases by title.
1 Addressee Manages Address 1.1 Addressee Creates Address 1.2 Addressee Reviews Address 1.3 Addressee Changes Address 1.4 Addressee Deletes Address
2 Addressee Manages Addressors 2.1 Addressee Uploads Addressors 2.2 Addressee Authorizes Addressor 2.3 Addressee Manages Addressor Permissions 2.4 Addressee Deletes Addressor
3 Addressee Manages Delegates 3.1 Addressee Authorizes Delegate 3.2 Addressee Unauthorizes Delegate 3.3 Addressee Removes Delegate
4 Addressor Manages Delegates 4.1 Addressor Authorizes Delegate 4.2 Addressor Unauthorizes Delegate 4.3 Addressor Removes Delegate
5 Addressor discovers Personal Address Manager service for Addressee 6 Addressor Requests Authorization 7 Delegate requests authorization 8 AddressRequester Requests Current Address 9 AddressSubscriber Activates Subscription 10 AddressSubscriber Deactivates Subscription 11 Addressee Accesses Activity Log 12 Addressor reports address change 13 Addressee acknowledges address change 14 Addressee downloads data 15 Addressee authorizes automated export 16 AlternativeServiceProvider downloads current dataset 17 AlternativeServiceProvider uploads revised dataset
Scenarios
A Scenario is a 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 scenario should be a short paragraph, containing the following elements:
- Why the actor is engaged in this use case? What happened? What motivated them to contact the system and begin the transaction?
- What does the actor do? Identify the keys actions taken by the actor during the use case.
- What does the actor get out of the system? Include both the actor's benefits and what the system does for them.
The goal is to have a simple, straightforward picture of why the Use Case matters and what happens to fulfill the Actor's needs. This should capture both the human elements of who & why and the functional elements of actions & results.
Each Use Case should have at least one scenario. Please number the scenarios, restarting the numbering for each Use Case.
Use Case 1 Addressee Manages Address
Scenario 1 General Address Edit
Betty needs to update her address at her Personal Address Manager. She goes to her service provider's website, authenticates herself using OpenID, and pulls up the Address Management interface. She edits one or more addresses and logs off. The system records the edits, both in the datastore and in the log files, and propagates update messages to current subscribers.
Use Case 1.1 Addressee Creates Address
Specializes Use Case 1 Addressee Manages Address
Scenario 1 Bob creates first address
Bob decides to try out the personal address service because he is about to move. He signs up with a service provider, creates a home address using his current address--specifying not to send updates yet--and confirms his email address with the provider. The system sets up a new account, discoverable by authorized Addressors and sends a confirmation email to Bob. (Bob's next action is likely to be one of the variations of Use Case 2 Addressee Manages Addressors)
Scenario 2 Betty creates alternative address
Betty is going to be sending a number of purchases to her Mother's place over the next few months. She goes to her Personal Address Manager and adds a new Alternative Address, giving it a name (Mom's Address), and making sure her current address remains the default for new purchases. The system records the new address, making it available to authorized Addressors who specifically ask for Betty's "Mom's Address". Betty's next step might be Use Case 2 Addressee Manages Addressors or she might just wait until she is purchasing an item that she wants to ship to Mom before authorizing any Addressors.
Use Case 1.2 Addressee Reviews Address
Scenario 1 Betty double checks her address
Betty is wondering if the current address is correct. She logs in and reviews the addresses currently presented to authorized Addressors. The address is correct, so she does nothing further. (If it was incorrect, the next step is likely Use Case 1.3 Addressee Changes Address
Use Case 1.3 Addressee Changes Address
Scenario 1 Bob gets a new job
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 Personal Address Manager Service and inputs his new address. The service confirms the new address, date of the move, and the subscribers it will contact, logging the transaction. The system sends out the notices and keeps track of delivery so Bob can later verify receipt of the update. If Bob needs to manage Addressors, he likely goes to one of the variants of Use Case 2 Addressee Manages Addressors.
Use Case 1.4 Addressee Deletes Address
Scenario 1 Betty deletes Mom's address
Betty decides she no longer wants her Mother's address listed. She logs in and deletes it. The system removes the address and logs the transaction.
Use Case 2 Addressee Manages Addressors
Use Case 2.1 Addressee Uploads Addressors
Use Case 2.2 Addressee Authorizes Addressor
Use Case 2.3 Addressee Manages Addressor Permissions
Use Case 2.4 Addressee Deletes Addressor
Use Case 3 Addressee Manages Delegates
Use Case 3.1 Addressee Authorizes Delegate
Use Case 3.2 Addressee Unauthorizes Delegate
Use Case 3.3 Addressee Removes Delegate
Use Case 4 Addressor Manages Delegates
Use Case 4.1 Addressor Authorizes Delegate
Use Case 4.2 Addressor Unauthorizes Delegate
Use Case 4.3 Addressor Removes Delegate
Use Case 5 Addressor discovers Personal Address Manager service for Addressee
Use Case 6 Addressor Requests Authorization
Use Case 7 Delegate requests authorization
Use Case 8 AddressRequester Requests Current Address
Use Case 9 AddressSubscriber Activates Subscription
Use Case 10 AddressSubscriber Deactivates Subscription
Use Case 11 Addressee Accesses Activity Log
Use Case 12 Addressor reports address change
Use Case 13 Addressee acknowledges address change
Use Case 14 Addressee downloads data
Use Case 15 Addressee authorizes automated export
Use Case 16 AlternativeServiceProvider downloads current dataset
Use Case 17 AlternativeServiceProvider uploads revised dataset
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.
Addressee Changes Address
| User Intention | System Responsibility |
|---|---|
| 1. Addressee decides to move. | |
| 2. Addressee expresses new address to system (optionally including scheduling information). | |
| 3. System assures Addressors 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 VRM 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 set of use cases, it became clear that the a few of 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 Personal Address Manager service VRM-compliant. That led directly to a handful of simple requirements that assure the user and vendors have appropriate access and controls.
- Address stored independently of any particular service provider
- Addressee 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
- Addressors can discover the appropriate CoA service for each user
Policy Requirements
Implementations must meet the following policy requirements.
Administration & Operations
- Specified Data Visibility--Service providers must specify and implement either a visible of invisible data strategy.
- Visible Data - Data stored with the Service provider is visible to administrators.
- Invisible Data - Data stored on the Service is encrypted and not visible to administrators.
- Constrained & Logged Data Modification--All data modifications must only be made through explicit Roles as defined in the specification. All data modifications must be logged in a system activity log. All system activity must be auditable by users and their delegates.
Representation & Warranties
Service providers must explicitly specify, represent, and legally warrant their policies in the following areas.
- Privacy
- Security
- Survivability
- Accountability
Note: these areas need to be more clearly and completely specified. See the [Global Services Specifications] as informative of the type of self-asserted warranties will be required by Personal Address Manager Service providers.
Technology Review
Review relevant technology and existing services, highlighting how they inform our development, either by highlighting successful ideas or as examples of what we should avoid.
Services
- LinkedIn http://www.linkedin.com
- Plaxo http://www.plaxo.com
- Ryze http://www.ryze.com
Technologies
- FOAF http://www.foaf-project.org
- hCard http://microformats.org/wiki/hcard
- OAuth http://www.oauth.net
- OpenID http://openid.net
- XDI http://en.wikipedia.org/wiki/XDI
- CardSpace http://www.microsoft.com/net/cardspace.aspx
- Liberty Alliance Identity Web Services Framework (ID-WSF) http://www.projectliberty.org/liberty/specifications__1
Organizations/Movements
- DataPortability.org http://www.dataportability.org
- Microformats http://microformats.org
- Liberty Alliance Project http://www.projectliberty.org
- OpenLiberty.org http://www.openliberty.org
- Concordia Project http://www.projectconcordia.org
Formats & Protocols
We will need formats for
- Representing an address (machine readable)
- Presenting an address (human/postal service readable)
- Personal Address Manager metadata
- Address Metadata
- Address Name
- Authorizations
- Log data
- Address Metadata
We will need protocols for
- Authenticating Addressees, Addressors, and delegates
- Authorizing Addressors & Delegates
- Service discovery
- Inbound human services
- most likely web pages
- Inbound automated services
- Outbound automated services