Email List Subscription Use Case

["Drummond Reed" <drummond.reed@cordance.net>]

For reference on this week's TC call, the following is a plain text version
of the Calendar Sharing use case (also posted at
http://xrixdi.idcommons.net/moin.cgi/XdiUseCases_2fEmailListSubscriptions). 

== XDI Use Case :: Automated Email List Subscriptions ==
 * '''Level:''' Sea

=== Description ===
Email lists are one of the most ubiquitous services on the net, and many
heavy net users are subscribed to dozens of them. With the present state of
email list technology, undergoing an email-change-of-address (ECOA) requires
separate human-managed interactions with each email list. This use case
describes the ability for a List Subscription Authority to automate this
change-of-address task, and also to be able to add or delete subscriptions
easily and automatically without any knowledge of the individual interface
or authentication requirements of the specific lists.

=== Actors ===
 * List Subscription Authority (Data Authority)
  * The individual or other subscription entity represented by the
subscribed email address.
 * List Subscription XDI Service Provider (XSP).
  * An XSP that offers automated email subscripton services.

=== Pre-Conditions ===
 1. The List Subscription Authority has subscribed to one or more email
lists.
 1. The List Subscription XSP hosts the List Subscription Authority's list
subscription data (i.e., the current email address and the addresses and
authentication credentials required by the subscribed lists). In this
capacity the List Subscription XSP is acting as a Delegated DA for the List
Subscription Authority.
 1. Each email list offers an XDI list subscription service (i.e., functions
as an XSP).

=== Steps / Activities ===
 1. The List Subscription Authority authenticates to the List Subscription
XSP.
 1. The List Subscription Authority changes his/her email address or adds a
new email address.
 1. The List Subscription XSP prompts the user to verify which list
subscriptions should be updated and the List Subscription Authority makes
this selection.
 1. The List Subscription XSP sends an automated change-of-address to all
the affected email listbots and receives the acknowledgement.
 1. If there are any failures, the List Subscription XSP notifies the List
Subscription Authority.

=== Post-Conditions ===
 * The List Subscription XSP's records are updated so that any future
changes are ready to be made.

=== Variations ===
 * The List Subscription Authority may also instruct the List Subscription
XSP to add a new email list to his/her subscriptions, or to delete an
existing subscription. In each case the List Subscription XSP sends the
appropriate automated message to the email list.
 * In the case of adding a new subscription, the List Subscription XSP may
need to query the email list to discover the necessary list
subscription/change-of-address/unsubscription data requirements.

=== Issues / Key Requirements ===
 * The List Subscription XSP can be either a server-side service or a
client-side program - the architecture should be neutral.
 * Messages to the email lists should be able to be sent via either email or
Web forms (many email lists support both interfaces).

=== Security Considerations ===
 * Messages to listbots must include the credential(s) necessary to
authenticate the List Subscription Authority to the email list, preventing
automated attacks.

=== Privacy and Other Data Protection Considerations ===
 * The List Subscription Authority's list subscription data is typically
sensitive and should be protected by an applicable privacy policy.

=== Links and Resources ===
 * ReturnPath offers several white papers on the [http://www.returnpath.biz/
ECOA problem].
 * Although there is a wealth of software to automate email list management
(i.e., publisher-side operations), I don't know of any to automate
subscriber-side operations.

=== Contributors ===
 * DrummondReed