Project VRM - User contributions [en]

VRM Workshop 2008

2008-07-06T13:08:24Z

Brett.McDowell: /* Sunday */

The first ProjectVRM Workshop (tag [http://technorati.com/tag/vrm2008 vrm2008]) will be hosted by ProjectVRM and the [http://cyber.law.harvard.edu Berkman Center] at Pound Hall at [http://law.harvard.edu Harvard Law School], on Monday-Tuesday 14-15 July. The event will go from 9AM to 5:30 on both days.

The purpose of the workshop is to bring people together and make progress on any number of VRM topics and projects. The workshop will be run as an "unconference" on the open space model, which means session topics will be chosen by participants. [http://en.wikipedia.org/wiki/Open_Space_Technology Here is the Wikipedia page on open space.]

In open space there are no speakers or panels: only facilitation with no agenda beyond helping participants make progress on their topics.

== Registration ==

The workshop is free. You can register through [http://vrmjuly2008workshop.eventbrite.com/ this EventBrite link]. Feel free to also add your name to the [[VRMWorkshop Attendees]] list.

== Proposed Schedule ==

=== Sunday ===
'''Non-hosted Dinner'''
* Location: TBD
* Time: TBD
* Attendees (please add your name here if you plan to attend so we can get reservations):
** Keith Hopper
** Iain Henderson
** Doc Searls
** Mark Scrimshire (tentative)
** [http://blog.joeandrieu.com Joe Andrieu]
** Chris Reynolds
** Brett McDowell

=== Monday ===

9AM to 5:30PM

After opening remarks, we'll each introduce ourselves to the group. After that we will have short briefings by people working on VRM projects. These briefings are required by the purpose of the workshop: to move VRM projects forward. We plan to keep these briefings under 5 minutes apiece, though some may go a bit longer. There is a lot of parallel work being done already with VRM, not just on specific projects but also in committees and conversations around various hot topics. It is essential that we get to know a few basics about who's doing what before we break off into the workshop discussions.

In open space workshops, topics are suggested by participants in an opening session attended by everybody. Participants write the title of their topic on a sheet of paper with a bold marker, add their name, then describe the topic to the group and post it on a large "spreadsheet" of times and session locations, located on a wall for everybody to see. Once up, these sessions can be combined or moved around as the sheet fills up.

One person in each session will take notes, either directly (or eventually) on the workshop wiki. At the end of each day somebody from each discussion session will report progress to the group.

7:00PM:
'''Non-hosted Dinner'''
* Location: TBD
* Time: TBD
* Attendees (please add your name here if you plan to attend so we can get reservations):
** [http://blog.joeandrieu.com Joe Andrieu]

=== Tuesday ===

9:00am-9:30am Opening and Agenda Making -- same as in Day 1

9:30am-4:00pm: Sessions

4:00-5:30pm:

Closing - Reports from all discussions, listing of Action Items and community conversation about what is next for various VRM projects

==Space==

We have three classrooms booked. All have a power outlet at every seat, and seating is arranged in a horseshoe shape, so everybody can face everybody else. (We'll also put details here for wi-fi connecting as well. Some advance work is required there.)

If we need additional small session spaces, there are plenty of those out on the lawns and in the halls and public seating areas amongst nearby buildings at the Law School. We'll make room on the session "spreadsheet" for these, so we're ready if the need arises.

As the workshop approaches, we encourage people working on projects to get ahead of the workshop curve by sharing some of their work with the ProjectVRM list and on their own blogs.

== Possible Topics ==

There are many. Here is a list to get us started. Add or subtract whatever you like...

* The Mine! (Adriana Lukas)
* Personal Address Manager (Iain Henderson)
* RelButton -- and first use challenge: a biz model for public media (Doc Searls)
* User-driven Search (Joe Andrieu)
* r-cards (Paul Trevithick)
* VRM and health care
* VRM and social web stuff (Kevin Marks)
* VRM standards, policies and practices (Brett McDowell)
* VRM and TiddlyWiki
* VRM + (rather than vs.) CRM
* VRM and legal openings, hurdles, models and precedents (Renee Lloyd)

== Getting There ==

Pound Hall is located on the Harvard campus at 1563 Massachusetts Avenue, within the Law School. Some resources --

* [http://www.law.harvard.edu/about/contact/images/law_map.jpg Harvard Law map]
* [http://maps.google.com/maps?f=q&hl=en&geocode=&q=1563+Massachusetts+Avenue,+02138&sll=37.0625,-95.677068&sspn=76.482111,100.898438&ie=UTF8&ll=42.378345,-71.120081&spn=0.009019,0.012317&t=h&z=16 Google Maps]
* [http://wikimania2006.wikimedia.org/wiki/Getting_to_and_around_Cambridge Wikimania on Cambridge]

Parking is a hassle, so we highly recommend taking public transportation. Fortunately, the Boston Area has some of the best public transportation in the U.S. The Harvard Campus is adjacent to Harvard Square, which is a stop on the Red Line of the "T", Boston's subway system. The Red Line is the best of all the "T" lines. Trains roll through every stop only few minutes apart, and the trains are fast. If you can find accommodations near a Red Line stop, you'll be in great shape. Cambridge area stops are Alewife, Davis, Porter, Harvard, Central and Kendall. In Boston the near ones are Charles/MGH, Park, Government Center and South Station.

Getting to Pound Hall:

From the Harvard "T" station go up the stairs to "Church Street." At the top of the stairs, turn right to walk across Church (and past the church itself), then up "Mass Ave" past Cambridge Common (which will be on the left). Cross over to the Harvard side of Mass Ave at Waterhouse Street, then turn left to continue north on Mass Ave. The first Harvard building on your right (just before a big construction project) is Pound Hall. Look for us in the center of the ground floor. If you walk fast you can make it in 5 minutes from the "T".

Personal Address Manager Service

2008-03-08T19:27:10Z

Brett.McDowell: /* Organizations/Movements */

This Standard is being developed according to the VRM [[Use Cases|Use Case]] guidelines.

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

==Status==
[[:Category:Working Draft|Working Draft]]
[[Category:Working Draft]]

==Schedule==
{| border="1"
|+ '''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 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''

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

[[image:PAM_Role_Map.png]]

==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 required use cases by title.
# Addressee Manages Address
## Addressee Creates Address
## Addressee Reviews Address
## Addressee Changes Address
## Addressee Deletes Address
# Addressee Manages Addressors
## Addressee Uploads Addressors
## Addressee Authorizes Addressor
## Addressee Manages Addressor Permissions
## Addressee Deletes Addressor
# Addressee Manages Delegates
## Addressee Authorizes Delegate
## Addressee Unauthorizes Delegate
## Addressee Removes Delegate
# Addressor Manages Delegates
## Addressor Authorizes Delegate
## Addressor Unauthorizes Delegate
## Addressor Removes Delegate
# Addressor discovers Personal Address Manager service for Addressee
# Addressor Requests Authorization
# Delegate requests authorization
# AddressRequester Requests Current Address
# AddressSubscriber Activates Subscription
# AddressSubscriber Deactivates Subscription
# Addressee Accesses Activity Log
# Addressor reports address change
# Addressee acknowledges address change

==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.
===Addressee 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 subscribers 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=====
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

==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===
{| border="1" cellspacing="0" cellpadding="5" align="center"
! width="50%"|User Intention
! width="50%"|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
==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

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
#*email

Personal Address Manager Service

2008-03-08T19:25:05Z

Brett.McDowell: /* Technologies */

This Standard is being developed according to the VRM [[Use Cases|Use Case]] guidelines.

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

==Status==
[[:Category:Working Draft|Working Draft]]
[[Category:Working Draft]]

==Schedule==
{| border="1"
|+ '''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 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''

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

[[image:PAM_Role_Map.png]]

==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 required use cases by title.
# Addressee Manages Address
## Addressee Creates Address
## Addressee Reviews Address
## Addressee Changes Address
## Addressee Deletes Address
# Addressee Manages Addressors
## Addressee Uploads Addressors
## Addressee Authorizes Addressor
## Addressee Manages Addressor Permissions
## Addressee Deletes Addressor
# Addressee Manages Delegates
## Addressee Authorizes Delegate
## Addressee Unauthorizes Delegate
## Addressee Removes Delegate
# Addressor Manages Delegates
## Addressor Authorizes Delegate
## Addressor Unauthorizes Delegate
## Addressor Removes Delegate
# Addressor discovers Personal Address Manager service for Addressee
# Addressor Requests Authorization
# Delegate requests authorization
# AddressRequester Requests Current Address
# AddressSubscriber Activates Subscription
# AddressSubscriber Deactivates Subscription
# Addressee Accesses Activity Log
# Addressor reports address change
# Addressee acknowledges address change

==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.
===Addressee 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 subscribers 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=====
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

==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===
{| border="1" cellspacing="0" cellpadding="5" align="center"
! width="50%"|User Intention
! width="50%"|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
==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

==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

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
#*email

Personal Address Manager Service

2008-03-08T19:21:29Z

Brett.McDowell: /* Technologies */

This Standard is being developed according to the VRM [[Use Cases|Use Case]] guidelines.

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

==Status==
[[:Category:Working Draft|Working Draft]]
[[Category:Working Draft]]

==Schedule==
{| border="1"
|+ '''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 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''

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

[[image:PAM_Role_Map.png]]

==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 required use cases by title.
# Addressee Manages Address
## Addressee Creates Address
## Addressee Reviews Address
## Addressee Changes Address
## Addressee Deletes Address
# Addressee Manages Addressors
## Addressee Uploads Addressors
## Addressee Authorizes Addressor
## Addressee Manages Addressor Permissions
## Addressee Deletes Addressor
# Addressee Manages Delegates
## Addressee Authorizes Delegate
## Addressee Unauthorizes Delegate
## Addressee Removes Delegate
# Addressor Manages Delegates
## Addressor Authorizes Delegate
## Addressor Unauthorizes Delegate
## Addressor Removes Delegate
# Addressor discovers Personal Address Manager service for Addressee
# Addressor Requests Authorization
# Delegate requests authorization
# AddressRequester Requests Current Address
# AddressSubscriber Activates Subscription
# AddressSubscriber Deactivates Subscription
# Addressee Accesses Activity Log
# Addressor reports address change
# Addressee acknowledges address change

==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.
===Addressee 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 subscribers 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=====
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

==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===
{| border="1" cellspacing="0" cellpadding="5" align="center"
! width="50%"|User Intention
! width="50%"|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
==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/resource_center/specifications/liberty_alliance_id_wsf_2_0_specifications_including_errata_v1_0_updates

===Organizations/Movements===
*DataPortability.org http://www.dataportability.org
*Microformats http://microformats.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

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
#*email