Archives
What's New
Site Map
Subscriptions

Home
NetFlash
This Week
Forums
Reviews/buyer's guides
Net Resources
Industry/Stocks
Careers
Seminars and Events
Product Demos/Evals
Audio Primers

IntraNet


Error 404--Not Found

Error 404--Not Found

From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.


















For more info:

The Open Profiling Standard
From Netscape.

Open Profiling Standard Frequently Asked Questions

Implementation of Ops Over HTTP

Standard Practices for Ops Systems

vCard and vCalendar

vCard MIME Directory Profile

TRUSTe An alternative to OPS

Back to the IntraNet page


Open Profiling Standard: At home on intranets

By Mark Gibbs
Network World, 2/23/98

You might not think there's reason to care about the demographics of your intranet users - or at least as much of a reason as out on the 'Net, where knowing a visitor's gender, age and other attributes can lead to targeted sales.

But demographic information on intranet users can be important, too. Try supporting customized content for business customers entering your intranet - you'll be clamoring for a standard way of identifying all those people.

The Open Profiling Standard (OPS) proposal from Netscape Communications Corp., VeriSign, Inc. and Firefly, Inc. might be able to solve this identification issue. OPS' purpose is to provide a mechanism for controlled storage and retrieval of potentially sensitive information about the client on a client's computer by the client and servers. Moreover, OPS provides a standard structure for the information that allows for different levels of access.

By allowing the remote server to place information on the client, information about the user can be retrieved in subsequent sessions. This, for example, would allow an extranet user to reveal his name and address to a known, trusted server and allow the server to store the user's preference for that site.

OPS meets three objectives: informed consent, value exchange and control by source. Informed consent requires that a party requesting an individual's information must have that person's consent. The individual must know what will be done with the information provided.

Value exchange ensures that no one can collect information without offering the information provider something in return. This means a person's profile is not freely taken without benefit to that individual.

Lastly, information access is to be controlled by its source. That is, whoever creates profile information should control the permission for dissemination.

For example, a company that allows customers to access an extranet-based product catalog would obtain informed consent to OPS data from its customers. This ensures that the customers know who will be using the data and for what purpose.

Value exchange could be implicit in a customer's interest in the catalog, or a company could quantify it by offering a discount on purchases in exchange for OPS data. Control by source ensures that customers can control what data is in their profiles.

Outward look

The OPS system is similar to the cookie mechanism in that it allows a remote server to place and retrieve data on an OPS-enabled client. The difference is the type of data it deals with and the controls on access.

OPS is based on digital certificates and the Internet Mail Consortium-managed vCard electronic business card specification.

The OPS profile data is a hierarchical structure of named sections and subsections. These sections and subsections contain pairs of attributes and their values. For example, the section "demographics" might contain an attribute "age" with a value of "45."

There are three kinds of sections: well-known, permissions and transaction logs.

Well-known sections will define elements that are common to all OPS- compliant client and server applications. These sections will include anonymous demographic information, such as age, numeric identification information and contact information.

The permissions sections contain specifications of constraints which, when evaluated by the OPS-enabled client, allow or prevent access or modification of profile data. There are four sets of permissions for each attribute or section, corresponding to the two fundamental operations (read, write) and the two parties (end user, reader/ writer).

For an operation to take place, the user and profile reader/writer permission sets must be satisfied. The details of fulfilled requests are recorded in the transaction log section. Transaction logs provide the ability to track access to profile data so readers can be held accountable for use of that information.

The client controls access to part or all of the profile, except when explicit permission has been set. In this case, the client confirms whenever any remote server reads from or writes to the OPS profile. The access control specifies which remote systems can read and write data to which sections under what conditions.

A remote profile writer also can be granted access for modifying a section or sections' permissions. In such an instance, the profile writer becomes a section authority.

For example, when a user who has given consent accesses the Acme product catalog on an extranet, her choices are recorded in a section named acme. com. Once permitted and until the user revokes the privilege, acme.com is the section authority.

Two separate parties - the top-level section authority and the end user - create access policies for the read and write actions. This provides four sets of permission for each attribute.

Implementations typically will provide a management interface with the flow down of permissions from a section to its subsections.

Security

Technologies such as public-key cryptography, digital certificates and public certification services will be used to support OPS. End users and readers/writers will choose the level of security they consider appropriate for a particular transaction.

OPS specifies a means for end users to reliably verify the identity and practices of readers/writers using existing certificate methods and protocols.

But insecure profile exchanges - that is, those that don't use digital certificates - will be common on intranets. OPS specifies how the Domain Name System can be used to provide unreliable service identification.

Status

OPS developers submitted the Internet Draft in November 1997. More than 60 organizations have committed to support OPS. Among them are American Express Co., CommerceNet, Digital Equipment Corp., Hewlett-Packard Co., IBM, J. Walter Thompson and Sun Microsystems, Inc.

That said, most members of the OPS booster squad support the World Wide Web Consortium's (W3C) Platform for Privacy Preference Project (P3P). W3C is positioning OPS as part of P3P; it will not endorse OPS per se.

In light of this, it remains to be seen what happens with OPS. But one thing is for certain: OPS has been a great step forward in building a framework for handling private information.


Feedback | Network World, Inc. | Sponsor index
How to Advertise | Copyright

Home | NetFlash | This Week | Industry/Stocks
Buyer's Guides/Tests | Net Resources | Opinions | Careers
Seminars & Events | Product Demos/Info
Audio Primers | IntraNet