NOTE-OPS-FrameWork.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
This specification 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.
A profile exchange is the informed, secure exchange of profile information between two parties. Thus, this specification discusses the control of profile information flow by both the creator and the recipient of the information, as well as third parties acting of behalf of either party. OPS also creates a framework for disclosure of intended usage of the information. This framework forms a basis for the further protection of privacy and usage through legal and social contracts and agreements as well as associated business processes.
This document is the first in a series of OPS related specifications. This document covers the framework for profile exchange, including data structure and operational primitives. A second document, "Implementation of OPS Over HTTP," covers implementation of the Open Profiling Standard over the standard web protocol, HTTP. Finally, "Standard OPS Practices" addresses "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.
OPS gives individuals the ability to enter the information once, and to give specific rules about how and when that information can be exchanged with services. This saves the user time, and gives service providers access to better information about their customers, allowing them to offer a better service and to understand their customer base. Furthermore, OPS greatly enhances personal privacy by giving the end user the ability to 1) control the release of their information and 2) track the exchange and usage of their personal profile.
The design of the Open Profiling Standard is motivated by three core guiding principles for the exchange of profile information. These principles are intended to protect the interests of end users and any party whose potentially sensitive and proprietary data is being exchanged. OPS is the technical framework that drives towards the goals, we envision two other key components: a policy/business practice and a growing social practice.
The core guiding principles are:
• Control by Source
• Informed Consent
• Value Exchange
Control by Source
Access to information is controlled by its source. The parties responsible for creation of any information should rightfully control permission for its dissemination. These parties minimally include the end user and the entity gathering the profile data. If the end user creates profile information, then the user has sole control over permissions for dissemination.
Informed Consent
A party requesting an end user’s profile must receive the informed consent of the source(s) before collecting and using their information in any manner. The individual must be given complete information as to how their data will be used, and with that knowledge, has the option of consenting to its usage and/or exchange. The communication of the consent may be entrusted to a third party or an automated process or system. Furthermore, as much as possible, the enforceability and verifiability of each profile exchange should be enabled by this process or system.
Appropriate Value Exchange
No party should collect information without offering the individual value in exchange. Adherence to this principle assures that an individual’s profile is not freely taken with no benefit for the user. Additionally, offering value to the individual provides an incentive for the user to provide valid and truthful information. For example, if a person’s locale is requested in order to provide appropriate local news, it is in the user’s best interest to provide their true information. Finally, the information requested should be appropriate to the application – in the case of local news, requesting a user’s hair color, for example, lacks relevance; in an online shopping application, on the other hand, fulfilling a user’s order for an audio CD clearly requires knowing a "ship-to" address for the order in question.
[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
[OPS-HTTP] W3C Draft, "Implementation of OPS Over HTTP"
[OPS-PRAC] W3C Draft, "Standard Practices for OPS Systems"
[LDAP]
[PKIX]
A brief definition of terms used within this document is presented below:
Profile: A hierarchical collection of personal profile information, the features and corresponding values describing an end user. See Figure 1 for an example.
Profile attribute: A singular feature of the end user described within their profile.
Profile section: A grouping of attributes and/or other profile sections within a profile.
Top-level profile section: A section which does not belong to any other section. Top-level sections have associated section authorities.
Permissions: The rights granted to other parties to either read or update a profile attribute or a profile section.
Credentials: Assertions by third parties as to the identity, authority, or practices of a service provider.
Profile request object: A data structure sent to a user agent by a profile reader describing the originator’s identity and the nature and context of the profile request.
Profile write object: A data structure sent to a user agent by a profile writer to store information in a user’s profile.
Terms of exchange: Text describing the intended usage of profile information. For example, "Acme Grommets will only use the information collected for recommending better grommets within our site."
Figure 1. Pieces of the Profile
There are a number of parties potentially involved in a profile exchange:
End users: The individuals managing their personal profile.
User agents: Client software which manages the end user profile and its interaction with profile readers and writers. The user agent can abstract much of the underlying complexity within OPS in order to simplify user management of their profile.
Service Providers: Profile readers or writers. Web sites which offer personalized news, stock quotes, or the ability to communicate with other users are examples of service providers.
Profile readers: The party asking to gain access to a portion of the end user profile in exchange for some service.
Profile writers: The party which adds or updates information within an end user profile.
Section authority: A profile writer which has qualified rights to control access to information within that section (fully explained in Section 3.1, "Naming and Authority"). In OPS the profile naming convention encodes the section authority.
Access providers: The party physically supplying network access and/or hosting to end users, profile readers and profile writers. Within the context of this protocol, the role of the access provider revolves around the security of the information being exchanged.
Certificate authorities: Third parties who certify the identity of an end user, profile reader, or profile writer.
Auditors: Third parties which verify the practices of a profile reader or profile writer and grant them the appropriate credentials.
The following symbols are used to simplify this document:
a* - one or more instances of a
[ a | b ] - a or b
c = { a, b } - structure c is composed of a and b
SIGN(x,y) - data x digitally signed by party y
HASH(x) - the hash value of data x, which is to be unique for all unique x
cert(a) - a’s certificate, or a fully qualified reference to a certificate
Profile data is the record of the end user’s features. It consists of a hierarchical set of named attributes. Examples of such attributes include "demographics.age" or "/com/acme.favoriteGrommets" (the naming convention is specified below). From the previous example, the profile sections would be "demographics" and "/com/acme", respectively. "age" and "favoriteGrommets" would be examples of attributes within the respective sections.
The communication encoding of profile data is specified by this document, along with mechanisms for alternate encodings. The representation of this data at the endpoints (end user system and profile reader system) is not restricted or specified by this document.
This specification describes two types of operations that can be performed: profile read and profile write. In a profile read, a ProfileRequestObject is presented by a profile reader as a request of the user agent. The profile request object specifies the identity and credentials of the requester, and the nature of their request. In a profile write, a ProfileWriteObject is presented to a user agent for creation or update of a profile attribute.
An important part of secure and trusted exchange of profile data is a robust permissions model. The OPS framework requires that applications implement permissions to control profile read and write operations. The "Standard Practices" document describes the required minimum permission capabilities and their implications in detail.
In reading this document, the key point is that a permission set must be established for both read and write operations, and that both the end user and the service provider shall have an equal role in controlling the exchange of profile data. That is to say, if the service provider’s read permissions are not satisfied for a given exchange, the exchange will not occur; if the end user’s read permissions are not satisfied for a given exchange, the exchange will not occur.
An end-user’s profile data is organized as a hierarchical collection of attribute-value pairs. Pairs are grouped into sections, which themselves may contain other sections. Sections not contained by any other are referred to as top-level sections. Sections are referenced as dotted strings. For example, the "episodesShown" attribute in the "bart" section would be referenced "bart.episodesShown." Section and attribute names shall be case insensitive.
In order to simplify the mechanism for naming sections while ensuring uniqueness, we leverage the existing domain registration infrastructure and use the entities’ reversed domain name (root and second level), with ‘/’ substituted for ‘.’, to avoid confusing section hierarchy with domain name hierarchy. From our previous example, all profile elements stored by ACME Grommets would be organized under /com/acme in the profile. This approach is meant to correspond with the current scheme for Java packages, and simplifies both section naming and section authority identification.
The section authority is defined to be the entity specified in the section name (e.g. acme.com, from the previous example). A section authority has rights to change the service provider’s read/write permissions on attributes within that section, and is not subject to the service provider’s read/write permissions of that section. In other words, the section authority controls the service provider half of the permissions for that section, and is not subject to those service provider permissions. The section authority is subject to the user permissions of that section.
The encoding of profile data shall be described using a MIME container. Furthermore, all compliant implementations shall understand the MIME type text/directory, described in [IETF-VCARD] based on the vCard standard described in [VCARD]. It is envisioned that, over time and through the evolution of this and related standards, other encoding formats will be explicitly included in the standard as well. Furthermore, other encoding formats may be used among custom OPS-compliant applications, so long as they can speak with standard OPS-compliant systems via the vCard encoding.
A full syntactical description of expressing attribute-value pairs (equivalent to profile attributes and values) can be found in [IETF-VCARD].
The risks associated with the abuse of user’s privacy advocate a diligent use of leading security technologies, most prominent of which are public key cryptography, digital certificates, and public certification services. OPS compliant applications shall implement the security mechanisms described in this document. Services using OPS are in turn free to choose the level of security employed in their service. The approach to security in OPS is therefore to allow the end users and services to choose the level of security appropriate for transactions. For example, a user may be willing to disclose browser preferences (likesFrames, etc.) indiscriminately. OPS provides foundations for varying levels of security in identity authentication and communication, and by requiring OPS compliant applications to implement security measures, allows the final choice to be made by the end user and/or service.
Reliable Identity. A reliable service provider identity is the combination of digital certificate, a domain identity, and an signed pair SIGN( (domain, UTS_timestamp) , service provider). The domain must be equal to or more specific than the authority presented in the certificate. For example, if the certificate applies to acme.com, the domain must be acme.com or homer.acme.com, or any machine or subdomain within that domain. The client may reject the identity if the timestamp is not within a reasonable interval from the client’s current time.
Non-reliable Identity. A non-reliable identity check is available via reverse DNS of the service provider machine. The specified domain must then be equal to or more specific than the name yielded from the reverse DNS query.
An identity is then expressed as:
identity = [ reliableId | unreliableId ]
reliableId = {
cert(I),
domain_string,
SIGN((domain_string,UTS_timestamp), I)
}
unreliableId = { domain_string }
At least two parties are involved in every profile exchange, the end user and the reader/writer. Often, however, a trusted third-party will audit or verify that a profile reader/writer abides by the policies they describe. This assertion is in turn provided to the end user as additional assurance of the security and safety of a profile exchange. In OPS, we term this assertion a credential. We must then insure that:
• credentials cannot be easily forged,
• credentials can be revoked, and
• credentials valid for one entity cannot be passed from one entity and usefully presented by another entity.
The raw materials for a credential are:
credentialInfo = { credentialName, credentialLevel, entityName }
credentialName = token
credentialLevel = number
entityName = token
To insure the validity of the assertion, the 3rd party must
digitally sign it. To further insure the identity of the party presenting
the credential, it must then be digitally signed by the presenter. Therefore,
a credential consists of a doubly signed package:
credential = {
cert(3rd party),
credentialInfo,
SIGN(SIGN(credentialInfo,3rd party), reader/writer)
}
where:
credentialLevel the numeric audit level, such as 2
entityName the audited party’s name, such as "acme.com"
Additional discussion of OPS security can be found in Section 6, "Security Considerations."
When a profile reader wishes to access an end user profile, it must present a profile request object which outlines:
1. The reader’s identity
2. The profile information requested of the end user
3. The intended usage codes for each section of the profile, in machine readable form
4. The fallback mode for each section of the profile, in machine readable form
5. The reader’s credentials
6. The terms of exchange, in human readable form
Identity. As described above, in Section 4.1.
List of Profile elements requested. A list of requested profile sections is provided. Each list element includes:
Profile Element Identifier. A string containing either a unique attribute identifier (such as demographics.postalCode) or a unique section identifier (such as demographics), which attempts to retrieve all attributes from a given section.
Intended Usage Codes. A machine-readable encoding of the profile reader’s usage of the end user’s data is required. In all cases, the intended usage must also be described in the terms of exchange, described later in this in document. A usage code is defined as:
UsageCode = { code, level, [ explanation ] }
where:
level a number representing the usage level, such as "3". Each code set will define the meaning of each level.
explanation a short description of the usage, such as "Online ads"
Fallback Mode. Should the requested information be unavailable or access not permitted, the fallback mode tells the user agent whether this is a fatal or non-fatal error. If fatal, the user agent won’t send partial results, it will send nothing. If non-fatal, the user agent will merely omit that profile element. (Note that it is not appropriate for a service to declare that it will accept partial results under a circumstance in which it will not allow the user to proceed with only those partial results; enforcement of this, however, is only possible through external processes rather than through direct technical means.) Under no circumstances is the reader notified whether the sender simply did not have that information available or whether the sender actively chose not to share their information.
| REQUIRED | If access is not permitted or the value is not available, the profile exchange will be aborted. |
| OPTIONAL | If access is not permitted or the value is not available, the profile exchange will continue without the specified attribute. |
ProfileElementRequest = {
attribute_or_section_name,
UsageCodes*,
fallbackMode = [ required | optional ]
}
Credentials. The reader’s credentials provide additional information
about the reader’s identity and practices. A full description can be found
in Section 4.2, "Credentials."
Example credentials include:
• 3rd party auditing of the reader’s data handling practices
• the reader’s inclusion in a larger group of readers, all of whom have mutual access to the same section(s)
Terms of exchange (TOE). The terms of exchange communicates the intended usage of the end user’s profile information in a human readable fashion. The terms of exchange restates (more fully) the machine readable usage codes. For example, "Acme Grommets will only use the information collected for finding you better grommets on this site." For compactness, the terms of exchange can be represented as a link to content residing elsewhere. The user agent can then, at its discretion and convenience, retrieve the terms of exchange for logging, display, or other purposes. Optionally, the terms of exchange contract can be digitally signed, providing the ability to verify the contents. The signature is of the form SIGN(HASH(TOE text), profile reader). Lastly, the TOE section includes a Boolean value indicating whether or not the user must digitally sign the TOE, providing the profile reader verifiable evidence of the acceptance of the TOE by the end user. If the user refuses to sign the TOE, the profile element shall behave as if permission was denied by the user. Formally, a terms of exchange element is:
TOE = { content, needs_signature, [ signature ] }
where:
needs_signature A Boolean value indicating whether the reader requires the user to digitally sign acceptance of the terms of exchange.
signature An optional profile reader signature verifying the contents of the terms of exchange. Expressed as SIGN(TOE text, reader)
ProfileRequestObject =
{ identity, ProfileElementRequest*, credential*, TOE }
After the profile read request is transmitted, a corresponding profile
object may be returned (or none in the case that permissions or other facilities
fail). A profile object is of the simple format:
ProfileObject = {
ProfileElement {
mime_type,
content
}
[ cert(user), SIGN(HASH(TOE text), user) ]
}
where a ProfileElement is a MIME entity as described in Section 3.2,
"Communication Encoding."
A profile write operation is a request from a service provider to store a profile element in the end user profile. A profile writer must provide proof of identity, third-party certifications, the desired property write operations, and directives specifying the intended accessibility of the data (i.e. service provider permissions). Permissions replace any preexisting service provider permissions if and only if the domain identity matches the property’s top-level section name. As with any profile element, both the section authority’s permissions and the user’s permissions must be satisfied for an exchange to succeed. For example, if acme.com successfully writes to com.acme.favoriteGrommets, the permission sets are replaced. However, if acme.com successfully writes to com.bart.likesTV the permissions are not replaced.
A section authority can be prevented from writing to "their" section by the user’s write permission set. Either the user of the section authority can prevent a third party from writing to "another’s" section. If the section authority has not yet created that section, third party attempts to create the section must fail. This prevents erroneous data attacks against section authorities from third parties. Multiple profile attribute writes can be combined into a single message if the identity and credential fields are identical. A profile write is of the format:
ProfileWrite =
{
identity,
credential*,
ProfileUpdates {
propertyName[;propertyModifier]:propertyValue
permissions*
}*
}
The syntax of the permission set is described in [OPS-PRAC].
OPS attempts to insure that profile information is securely communicated and managed. OPS implementations must also consider that:
• Service providers must protect the privacy of information given to them by users.
• Users must be able to determine to some degree of assurance that a service provider will protect their information from unauthorized disclosure.
• Service provider’s audit status and "trust" status may change quickly; an entity that was once trusted may have its credentials revoked or re-assessed.
• Sensitive profile information must be secured from unauthorized disclosure while stored unattended on the user’s workstation.
• All profile information must be secured from unauthorized modification while stored unattended on the user’s workstation.
• Providers of value-added information or services must be able to determine the authenticity of a user’s claim of right to access the subject information or service. For example, if a user claims they are a certain age, the service provider must have the ability to verify whether or not that claim is correct.
Privacy of Information on Workstation. Privacy-sensitive profile information stored on the user’s workstation should be encrypted to prevent unauthorized disclosure. If the user fails to protect this information, claims of privacy violations against malicious service providers are significantly weakened.
For ease in key management, one approach is to usa a single symmetric key to encrypt all sensitive attributes. This key in turn would require protection from disclosure. A weak form of protection is provided by the use of a user-generated passphrase as a key-encryption key. A more diligent solution would employ a user’s private key to encrypt the attribute encryption key.
Privacy of Information when in transit to a Service Provider. It is often necessary that the exchange of attributes between service provider and user maintain the privacy of this information while in transit to the service provider. When communication security is required, this specification requires the use of end-to-end cryptographic solutions to establish a secure session prior to any exchange of attributes. This specification also requires user agents to alert users as to the level of security employed in transit. [OPS-HTTP] describes specific encryption mechanisms (namely SSL) for use in conjunction with the HTTP protocol.
When stored into a vCard encapsulation, certificates shall be incorporated as a binary object in compliance with the LDAP specification addressing the same requirement. The certificate can also be "pointed at" using standard vCard linking methods. When extracted -- or exported -- from the vCard object for subsequent transfer to another medium, the output of such process shall be the DER encoded octets of the certificate.
When processing certificates, OPS compliant applications shall reference a Certificate Revocation List (CRL) prior to accepting an otherwise valid certificate. CRL processing shall be compliant to PKIX Part 1. In lieu of reference to a CRL, OPS compliant software may refer to online revocation status services to obtain the same information. These services must be compliant to PKIX Part 2, Section 4. The length of time an application chooses to cache CRL information is not specified by this document.
Applications claiming OPS compliance must abide by the security policies and mechanisms (in addition to the other policies and mechanisms) described in this document. The security level at which services and end users are comfortable sharing data will evolve independently from the capabilities of OPS compliant applications. These capabilities include X.509 based certificate management, encrypted data transfer, and digital signatures.
When processing certificates, OPS compliant applications shall provide the end user the ability to: 1) view the text of the Terms of Exchange, and 2) view the identity of the certificate authority providing verification of the service provider’s identity.
First and foremost, this document would not have been possible without the team that came together at the "OPS Summit": Sean Gaddis, Martin Haeberli, Saul Klein, and Greg Smirin.
A number of people were involved in reviewing and contributing to the drafts: Brian Behlendorf, Marshall Behling, Joe Coco, Taher Elgamal, Tony Fernandes, Ramanathan Guha, Tim Howes, Jesse Hull, Phil Karlton, Lou Montulli, Paul Perry, David Ritter, Jonathan Sheena, Mike Toth, and Jeff Weinstein.