NOTE-OPS-StandardPractices.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 discusses required practices in OPS-compliant systems for permissions management, standard attributes, and transaction logging. Permission management refers to the user’s and service provider’s ability to control the distribution and maintenance of profile data. This document then describes a set of well-known sections of each user’s profile which are meant to provide immediate value to users and service providers by establishing a common foundation for commonly used data. Finally, this specification describes transaction logging, the ability to record a profile exchange for later referral and analysis.
This document is the third 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. A second document, "Implementation of OPS Over HTTP," covers implementation of the Open Profiling Standard (OPS) over the standard web protocol, HTTP.
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
[OPS-PROP] W3C Draft, "Proposal for an Open Profiling Standard"
[OPS-PROT] W3C Draft, "Implementation of OPS Over HTTP"
This document uses all terms defined in [OPS-PROP], as well as:
Well-Known Section. A well-known section is a profile section which must be recognized and "implemented" by all OPS-compliant systems. In this case, "implementation" means that a new user profile shall contain the well-known sections.
Well-Known Attribute. A well-known attribute is an element of a well known section with the meaning described in this document.
This document describes standard practices for OPS compliant applications. These standard practices include well-known profile sections and attributes, standard permission mechanisms, and transaction logging. The document assumes a cursory knowledge of the OPS framework specified in [OPS-PROP].
Well-Known Sections are intended to establish a common informational foundation for OPS compliant client and server applications. Sections for anonymous demographic information, numeric identification information, and contact information (a superset of existing vCard attributes) are included in this specification. Commerce and User Agent sections are mentioned in this specification, but their contents are delegated to existing standards bodies in those areas.
Permissions are constraints which, when evaluated, allow or prevent access or modification of profile data. There are four permission sets for each attribute or section, corresponding to the two fundamental operations (read, write) and the two parties (end user, service provider). For an operation, both the user and profile reader/writer permission sets must be satisfied. The amount of end user permission management necessary can be minimized using permission inheritance techniques. An encoding for permission set transfer is described in this document, as permissions must be sent over the communication channel. The storage of permission sets at the endpoints (end user machine and service provider systems) is not restricted by this specification.
The transaction logs record fulfilled requests and their context. These logs provide the end user the ability to track access of their personal data and hold profile readers accountable for the use of their profile information. The user agent is responsible for the management of the transaction logs, including secure storage, display, archival, and deletion; this specification describes the data needed to provide a complete record of a profile exchange.
Discussions and a more formal specification of well-known profile data, permissions management, and usage logging follow.
This specification includes a definition of standard sections which commonly benefit the user at a number of services. In order to conform to this standard, an application must implement and recognize these sections, and not define alternative profile section containers of the same data elements. Furthermore, these sections must have no section authority; the user fully controls access to this information.
The well-known sections are:
Globally Unique ID (GUID). The Globally Unique ID is unique among the set of all sender profiles, and is constant for the life of a profile. The GUID is generated in the same fashion as DCE UUIDs. Typically an OPS implementation would place higher constraints on the exchange of the GUID than Pairwise Unique Ids, as the GUID enables correlation across profile readers. GUID’s cannot be changed for a given profile.
Pairwise Unique IDs (PUID). This is a special section which returns to a reader an ID which it can use to identify the user over time at that site. The ID returned is algorithmically generated from the user’s GUID and the reader’s ID, in a manner such that, for a particular site, each GUID generates a unique PUID for a particular reader ID.
PUID = HASH(GUID, reader domain)The domain in the PUID is equivalent to the identity domain discussed in "Security Foundations: Identity" in [OPS-PROP]. The Pairwise Unique IDs are not stored within the profile - they are dynamically generated when needed. It does however have a corresponding permissions and transaction log data. Pairwise Unique IDs shall have default permissions such that they are transferred automatically. As with GUIDs, PUIDs cannot be changed for a given profile.
The following tables specify the formats of the well-known attributes. The formats are expressed in terms of the X.520 specification and [IETF-VCARD]. For example, the birth date (BDAY) is formatted in the same manner as the corresponding BDAY attribute in [IETF-VCARD]. Attributes contained here shall be referenced as <section_name>.<attribute_name>; e.g. DEMO.ZIP.
Demographics Section: DEMO
| Name | Description | Type |
| C | Country | based on X.520 Country Name |
| ZIP | Postal Code | based on X.520 Postal Code |
| AGE | Age | number |
| G | Gender | [ ‘M’ | ‘F’ ] |
| SN | Preferred Screen Name | UTF-8 |
Contact Section: CONT
Identification Properties
| FN | Formatted Name | FN |
| N | Name | N |
| PHOTO | Photograph | PHOTO |
| PHOTO.TYPE | Photograph Format Type | PHOTO.Type |
| BDAY | Birth date | BDAY |
Delivery Addressing Properties
| ADR | Delivery Address | ADR |
| ADR. | Address Type | ADR.x |
| LABEL | Delivery Label | LABEL |
| LABEL.x | Label Type | LABEL.x |
Telecommunications Addressing Properties
| TEL | Telephone Number | TEL |
| TEL.x | Telephone Type | TEL.x |
| Electronic Mail Address | ||
| EMAIL .type | Electronic Mail Address Type | EMAIL.type |
| MAILER | Mailer | MAILER |
Geographical Properties
| TZ | Time Zone | TZ |
| GEO | Geographic Position | GEO |
Organizational Properties
| TITLE | Title | TITLE |
| ROLE | Business Category | ROLE |
| LOGO | Logo | LOGO |
| LOGO .type | Logo Format Type | LOGO.type |
| AGENT | Agent | |
| ORG | Organization | ORG |
Currency: CUR. This section contains the user preferences and information for commerce, e.g. credit card information and electronic cash.
Structure to be determined by the relevant standards working group, either the W3C P3 working group, or another standards group as designated by the W3C P3 working group.
User agent preferences: UA. This section captures preferences relevant for to the user agent, for example, the user’s preference for frames or preferred language.
Structure to be determined by the relevant standards working group, either the W3C P3 working group, or another standards group as designated by the W3C P3 working group.
The permissions management data specifies what permissions end users and section authorities have granted on information that they administer. Permissions are sets of constraints which, when evaluated, allow or prevent access or modification to profile data.
The permissions model consists of access policies created by two separate parties, the top-level section authority and the end user, for two actions, read and write. In other words, there are four permission sets that apply to each attribute. In some cases (where well-known top level sections are concerned) the end user is the section authority, and thus in full control of permissions for those sections and attributes. Section authorities are either the end user or profile writer. These policies jointly govern the access to attributes within a profile, and both the user and profile writer policies must yield positive results in order for any data to be exchanged or modified. Permissions are stored for each attribute, there is no explicit permission inheritance model prescribed by this specification. Typical implementations will provide a management interface with some level of inheritance to simplify permission management.
User permissions. The user has the ability to grant and revoke permissions on ANY attribute. User permissions have the ability to revoke access by section authorities. This represents a "shared stewardship" of all profile data. For well-known sections, such as UserAgent.browser or Commerce.Currency, where the user is also the section authority, no separate permissions need to be specified.
Section Authority permissions. The section authority has the ability to grant read/write access to profile readers and writers for all named attributes under their top level section (except in the case where a user removes access). As described in [OPS-PROP], the section authority is determined from the section name, which begins with the reverse top-level and second level domain elements.
Permission Block Structure. For each attribute in a profile there can exist permission blocks which govern its access. Each permission block consists of two separate permission sets, read and write. Within each set are permission rules which must be satisfied before corresponding actions can be performed.
An individual rule is made of four elements: an action (e.g. ALLOW access), a restriction scope (e.g. ONLY these values), an operator (e.g. USAGE), and a list of match values to the operator (e.g. "Direct Mail") A rule can generate either no result or an action. A group of rules thus generates a group of actions, and all non-empty actions are then "and"-ed together to arrive at the single, final action. For example, take the following two-rule set:
"Allow entities proven to be from acme.com or ernie.com but not those from bert.com."
This rule set would translate to the two rules (not literally, but symbolically):
{ ALLOW, ONLY, AUTH_DOMAIN, (acme.com,ernie.com) }
{ DENY, ONLY, AUTH_DOMAIN, (bert.com) }
A description of rule components follows.
Action Codes
| ALLOW | Automatically allow the profile read or write. |
| DENY | Automatically deny the profile read or write. |
| ASK | Ask for user intervention before allowing or denying the read or write. |
Restriction Scopes
| ONLY | Trigger the action ONLY if the operator is satisfied. |
| EXCEPT | Trigger the action for all EXCEPT if the operator is satisfied. |
| ALL | Trigger the action in all cases. |
Operators and Arguments
| AUTH_DOMAIN | Satisfied if the certified identity of the reader or writer is included in the list of argument domains. See the profile read and write request descriptions for a discussion of certified identities. The match value may contain ‘*’ to indicate a wildcard (*.acme.com). |
| UNAUTH_DOMAIN | Satisfied if the identity of the reader or writer is included in the list of argument domains. Does not need to be cryptographically proven, can be inferred from reverse DNS. The same match rules apply here as in AUTH_DOMAIN. |
| SECURE_COMM | Satisfied if the profile exchange will occur over a secure communication channel. |
| INSECURE_COMM | Satisfied if the profile exchange will occur over an insecure communication channel. |
| AUDITED | Satisfied if the requester possesses at least one of the appropriate audit credentials. See the profile read and write request description for a description of credentials. The match list is a list of triplets of (authority, auditCertification, auditLevel). |
| Reader Specific Operators | |
| INTENDED_USE | Satisfied if the intended use of the data matches or is "more stringent than" the usages in the match list. The elements of the match list are pairs of (usageCodeGroup, usageLevel). See the usage codes section for a discussion of usage level ordering. |
| SIGNED_TOE | Satisfied if the terms of exchange contract is digitally signed. No match list is needed. |
The encoding of permission rules into vCard format simply equates one vCard property (one "line") to each rule. The line is formatted such that the property name is the profile entry name, the action codes, restriction scopes, and operators are property modifiers, and the arguments appear as a semi-colon delimited list to the right of the value marker. Lastly, we add a property modifier to determine whether the rule applies to read or write. The complete property modifier set is thus:
permissionModifiers = {
OWNER_READ | OWNER_WRITE | ALLOW | DENY | ASK |
AUTH_DOMAIN | UNAUTH_DOMAIN | SECURE_COMM | INSECURE_COMM |
AUDITED | INTENDED_USE | SIGNED_TOE
}
The following are sample permission rules in vCard encoding:
Semantic Meaning: "All verifiable members of the bert.com and ernie.com domains can read the ernie.prefs section, but only ernie.com can write."
com.ernie.prefs; OWNER_READ; ALLOW; AUTH_DOMAIN : *.bert.com;*.ernie.com com.ernie.prefs; OWNER_WRITE; ALLOW: *.ernie.comSemantic Meaning: "The user agent must ask the user’s permission in all cases."
com.bert.prefs; OWNER_READ; ASK; ALL com.bert.prefs; OWNER_WRITE; DISALLOW; ALL
When a profile reader wishes to access an end user profile, it must present a profile request object described in [OPS-PROP]. Part of this profile request object is a set of usage codes which describe the reader’s intended usage of the profile data. Certain users may allow automatic access to profile data if it’s only used for certain purposes. Therefore, for the most common uses of data, this document describes the standard usage codes:
| STANDARD.1 | Information to be used solely to provide a requested service to the end user. |
| STANDARD.2 | Additionally, information can be used by the collecting party and by the collecting party alone for its own private purposes, and sold anonymously in the aggregate. |
| STANDARD.3 | Information to be shared or sold with third parties. These third parties must comply with the terms of exchange offered the user by the collecting party. The collecting party will make available, upon request, a record of all third parties with which information may have been exchanged. |
The standard usage codes are meant to provide baseline interoperability among OPS applications and to enable simple transfer for the most common uses of data. Other usage codes can and will be defined, but implementations may be forced to explicitly ask for user permission when a usage code is not recognized.
OPS helps manage and simplify the process of profile exchange. If successful, portions of a user’s profile information will be exchanged with hundreds of third parties each with different uses and policies for handling the data. Therefore, the user needs a method for tracking which third parties have accessed each portion of their profile, and for what purpose.
Transaction logs record information about all profile exchanges. These logs provide the end user the ability to track access to their personal data and hold profile readers accountable for the use of their profile information. The user agent is responsible for the management of the transaction logs, including its display, archival, and deletion.
In the most common case, the user needs this log information to understand and manage the spread of their data; however, an important requirement is the ability to reliably reference the terms of a profile exchange to resolve a dispute about the use of that data. If a site asks for a user’s email address for "customer support purposes", and then sells that email address to a third party, the user needs to be able to prove that permission for such a transfer was not given. The log of a profile exchange shall minimally include:
ProfileExchangeLog =
{
transaction type - [ READ | WRITE | MODIFY ]
reader or writer identity - domain name or authenticated domain
identity
transfer context {
date_time
protocol - (HTTP, SSL/HTTP, email, etc.)
location - (URL, physical location, etc.)
}
profile elements transferred or changed {
profile_attribute_name
[ usageCodes* ]
[ profile_contents* ]
}*
[ {
String termsOfExchange
[ SIGN(HASH(TOE), reader/writer) ]
} ]
}
Note that the usage codes and terms of exchange section are only relevant
in read transactions, and thus optional entities in the ProfileExchangeLog
structure. This specification does not describe the contents of the profile_contents
element, as each application is free to choose whether it stores old and
new values, just new values, or simply a hash of the value, for example.
Implementations are required to conform to the provisions of the Security Considerations clause in [OPS-PROP].