W3C home > Mailing lists > Public > public-p3p-spec@w3.org > June 2003

Comments on "[P3P]: Beyond HTTP"

From: Hugo Haas <hugo@w3.org>
Date: Mon, 2 Jun 2003 20:34:53 +0200
To: public-p3p-spec@w3.org
Message-ID: <20030602183453.GL32077@w3.org>

[ Sending this to public-p3p-spec@w3.org instead of
  www-p3p-public-comments@w3.org as indicated since the latter is
  closed. ]

Please find below some comments regarding:

  [P3P]: Beyond HTTP

  P3P Task Force Report 18 April 2003
  $Revision: 1.17 $ on $Date: 2003/05/27 22:32:09 $ GMT


Comments are inline:

| [P3P]: Beyond HTTP
| P3P Task Force Report 18 April 2003
| Introducing A Web Application Scenario
|    An interesting/difficult requirement for Web applications is that of
|    initial data solicitation under a privacy policy and subsequent
|    delegation/propagation of the solicited data under the policy. Our
|    scenario is inspired by:
|      * [24]S030 Third party intermediary scenario of the [25]Web Services
|        Architecture Usage Scenarios [WSAUS], and
|      * The [26]IETF Provision Registry Protocol's (PROVREG) privacy
|        scenario
|    Our scenario is not intended to be a completely accurate
|    representation of real world requirements, nor does our document
|    necessarily provide a satisfactory solution. Instead, this scenario is
|    intended to be sufficiently represenative to serve our primary purpose
|    of exploring generic Web application privacy issues and providing
|    recommendations towards [P3P] reuse in that context.
|   Scenario Definition
|    Quoting from the [27]PROVREG Charter:
|      Administration of Domain Name Service (DNS) registration
|      increasingly
|      distinguishes between the operation of a "back-end" registry data
|      base
|      service for registrations, versus "front-end" support services by
|      registrars who interact with registrants and with the registry.
|      Especially for various Top-Level Domains, the desire is to permit
|      multiple registrars to share access to the database.  Conversely,
|      there
|      is a desire to allow a registrar to access multiple registries via
|      the
|      same protocol, even if the registries differ in operational models.

This is a great example. We should leverage it for the Web Services
Architecture Usage Scenarios document.

| Soliciting Data from the User and Referencing Policies
|    In our scenario, information is solicted from the [34]User by the
|    [35]Soliciting Service so as to register the user's domain name. This
|    section describes how a policy can be made known to the user agent.
|    [[36]Section 2, P3P] provides four mechanisms for indicating the
|    privacy policy of a site, the policy reference file
|     1. may be located in a predefined "well-known" location, or
|     2. a document may indicate a policy reference file through an HTML
|        link tag, or
|     3. a document may indicate a policy reference file through an XHTML
|        link tag, or
|     4. through an HTTP header.
|    In our scenario, the Soliciting Service has a P3P privacy policy at
|    the following URI:
|  href='http://registry.example.com/P3P/PolicyReferences.xml'
|    [37]Adopting applications that rely upon a data format other than
|    [XHTML] to solicit information SHOULD support the first (well known
|    location) and fourth (HTTP header) mechanisms; [38]adopting
|    applications MUST NOT ever (mistakenly) release information to an
|    application it is not familiar with on the basis of [P3P] mechanisms
|    that it is familiar with. [39]Adopting applications MAY provide a
|    means of associating a policy reference file with their own format.

I think that for Web services, the policy (or the link to a policy
reference file) should be expressed as a feature. Features are the
extensibility mechanism of SOAP 1.2[55]. The Web Services Description
WG is working on their description and the Web Services Architecture
WG is evaluating their role in the overall architecture.

Feature is basically a functionality which can be expressed in
different ways. In this case, the policy / policy reference would be
carried by the SOAP message:
- inside the envelope.
- by the binding:
  - an RFC2822 header for an email transfer.
  - an P3P's HTTP header when using HTTP.
  - other means.

|   Associating with an (Optional) WSDL Description
|    An optional feature a Web service is to offer potential clients a
|    [WSDL] description of its capabilities prior to interaction. Or, it
|    might list itself in a directory [UDDI] such that user agents can
|    peruse a description in order to select the most appropriate service.
|    An obvious question in these circumstances is should a privacy
|    statement be included in a [WSDL] description or [UDDI] entry? This
|    would certainly be useful to web service clients that want to select
|    services on the basis of a privacy practice.

WSDL 1.2 has a mechanism to express features. If you were defining
such a P3P feature, it would define what to express (the properties of
the feature) in WSDL 1.2 (e.g.a URI reference, etc.). See [56] for the
description of features.

Registries would most likely refer to the service description and you
would get that information for free.

