Licensing

Mary Kirtland

Microsoft Corporation

February 21, 2001

In last week's column, I discussed the user privacy issues we considered while designing our Favorites Web Service. Based on our initial research into the user privacy issues, we decided to focus on three main usage scenarios in the initial release of the Favorites Service:

A Web site, say msdn.microsoft.com, provides a button on each of its pages that a user can click to add that page to the user's favorites stored at the Favorites Service.

Msdn.microsoft.com provides a Web page that displays a user's favorites, which were originally stored with the Favorites Service by msdn.microsoft.com on the user's behalf.

Msdn.microsoft.com provides a Web application that lets a user manage the favorites that were originally stored with the Favorites Service by msdn.microsoft.com on the user's behalf.

In essence, each Web site that uses the Favorites Service gets its own private store for user favorites. Even with this limited set of scenarios, we decided we would need to restrict access to the service to known users—in other words, we would need to license the service.

In this column, we'll look at licensing in detail: issues to consider when defining a business model for a Web Service, how business models relate to licensing, the model we selected for the Favorites Service and why, and the impact of the selected model on our design and implementation.

Feedback on Your Comments

Before we get started, I wanted to address a couple issues raised by readers of last week's column.

First, with respect to user privacy, someone asked how we would address European Union (EU) data protection regulations. For those of you wondering "what European Union data protection regulations?," you can read about them at http://www.europarl.eu.int/dg2/hearings/20000222/libe/framework/eplegs/en/. Since our project team works for Microsoft and we plan on hosting the service on Microsoft-owned equipment, our deployed service must comply with Microsoft's policy regarding the EU data directive.

Our team is currently working with Microsoft's Corporate Policy Group to ensure that the Favorites Service deployed on our production servers meets Microsoft policy. If we end up doing anything "extra" specifically to meet EU requirements, we'll be sure to let you know. However, you should note that what we need to do to comply with Microsoft policies might not be what you need to do to comply with your own company policies. This is a great example of why you should work with your legal advisors throughout the project lifecycle to ensure your privacy policies comply with current laws wherever your customers, staff, and servers are located.

Second, someone asked about dealing with the Logon component if they wanted to aggregate the Favorites Service with some other stuff and deploy a new service. The short answer is that the Logon component's methods are exposed through the Favorites Web Service. A client application—or in this scenario, the new service—calls the logon method before it can use any of the user favorites management methods. My next column will discuss authentication and authorization, so tune in next week for more details.

Web Service Business Models

Most Web sites that interact directly with end users seem to have gravitated toward a few business models. From a user's perspective, there are several options:

All features of the site are freely accessible to the user.

The user must sign up for a free account before accessing some or all features of a site.

The user must pay for a subscription before accessing some or all features of a site. The subscription usually provides unlimited access to a set of features for a specified period of time.

The user must pay a per-use fee before accessing some content.

Another aspect of the business model is how the business recovers the cost of developing and operating the site:

Development and operations costs are simply counted as part of the cost of doing business.

Users pay a subscription fee to access the site.

Space on the site is sold to advertisers or other sites.

As-is, these models don't really work well for Web Services. Usually a Web Service would not be used directly by an end user. In addition, Web Services are used programmatically, so you can't rely on advertising eyeballs for revenue. However, the models for Web sites can help us identify some issues to consider when defining the business model for a Web Service. The issues we identified are Customers, Pricing, Payment Methods, Subscriptions, Notifications and Billing, Grace Periods, Authentication, Auditing, and Customer Service.

Customers

The first question you should ask is with which customers you want to establish business agreements. Usually a Web Service provider will establish business agreements with application developers that want to use the Web Service in an application. If the Web Service stores user-specific data, the Web Service might establish agreements with the end users instead of or in addition to any agreements with application developers. Another possibility is that the Web Service provider establishes business agreements with one or more Application Service Providers (ASPs) to host the service. The ASP in turn establishes relationships with application developers and/or end users, as appropriate.

Pricing

