NOTE-OPS-OverHTTP.html
· Submitted to W3C on 02 June 1997 ·
This document is a NOTE made available by the World Wide Web Consortium for discussion only. This indicates no endorsement of its content, nor that the Consortium has, is, or will be allocating any resources to the issues addressed by the NOTE. A list of current NOTEs can be found at: http://www.w3.org/TR/.
This document is part of a complete submission to the W3C. The full submission has been acknowledged by W3C and is available at http://www.w3.org/Submission/1997/6/Overview.html
Note: since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.
Abstract
OPS proposes a means for the exchange of profile information. For the purposes of OPS, we define profile information as any feature and corresponding values of an end user or service provider. The specification provides for the trusted communication (mediated by computer software and communication systems) 1) between people and services, 2) between services mediated by people, and 3) between people.
This document describes the implementation of OPS over HTTP, as defined in [RFC 2068]. Specifically, this document discusses the implementation of profile read and write operations, including protocol and data format. A working knowledge of "Proposal for an Open Profiling Standard" [OPS-PROP] is necessary to fully understand this document.
This document is the second in a series of OPS related specifications. The first document, "Proposal for an Open Profiling Standard," covers the framework for profile exchange, including data structure and operational primitives. The third, the "Standard OPS Practices" covers "well-known sections" (standard profile elements), suggested permission mechanisms for user and service provider control of the exchange of profile data, and standard transaction logging techniques.
Reaching the goals outlined in these documents - creating a context for personalization with privacy management - is achieved only in part by the technical framework defined. Another essential part of reaching the goal requires the definition and operation of business practices and social structure, a topic beyond the scope of these documents.
Authors:
| Firefly Network, Inc: | Netscape Communications: |
| Pat Hensley - hensley@firefly.net | Donna Converse - converse@netscape.com |
| Max Metral - max@firefly.net | Verisign, Inc.: |
| Upendra Shardanand - shard@firefly.net | Mike Myers - mmyers@verisign.com |
As more and more users, and more and more services come to the Internet, users are finding themselves increasingly overwhelmed with the richness of new possibilities, and new service providers are discovering that rapidly building systems to fit these users’ information needs becomes ever more challenging.
In general, a solution to these problems often involves delivery of highly customized and personalized information to end users, which raises the profound and valid concern about making and keeping explicit commitments to users about how their most sensitive personal information, choices, preferences, and interest will be protected in these exchanges.
Companies and service organizations worldwide want to take advantage of the 1-to-1 nature of communications on the Internet or within intranets to provide their customers, employees and visitors with individualized information, entertainment and services. However, there are two barriers to the feasibility and widespread adoption of such products and services:
1. The potential threat to individual privacy makes end users wary of sharing any information. Today, there are few measures or safeguards which offer an end user any awareness of or any control over the usage of his or her personal information. This concern often outweighs the incentive of a personalized service and makes a person justifiably cautious about revealing any personal information.
2. Gathering the information that makes this personalization possible is inefficient. Service providers need to ask their visitors for information -- who they are, where they live, what they do, what they like - in order to personalize the user experience. This data collection can be very time consuming for both the service provider and the end user, and can’t be leveraged for their mutual benefit. Furthermore, a single individual might provide much the same information to dozens or even hundreds of parties over time - an inefficient and frustrating experience.
The Open Profiling Standard (or OPS) is a proposed standard for exchanging profile information between individuals and service-providing parties, with built-in safeguards for individual privacy.
For a full description of the foundations and motivations of OPS, see [OPS-PROP].
[ETRUST] eTrust Press Release "Survey Reveals Consumer Fear of Privacy Infringement Inhibits Growth of Electronic Commerce", http://www.eTRUST.org/press/article003.html, March 24, 1997
[FTC] Federal Trade Commission Staff Report, "Public Workshop on Consumer Privacy on the Global Information Infrastructure", http://www.ftc.gov/bcp/privacy/privacy.htm, December 1996
[IETF-VCARD] IETF Network Working Group Draft, "vCard MIME Directory Profile", http://www.internic.net/internet-drafts/draft-ietf- asid-mime-vcard-02.txt, March 26, 1997
[VCARD] VERSIT Consortium, "vCard - The Electronic Business Card Version 2.1", http://www.imc.org/pdi/vcard-21.txt, September 18, 1996
[PEP] W3C Working Draft, "PEP - an Extension Mechanism for HTTP"
[OPS-PROP] W3C Working Draft, "Proposal for an Open Profiling Standard"
[OPS-PRAC] W3C Working Draft, "Standard Practices for OPS Systems"
This document uses all terms defined in [OPS-PROP].
Profile readers and writers must be able to exchange profile data from end users through many protocols. This document illustrates the use of HTTP as a communication mechanism. While many alternatives are available, the primary mechanism is envisioned to be HTTP, as it is the predominant protocol on the World Wide Web. The protocol is designed to:
• Minimize the number of round trips
• Insure graceful failure for non-compatible client systems
• Allow extensions to existing browsers to implement the protocol
• Allow sites to trade off complexity and security, and make the user aware of such tradeoffs
• Leverage existing standards (e.g. SSL)
In the abstract, a profile exchange consists of an exchange of profile attributes. For a full description of profile operations and exchange, see [OPS-PROP]. In an HTTP profile exchange, profiles are embedded in HTTP headers. Currently, these headers are defined in this document. As drafts such as [PEP] become standard, the headers defined here can be changed, so long as the semantics of their contents remain the same.
Profile elements are encoded in a MIME message body, most often containing type "text/directory". Static content such as identity certificates and terms of exchange contracts can be referenced as described in [IETF-VCARD] rather than included to conserve header space and reduce redundant data transfer.
Implementations are required to conform to the provisions of the Security Considerations clause in [OPS-PROP].
Privacy of Information when in transit to a Service Provider. It is necessary that the exchange of attributes between service provider and user maintain the privacy of this information while in transit to the service provider. This specification encourages the use of SSL to establish a secure session prior to any exchange of attributes. This specification also encourages user agents to alert users as to the level of security employed in transit.
An HTTP profile exchange occurs in two forms: profile read and profile write. A "profile read" describes the end user furnishing profile information (either after being requested or by offering it automatically) to a service provider. A "profile write" is a request by a service provider to store information in the user profile. Profile writes encompass profile section creation, attribute creation, and attribute modification. A detailed protocol description follows.
A profile write is a simple transaction. A SetProfile header can be included in any HTTP response, much like a SetCookie header. Also like a SetCookie header, there is no guarantee the set will succeed, and it can only be checked with a profile read. If a user agent receives both a profile read and profile write request, all profile writes shall be attempted first, followed by the profile read. This ordering allows service providers to check the result of a write while minimizing round trips. The contents of the SetProfile header element is a profile update structure, which for reference is repeated from Section 5.2 of [OPS-PROP]:
ProfileWrite =
{
identity,
credential*,
ProfileUpdates {
propertyName[;propertyModifier]:propertyValue
permissions*
}*
}
The profile write structure is escaped (converted to an HTTP fragment),
according to [RFC 2068].
For additional clarity we present an example browser-server profile write conversation (client in bold):
GET /myPage.phtml HTTP/1.0 User-Agent: OPS-IS-COOL 1.0 HTTP/1.0 200 OK SetProfile: <escaped ProfileWrite object> GetProfile: <escaped ProfileRead object> Content-length: 50 Content-type: text/html Here’s your web page. I noticed you like widgets, so I’ll customize the rest of your experience here on ACME Grommets.
A Profile Read is a two-step process. First, the site must specify what profile elements it wants, and present appropriate credentials to get them, and then the user agent must evaluate the query and return the profile elements, or fail if permission is denied. Because this process is not a trivial one, this protocol is designed to occur once per "session." ; This is in direct contrast to cookies, which are transferred on every page view. While it is possible to request profile information on every page view, the protocol is designed to make this behavior undesirable; the OPS protocol is not meant as a state management system.
Conceptually, profile reads are similar to an HTTP Forbidden response used to implement access control. Briefly, the HTTP authentication protocol ([RFC 2068]) occurs as follows:
| CLIENT | SERVER | |
| User agent requests page from server | --> | |
| <-- | Server sends back forbidden response, asking for basic authentication, and includes content to be displayed on failure | |
| User agent asks the user for a password | ||
| User agent EITHER:
• Fails password entry and displays failure content • Attains password, re-requests the page and passes the password information to the server |
--> | |
| <-- | If the password is correct, server returns the protected content. If incorrect, server sends forbidden response and the process repeats. | |
| User agent continues to send password information on subsequent page views to same domain | --> |
For profile reads, the user agent interprets the "GetProfile" header, and emulates the forbidden process, as follows:
| CLIENT | SERVER | |
| User agent requests page from server | --> | |
| <-- | Server sends back response, asking for a profile section using a GetProfile header, and includes failure content to be displayed on failure | |
| User agent evaluates profile request, possibly asks for user permission | ||
| User agent EITHER:
• Fails permission set evaluation, and displays the failure content to the user • Assembles response profile packet and sends it to the server, requesting same URI |
--> | |
| <-- | If the profile data is adequate, server returns the personalized content. If incorrect, server sends request in response and the process repeats. |
So, an actual conversation might look like: (client in bold)
GET /myPage.phtml HTTP/1.0 User-Agent: OPS-IS-COOL 1.0 HTTP/1.0 200 OK GetProfile: <escaped ProfileRead object> Content-length: 50 Content-type: text/html <a href="myPage.html">Click here to get an OPS compliant browser…</a>
The user agent then decodes and evaluates the request object and returns a corresponding header:
GET /myPage.phtml HTTP/1.0 User-Agent: OPS-IS-COOL 1.0 ProfileObject: <escaped ProfileObject> HTTP/1.0 200 OK Content-length: 12350 Content-type: text/html Thanks for your profile. Here’s some personalized content. Personalized web page……………
A clear design goal was to allow existing browsers to support OPS. This support should manifest itself in two ways:
• An incapable browser should fail gracefully, displaying informative content and allowing users to fill out forms if necessary
• Via standard extension mechanisms (plug-ins, applets), existing browsers should be able to support OPS to some degree.
Two methods for support are described here, with their associated advantages and disadvantages explained.
Through a combination of Java applets and trusted code (primarily for the ability to store the profile on disk), OPS can be implemented on any Java compatible browser. The general approach is to allow applet invocations on OPS profile request pages to interact with an OPS client side library, fulfill the request, and redirect the browser to the target page with the profile object included. Like the table above the process would look like:
| CLIENT | SERVER | |
| User agent requests page from server | --> | |
| <-- | Server sends back response, asking for a profile section using a GetProfile header, and includes failure content to be displayed on failure. That failure content in turn invokes a Java applet, passing parameters including the GetProfile header value. | |
| User agent ignores header, but invokes applet. Applet evaluates profile request by interacting with trusted code, possibly asks for user permission. | ||
| Applet EITHER:
• fails permission set evaluation, and displays the failure content to the user by simply stopping. • assembles response profile packet and sends it to the server, requesting same URI but passing the profile result as form variable |
--> | |
| <-- | If the profile data is adequate, server returns the personalized content. If incorrect, server sends request and applet invocation in response and the process repeats. |
The applet approach fulfills both design goals:
• Browsers which don’t have Java capability, or don’t have the "trusted code," will merely display the failure content, which could include a form for profile submission, or instructions on obtaining the OPS extension.
• Any Java capable browser can now implement OPS.
The main weakness of the Java solution at this time is the great flux occurring in Java implementations, especially in the areas of security and UI.
Most current browsers support the concept of "plug-ins," or modules which can be dynamically installed to provide additional functionality. Most often, this functionality is invoked via the use of custom MIME types. For example, if a server returns content of type "application/customApp," a certain plug-in could be invoked, or in some cases, the plug-in could be installed on the fly, and then invoked.
The basic conversation would proceed as follows:
| CLIENT | SERVER | |
| User agent requests page from server | --> | |
| <-- | Server sends back response, asking for a profile section using a GetProfile header, and includes failure content as a special MIME type which encodes the profile request. | |
| User agent EITHER:
• invokes plug-in for MIME type, which evaluates the request and assembles response • installs plug-in, and invokes as above • fails and behaves in a browser-specific manner (such as showing no content) |
-->
--> |
|
| <-- | If the profile data is adequate, server returns the personalized content. If incorrect, server sends request as custom MIME type and process repeats. |
The plug-in approach partially fulfills the design goals:
• Existing browsers can auto-install the plug-in, or display an appropriate error message.
• Plug-ins can fully implement OPS.
Plug-ins, although browser and platform dependent, have a stable, fully-functional environment in which to work.
If PEP is adopted, could this protocol use it?
Clearly this protocol would fit into the goals of PEP. For performance reasons, certain PEP details need to be hammered out before OPS is implemented via PEP. Will it require more roundtrips? Will it make extension implementation for existing browsers easier or harder? Factually, since PEP is not yet a standard and no implementation plans have been announced, it is premature to base OPS on PEP.
Where are all the protocol details?
This document will be updated with BNF specifications of protocol details and references to relevant syntactic elements. Some of those details will likely find their way into the OPS Proposal document [OPS-PROP].
Can this interact more effectively with cookies?
It would be desirable to give user’s this level of control for cookies. It would also be desirable to allow certain profile elements to behave like cookies, e.g. site id’s (see PUIDs in [OPS-PRAC]). For now, we leave this to the UI. There’s nothing preventing transmission of profile elements as cookies (with the proper security precautions), or the administration of cookies under the same UI as profile elements.