Enabling On-line Commerce

Security, Trust, and Negotiation

Dr. James S. Miller
World Wide Web Consortium
MIT Lab for Computer Science

Commerce on the Web

• Commerce is based on trust
• ...and negotiation
• ...and a legal framework

Trust, not just Security

• Do you trust your bank?
• Do you know where your money is?
• Do you really care?

Elements of Trust

• What is said
• Who says it
• Rules for deciding

Technical Agenda

• Metadata
• Digital Signatures
• Trust Management
• Negotiation (today's talk)

P3P: Privacy Protection

• Europe has strong data privacy laws to protect citizens from unanticipated uses of data collected during normal commercial transactions (i.e. spam)
• U.S. has strong data privacy laws to protect citizens from unanticipated uses of data collected by the U.S. government (remember Vietnam!)
• U.S. has strong consumer protection laws that arguably cover privacy concerns in the commercial sector
• The EU plans to enforce their laws
  • in cyberspace
  • across borders (i.e. into the U.S.)

Privacy: The Issues

• Eavesdropping
• Tracking (anonymous)
• Tracking (personal)
• Subsequent use of personal information
• Discovery of personal information

P3P Premises

• Eavesdropping is handled by TLS (SSL) or IPSec
• Anonymous tracking is supported
• Subsequent use is the key issue
  • "No disclosure" isn't reasonable for commerce (how are goods delivered?)
  • Notice and informed consent
  • Enforcement is partly technology, partly auditing
• Discovery by correlation is too hard to do and too hard to defeat

P3P Public Promises

• Users have privacy preferences
• Servers have privacy practices
• P3P provides a framework for a market
  • Invisible if practices satisfy preferences
  • Notification or negotiation if not
  • Release of information is automatic if user has given prior consent
  • "Informed consent through user choice"

What P3P Is About

• Informed Prior Consent
• Agreeing on protection of data
• Asking for data, subject to an agreement
• Explaining why you should provide the data

Terminology

Agreement
An agreement is a small unit of information that is sufficient to indicate that both parties have agreed on a common proposal.

Assuring Party
P3P assumes the existence of an entity which assures that the service will abide by its proposal; this assurance may come from the service or an independent assuring party.   The assuring party digitally signs proposals and is responsible for assuring their implementation by the service.

Agreements: The Issues

• Both parties agree on what practices will be applied to what data
• Agreement is independent of mechanism used to convey the data
• Agreement may be made prior to or concurrent with request to transmit data via P3P mechanism
• Agreement may be made in terms of explanatory references (e.g. "contact information", called categories)
• Agreement may be made in terms of names of data elements (e.g. "http://www.w3.org/P3P/StandardDataElements/User.FirstName")

Agreements: The Technology

1. the fingerprint of a proposal (if both parties agree that it need not be non-repudiable)
2. the fingerprint (as above) plus the digital signature and identity information of the assuring party (q.v.) that is countersigning a proposal already signed by the user
3. the fingerprint (as above) plus the digital signature and identity information of the user that is countersigning a proposal already signed by the assuring party (q.v.)

Technically, this corresponds to a small piece of metadata in RDF (Resource Description Framework) format that may optionally include a DSig 2.0-compliant signature.

Categories and Classes

• Categories are primarily for configuring the protection of data. Classes are primarily for transferring groups of related data elements.
• Categories are likely to be the naming system that users see and understand. Classes are primarily of interest to the people running servers.
• Both categories and classes are extensible by both the client and the server (new data elements can be created within existing classes, new classes can be created, new categories can be created, existing data elements can belong to new categories, etc.)

Standardization of Names

• Standard classes, whose names are known to all clients and servers.
• Standard categories, whose names are known to all clients and servers.
• Minimal set of standard named data elements that belong to these standard classes, along with their data type and a minimal set of named categories to which each standard data element belongs.

Transferring Data (bi-directional)

• Server requests data transfer, client approves and transmits or stores data
• Request for data (by server) may be accompanied by an existing agreement or a new proposal for agreement
• Requests for data can be made by specifying a name or a category (note that a single name may refer to many elements).
• Some data elements and sets of data elements have universally known names: these are the classes

Universal Negotiation Primitives

1. OK, OK (2 types)
2. PROP, proposal
3. RFD, request for data
4. RFP, request for proposal
5. RFT, request for text of proposal
6. TXD, transmit data (either direction)
7. SRY, (sorry) refusal with reason (4 types)
8. STP, stop negotiation

Negotiation Flow (part 1)

Negotiation Flow (part 2)

Privacy Protection: Not Just Technology

• P3P is a good technological base
• Existing or new legislation may be needed to handle
  • misrepresenting privacy practices
  • refusal to state privacy practices
• Enforcement requires auditing