| Transferring Data to a Third Party
|   The Movement of Information
|    In an intermediary scenario, data (defined broadly to include service
|    privacy privacies, and personal information and privacy preferences)
|    may move in many directions between the parties of the transaction.
|    There are numerous models of interaction between the participants and
|    the flows of information. For example:
|      * In [P3P], a user's information is solicited by providing it with a
|        privacy policy, which the user's client evaluates in light of the
|        user privacy preferences. While the released information must be
|        redistributed in accordance with the p3p:recipient field, [P3P]
|        itself is not necessarily used to mediate those subsequent
|        interactions. A [P3P] interaction is one-to-one with a focus on
|        the user solicitation.
|      * In PROVREG, a privacy policy governs the interaction between
|        services (one or more registrars and the final registry). While
|        the information exchanged my include user data, the user
|        solicitation is out of scope.
|      * In EPAL ([47]Enterprise Privacy Authorization Language), "While
|        [P3P] formalizes privacy promises to be advertised (i.e., business
|        to consumer), EPAL formalizes privacy authorization for actual
|        enforcement within an enterprise or for business-to-business
|        privacy control."
|    One can consider three variables with respect to the flow of
|    information within a network:
|    Direction of Flow
|           In [P3P], policies flow to the user agent, preferences stay
|           local to the user agent, and information flows to services. One
|           can also conceive of an exchange in which a user publishes his
|           preferences and services must agree to them, or user
|           preferences accompany user information in its journey -- as
|           we've also done in our example scenario via my:Privacy element.
|    Points of Decision
|           In [P3P], the user's agent (the point of decision) is typically
|           his network client. However, one can also imagine a trusted
|           network service acting as the user's agent (managing the user's
|           identity, information and enforcing his preferences). In
|           PROVREG and EPAL services themselves are exchanging policies
|           and making decisions.
|    Points of Aggregation
|           A service which solicits information from a user for
|           redistribution to other services might choose to first collect
|           and combine the policies of its peers and represent the
|           p3p:recipients as having the "same" policy, or it might ask for
|           separate parcels of information under a different policy
|           corresponding to each of the recipients which it transfers data
|           to.

This is right on target.

|   The Scope of Layers and Bindings (HTTP and SOAP)
|    Does the [P3P] policy belong at the SOAP level, or HTTP? In the
|    majority of cases SOAP will be transported over HTTP, what happens if
|    both collect data? Given that a higher level application will likely
|    know its dependencies, but its dependencies will not know the
|    characteristics of those using them:
|    [49]Adopting applications MUST specify where relevant [P3P] statements
|    can be found. We RECOMMEND that normative association (not including
|    [WSDL] or [UDDI]) be limited to the higher/application layer. We
|    RECOMMEND that a higher/abstract layer MAY include the privacy policy
|    of layers it is dependent upon, but that lower layers SHOULD NOT
|    represent the policies of higher layers. For example, an application
|    that transfers data with SOAP over HTTP that uses cookies, SHOULD
|    specify:
|     1. the [P3P] policy associated with SOAP is normative and includes
|        the HTTP policy, or
|     2. there are distinct [P3P] policies associated with the SOAP and
|        HTTP layers.

Isn't this already the case with a Web server nowadays? The HTTP
stack/server may have some logging policies different from the ones a
CGI has, for example.

|   Intermediaries
|    Even before data makes it to the Service Provider and its
|    p3p:Recipients, if any, the information might travel through various
|    intermediaries in order to reach its destination. [[53]Section 1.1.3,
|    P3P] speaks to these cases as follows:
|      P3P policies represent the practices of the site. Intermediaries
|      such as telecommunication providers, Internet service providers,
|      proxies and others may be privy to the exchange of data between a
|      site and a user, but their practices may not be governed by the
|      site's policies. In addition, note that each P3P policy is applied
|      to specific Web resources (Web pages, images, cookies, etc.) listed
|      in a policy reference file. By placing one or more P3P policies on
|      a Web site, a company or organization does not make any statements
|      about the privacy practices associated with other Web resources not
|      mentioned in their policy reference file, with other on-line
|      activities that do not involve data collected on Web sites covered
|      by their P3P policy, or with offline activities that do not involve
|      data collected on Web sites covered by their P3P policy.
|    This semantic continues to stand in circumstances "beyond HTTP."
|    However, we may now make the following recommendation:
|     1. Adopting applications that want to ensure the privacy of user
|        information SHOULD take steps to ensure that no information is
|        released to a network intermediary that is not covered by its P3P
|        policy. This may be expressed via policy (such as [SOAP] headers)
|        or ensured via various end-to-end mechanisms such as session
|        security (e.g., [TLS]) or document security (e.g., [XENC]).
|    Do we need to say anything more about forwarding and active
|    intermediaries? Should we define a "[54]P3P Policy for SOAP
|    intermediaries" that only permits the data to be used for the "current
|    purpose/admin and no retention" that SOAP intermediaries MUST use?
|    Reagle prefers to rely upon the text above unless we are further
|    pressed with actual use cases.


There is something else which probably needs to be underlined. P3P
reference policies for resources, whatever the operation on them is.

With Web services, what the resource is is a little fuzzy (a car? the
application in charge of selling cars? some state about the sale of a
car?) and WSDL defines the interface to this target resource. The
level of granularity here is probably the WSDL operation.



  55. http://www.w3.org/TR/2003/PR-soap12-part1-20030507/#soapfeature
  56. http://www.w3.org/TR/2003/PR-soap12-part2-20030507/#soapfeatspec
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
Received on Monday, 2 June 2003 14:35:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:17 UTC