Once you've identified your customers, you can start to think about the value those customers will place on your service and how much they will be willing to pay for it. One of the things you should consider is whether the price will be based on the number of requests made (the pay-per-view model) or whether you will grant unlimited use for a period of time (the lease model). Other factors include whether or not the price is the same for all types of requests, whether or not the price is the same for all customers, and whether or not the price is always the same for a given customer.

Payment Methods

If you decide to charge money for your service, you'll need to consider what mechanisms customers use to pay for service. Web sites that interact directly with end users usually accept credit cards. However, a company that wants to access your Web Service may not want to use a credit card to make payments. You might need to accept payment by check or wire transfer.

Another factor you'll need to consider is whether customers must pay in advance, pay as they go, or can pay after the fact. If customers can pay after the fact, you may want to place an upper limit on the outstanding charges. You might impose a standard limit for all customers, or set a different limit for each customer.

Subscriptions

Whether or not you charge money for your service, you may need a way to identify who is calling the service. In this case, each customer will need to establish an account (or subscription) with you. How do they do this?

You should consider whether you will immediately grant an account to anyone who asks for one, or whether there is some approval process before an account is granted. If there's an approval process, can the customer apply over the Web or do they need to call a customer service representative? Do you need a staff to investigate and approve requests for new accounts?

You should also think about what information you require before granting an account and what optional information you will ask customers for. This information is likely to fall into the category of personally identifiable information that needs to be protected by your fair information practices, as discussed last week.

Another consideration is whether you let customers select their own account identifiers and passwords, if any, or whether you generate random identifiers and passwords. If the customers can select their own account identifiers, you'll need to handle the possibility of duplicate identifiers.

You'll also need to consider how customers maintain their account information, including passwords. Do customers use your Web site or can they call a customer service representative? What if they forget their account identifier or password?

Notifications and Billing

If your subscriptions have a time limit, you'll need to define the process for notifying customers that their subscription is about to expire. The same sort of issue occurs if you charge for your service and customers don't pay as they go. You should think about the medium used to notify customers. For example, you might send e-mail, make a phone call, or send an invoice. You should also think about how many attempts you make to notify the customer and whether the same medium is used for each attempt. How much advance notice do you provide before the subscription expires?

If you are charging money for the service, especially charging per-request, you should think about how often you bill customers. A customer is not going to want to receive a bill with thousands of individual charges, one per service request. Perhaps you'll want to aggregate charges per day, per week, or per month, and make detailed usage reports available to those who want a breakdown of charges.

Grace Periods

You should consider whether to grant a grace period after a subscription has expired or payment is past due. If so, you need to think about how long the grace period should be. You should also think about whether there are any restrictions on the account during the grace period. For example, perhaps the customer can only query existing information, not store new information. Another consideration is whether to send additional notifications to the customer during the grace period.

Authentication

On a more technical level, if customers need accounts to access your service, you need to consider how you authenticate the customers when they make service requests. There are three basic types of authentication mechanisms today: communications protocol authentication features, application level authentication, or third-party authentication. The most straightforward approach is to leverage the capabilities of the communications protocol used to exchange messages with your Web Service. For example, Microsoft Internet Information Server 5.0 supports several authentication mechanisms for HTTP. Another option is to implement a custom authentication mechanism in your Web Service. For example, if your Web Service accepts SOAP messages, customer credentials could be passed in a SOAP header or as elements in the SOAP body. Finally, you could use a third-party service, such as Microsoft Passport, to handle authentication for you.

Each of the available mechanisms has tradeoffs. Some mechanisms are more secure than others. Some mechanisms are not widely supported by developer tools for building Web Services. Some mechanisms require clients to obtain certificates or accounts from a third-party. Some mechanisms have significant performance overhead. You will need to weigh these tradeoffs against your customers to figure out which mechanism is appropriate for your Web Service. For further information about currently available authentication options for Web Services, see the article Web Service Security.

Auditing

