XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.

advertisement

Privacy and XML, Part 2

May 01, 2002

XML-Based Techniques Relevant to Privacy

There are a number of efforts currently underway in standards bodies and other organizations to address various aspects of privacy with XML-based technologies. This section gives an overview of this work, noting which of the privacy concepts discussed in the first part of this article are addressed by different XML initiatives.

P3P

Relevant Privacy Concepts
• Privacy Policy
• Transparency
The Platform for Privacy Preferences (P3P) is a protocol developed by the World Wide Web Consortium (W3C). P3P (on the server side) defines an XML-based language by which Web sites can describe their privacy policies in a machine readable format. Categories of information include the contact information of the legal entity making the privacy statement, whether users will have access to information collected about them, different types of data being collected, the purpose(s) for collection, and which organizations will have access to the collected data. P3P is a response to the long, non-machine-readable, and often confusing or vague "Privacy Policies" that many sites offer to users. The following listing displays a P3P policy for a fictitious Web site.

<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
<POLICY discuri="http://www.website.example.com/p3p.html">
    <ENTITY>
    <DATA-GROUP>
        <DATA ref="#business.name">WebSite.com</DATA>
        <DATA ref="#business.contact-info.postal.street">200
            Main Street</DATA>
    </DATA-GROUP>
    </ENTITY>
    <ACCESS><nonident/></ACCESS>
    <STATEMENT>
        <PURPOSE><admin/><develop/></PURPOSE>
        <RETENTION><stated-purpose/></RETENTION>
        <DATA-GROUP>
            <DATA ref="#dynamic.http"/>
        </DATA-GROUP>
    </STATEMENT>
</POLICY>
</POLICIES>

This P3P policy expresses that the company "WebSite.com" does not acquire any Personally Identifiable Information and tracks dynamic HTTP data for administrative and development purposes only.

Microsoft has included client support for P3P in Internet Explorer 6, providing an interface by which users can indicate their own privacy preferences, as shown in the following screen capture.

Options

As this figure demonstrates, Microsoft's early support for client-side P3P entails giving the user control over cookie behaviour.

Note: P3P policies covering the use of cookies can be expressed in a condensed form called compact policies. The cookie filtering of IE6 actually requires these compact policies as opposed to the full XML policy.

If the user browses a site with either a policy that conflicts with the user's recorded preferences, or a missing privacy policy, the user is warned of the situation through an icon in the Explorer window's Status bar (see the following figure) and can then make a choice regarding how they interact with that site.

XACML - XML Access Control Markup Language

Relevant Privacy Concepts
• Privacy Policy
• Access Control

XACML, an OASIS Technical Committee, is producing XACML, a proposal for capturing authorization policies for resources. XACML is expected to address fine-grained control of authorized activities (e.g., read, write, copy, etc.) based on, among other criteria, access requester characteristics ("only Senior VPs and above can view this document'), the protocol over which the request is made ("this data is only viewable if accessed over HTTPS'), and the authentication mechanism ("requester must have authenticated using a Digital ID'). XACML is relevant to privacy both because access control is one security mechanism by which corporations will ensure privacy (with respect to unintended use) for their customers, and because of the potential for XACML to be used as the syntax for capturing the privacy policy defined by that customer for information resources (such as a health record, for example).

The following is a sample of an XACML policy which says that patients are allowed to read their own medical records (which, it is assumed, are stored in XML). The policy illustrates the connection between XACML and the Security Assertions Markup Language (SAML), another OASIS initiative. SAML defines an XML syntax by which authentication and authorization assertions and queries can be expressed for delivery over the network. In the example, the assumption is that a SAML AuthorizationDecisionQuery has been received which questions what entitlements should be granted to a particular medical patient requesting access to their medical records.

<?xml version="1.0"/>
<rule>
  <target>
    <subject>
      samlp:AuthorizationDecisionQuery/Subject/NameIdentifier/Name
    </subject>    
    <resource>
      <patternMatch>
        <attributeRef>
          samlp:AuthorizationDecisionQuery/Resource
        </attributeRef>
        <attibuteValue>medico.com/record.*</attibuteValue>
      </patternMatch>
    </resource>

    <actions>
      <saml:Actions>
        <saml:Action>read<saml:Action>
      </saml:Actions>
    </actions>
  </target> 

  <condition>    
    <equal>
      <attributeRef>
        samlp:AuthorizationDecisionQuery/Subject/NameIdentifier/Name
      </attributeRef>
      <attributeRef>
        //medico.com/records/patient/patientName
      </attributeRef>
    </equal>
  </condition>

  <effect>Permit</effect>

</rule>

The resources for which read access are being requested are highlighted in blue, the conditions under which the access should be granted are highlighted in red.

XML Encryption

XML Encryption, currently a W3C Candidate Recommendation, is a proposal for an XML vocabulary for capturing the results of an encryption operation performed on arbitrary (but most likely XML) data. A critical feature of the XML Encryption proposal is that it supports the concept of encrypting only specific portions of an XML document, not only minimizing the encryption processing but, more importantly, leaving non-sensitive information in plain text form such that general (i.e., non-security-related) processing of the XML can proceed. The following figure displays a employee record with the salary element encrypted with the XML encryption tags in a separate 'xenc' name space. This example omits many of the details; the XML Encryption proposal is available if you'd like to see more.

<?xml version="1.0"?>
<employee id="b3456">
  <name>John Smith</name>
  <title>Senior Analyst</title>
  <salary>
    <xenc:EncryptedData>
      <xenc:CipherData>
        <xenc:CipherValue>AbC234ndZ...</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </salary>
</employee>

Only the intended recipient, presumably the employee in question or an appropriately authorized Human Resources representative, would be able to decrypt the contents of the <CipherValue> element to view the employee's actual salary.

XML Signature

Relevant Privacy Concepts
• Information Sharing
• Opt-In
• Authentication

XML Signature is another W3C proposal, current a Proposed Recommendation. XML Signature defines an XML Schema for capturing the result of a digital signature operation applied to arbitrary (but often XML) data. Unlike previous non-XML Digital Signature standards, XML Signature has been designed to both account for and take advantage of the Internet and XML. Please refer to our previous article for a detailed depth discussion of XML Signature.

XML Signature is especially relevant to privacy because, in the first place, in the context of information sharing programs like .NET My Services and Liberty, it will likely be through an XML Signature calculated on a SOAP request that a requesting application authenticates itself; and, in the second, because the user's opt-in confirmations could be captured as XML Signatures to guard against the user later repudiating their choice. This scenario is represented in the following diagram.

If the user were to click on the "Sign Confirmation" button, an XML Signature (using the user's private key) would be calculated over the relevant portion of the displayed HTML page and then archived, thereby preventing the user from subsequent repudiation.

Of course, current browsers do not provide the ability to perform digital signatures on displayed HTML, much less XML Signatures. Technologies do exist for extending the browser to provide these signing capabilities, and it's likely that XML Signature will eventually be supported.

Pages: 1, 2

Next Pagearrow