Another issue you'll want to think about is the information you need to collect for auditing purposes. Think about what information you would need on hand in case of a billing or customer privacy dispute. If you are billing per-request, this could be quite a lot of data. Consider the volume of data you'll collect each day and how that data is archived. Are there standard reports you should create to help avoid or resolve disputes?

Customer Service

Finally, consider what kinds of customer service you need to provide. For example, you might need to provide customer service to request and manage subscriptions. You will probably need to provide a way for customers to report problems accessing or using your service. You might need to provide a way to help developers write applications that use your service.

For each kind of customer service, you'll need to think about how that service is provided. Do customers need to use a Web site to get help? Can they send e-mail? Can they contact you by phone? Whichever options you decide on, what tools and infrastructure do you need to have in place in order to provide effective support?

Business Models and Licensing

After considering these nine issues, you should have a pretty good idea of the business model for your Web Service. How does this relate to licensing?

When we use the term license, we mean an agreement between a customer and a Web Service provider regarding use of the Web Service. Unless your business model is anonymous, free access to everyone, there's probably a license agreement involved. For example, the act of establishing an account or subscription may imply customer acceptance of certain terms of use. In some cases, the customer may be required to read or sign a license agreement before they are granted a subscription. We'll generally use the term licensing model instead of business model when discussing Web Services that restrict access to licensed customers.

The Favorites Licensing Model

Based on the scenarios we selected to enable for the first release of the Favorites Service, we had already defined who our customers were: application developers (or more precisely, development organizations) who wanted to use the Favorites Service. The next thing we looked at was whether customers needed to establish a subscription before using the service. Let's consider what might happen if we didn't require subscriptions.

Assume some application comes along that wants to start saving favorites using the Favorites Service. We decided for user privacy reasons that each caller effectively gets its own data store. How should the store be identified? If the caller specifies a name for the store, there's the possibly that two callers will specify the same name—and we have no way to distinguish one caller from another. We could provide a CreateStore method that would return a unique data store identifier. But what if the unique identifier is lost or stolen? Since we have no information to tie the unique identifier to a particular caller, we can't retrieve lost identifiers. Nor can we do much about stolen identifiers. In fact, we can't even confirm that the person reporting a stolen identifier has any relationship to the caller that created the data store.

All in all, we're probably better off requiring customers to sign up for a subscription. We can collect enough contact information to deal with lost or stolen account identifiers or passwords. The contact information also gives us a way to get in touch with someone if we detect a problem with the way a particular application is using the Favorites Service.

We could have stopped at this point and decided our licensing model would be free, life-time, unlimited use licenses granted to development organizations who have supplied contact information (and, perhaps, read our privacy policy or other disclaimers). However, we decided to design the system to support a more complicated business model in order to investigate the impact on overall system design.

In phase one, the Favorites Service is licensed to development organizations that want to use the service from their applications. The rules for licensing are as follows:

A licensee is granted unlimited access to the service for a specified period of time.

The licensee must pre-pay for the service. The rate charged is based on the length of the license and the total number of end users for which the licensee is managing favorites.

Licensees will be notified by e-mail one month before the license expires.

Licensees will be notified by phone one week before the license expires.

Licensees are granted a grace period of ten days after the license expires.

The licensing workflow is shown in the following diagram:

Figure 1. Favorites Licensing Workflow

A customer account representative must be contacted to start the licensing process. The licensee will be invoiced for all charges and payment must be received before the license is validated. When the license is validated, the licensee business contact will be sent e-mail containing all the information needed to use the Favorites Service. New licensees may not be recognized by the Favorites Service for up to 24 hours after validation occurs.

All new licenses are for a period of 3 months, at a rate of $0.00/user. After the initial three month term, licenses may be renewed for 3 months, 6 months, 1 year, or 2 years. The fee charged is based on the number of users for which the licensee is managing favorites. The functional specification defines how this fee is calculated.

In order to compute fees for license renewals, as well as defending ourselves in case of billing disputes, the Favorites Service logs every call to the Web Service and its outcome (success, client error, or server error).

Note that it is impractical for MSDN to deploy a sample service that actually implements all the features of this licensing model. For example, we don't have customer account representatives who can respond to requests for new licenses or call licensees a week before their license expires. Nor do we want to actually charge any money to use our sample service. However, we felt it was important to design a system capable of supporting this licensing model. Our actual implementation will have some modifications so that you can try out the deployed service without a lot of hassle to obtain a license. We'll be sure to point out where our design and implementation different. Hopefully it won't be too confusing

Implementing Licensing in Favorites

As you might imagine, supporting our licensing model added quite a bit of complexity to the Favorites Service. It wasn't enough just to implement a COM component and expose it as a Web Service. Suddenly we needed a way for prospective customers to request subscriptions, a way for customers to maintain their account information, and tools to generate notifications for subscription renewals. We needed to collect data about every call to the service in order to compute fees for license renewals. And we needed to implement an authentication mechanism. The following figure provides a high level view of our system architecture:

Figure 2. Favorite Service Licensing Architecture in Phase One

Customers request subscriptions and changes to account information through the Favorites Web site. The Web site validates data input, passes the requests on to the Licensing component, and displays confirmation messages that the requests have been received. In general, the Favorites Service does not immediately grant subscriptions or make changes to account information. Instead, pending requests are saved for verification by a customer account representative. When a request is accepted, e-mail is sent to the licensee contact to confirm the request has been completed.

The Licensing component implements the business logic for our licensing model. Each method of the licensing component has the same basic structure: initialize an Audit object to create an audit log entry, validate input parameters, call stored procedures to update the appropriate databases, send an e-mail notification if necessary, update the Audit object with the results of the method, and save the audit log entry. Some business rules are enforced in the stored procedures rather than the Licensing component. E-mail is sent using the IIS SMTP service.

Our licensing model workflow is enforced using a set of status flags stored in the Licensee and Notifications databases. For example, when a prospective customer requests a new license, a new licensee record is written to the Licensees database with status set to pending. Similarly, when a license renewal notice is sent, that is recorded in the Notifications database.

In a real-world implementation of our business model, we would have customer account representatives verifying customer contact information before granting new licenses or modifications to contact information. The Favorites License Management System (FLMS) is a Web-based application that customer account representatives could use to view pending requests and accept or reject those requests. Since we don't have any customer account representatives, we've only implemented support for a couple of the requests, so you can see how it might work. Like the external customer Web site, FLMS relies on the Licensing component to do most of the work.

In our deployed service for MSDN, we won't have any customer account representatives, so we've implemented a process called AutoAdmin that checks for pending requests and automatically grants them using the services of the Licensing component. We also need a way to generate renewal notices automatically. That is implemented in another process, Renewals, that is run once per day.

In order to compute license fees for renewals and record information necessary to resolve billing or customer privacy disputes, we log the result of every request to the Favorites Web Service and Web site to the Audit Log database using the previously mentioned Audit component. Each audit log record contains information about the licensee making the request, the user on whose behalf the request is made, the type of action requested, the time the action was requested, the length of time required to handle the request, and the outcome of the request. This information is used to compute daily usage statistics that form the heart of our Reports Service. Once the daily usage statistics have been computed, the raw audit log records can be archived.

Finally, all this supporting infrastructure doesn't do us any good whatsoever if we don't have a way to authenticate callers to our Web Service. We have elected to implement application level authentication for the Favorites Service. An application that wants to use the Favorites Service first calls the Logon Service to obtain a key. It then supplies the key in each request to the Favorites and Reports Web Services. If the key is valid, the request is allowed to proceed. Otherwise, access is denied.

Conclusion

As you can see, the decisions you make regarding the business model for your Web Service can have a significant impact on the overall requirements for your system. You should try to define the business model as early as possible to avoid surprises that would require drastic changes to your system architecture. On the other hand, it can be difficult to figure out what business models your customers are willing to accept. Flexible designs that can accommodate changes in the business model are worth pursuing.

Next week we'll continue our examination of the design issues encountered while implementing the Favorites Service by taking a closer look at authentication and authorization.