W3C home > Mailing lists > Public > xml-encryption@w3.org > October 2000

Re: proposed approach to XML encryption

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Fri, 20 Oct 2000 17:16:48 -0400
Message-Id: <4.3.2.7.2.20001020164023.034431f0@rpcp.mit.edu>
To: Mark Scherling <mscherling@xcert.com>
Cc: rnd@xcert.com, "Public XML Encryption List" <xml-encryption@w3.org>
Hi Mark,

Thanks for posting your thoughts regarding the authorization's requirements 
on XML encryption. ACL and authorization is likely to be out of scope for 
any W3C activity [1] (I think most folks believe such work should happen at 
the IETF, or in industry specific domains (e.g., DoD, medical, finance, 
etc.)), just as mandatory key structures and trust was out of scope for 
Signature. So to focus your requirements (and not speak to the substance of 
the authorization proposal) what do you see as the _critical _requirements_ 
on encryption? An open content model within an element (i.e. attributes from 
an external authorization namespace can be included)?

In Signature we provided ways for people to include their own KeyInfo (by 
making that an open content model [2]) and trust (by allowing them to define 
their own Signature semantic [3]) how do we accommodate authorization 
without actually getting into it?

My initial reaction is it depends on your authorization model (for which I 
admit there is no standard, but a fair amount of work). My uninformed 
_personal_opinion_ follows:

1. Your proposal (in my limited understanding) decorates native content (or 
encrypted content) with syntax from a authorization namespace. This means 
that elements would need to be changed, so we'd have to define the schema 
accordingly if that's possible.
2. Damiani et. al, [4] (in my limited understanding) specify authorization 
at the DTD level. This would be completely orthogonal (and they've done a 
lot of good research) but requires a specifications over DTDs, and I hope 
folks will be moving to schemas regardless.
3. XACL [5] (in my limited understanding) uses references to describe the 
ACL policies associated with native content. This requires no change to DTD, 
schema, or the content, can be deployed orthogonally, versioned easily, and 
can possible tie into RDF/database/semantic-web. You could even have 
multiple authorization policies associated with the content, each signed 
differently as needed.

Thoughts?

__

[1] http://www.w3.org/2000/09/XML-Encryption-Workshop.html
Related topics that are not part of XML Encryption (though they may provide 
requirements as an application) are:
       XML Access Control Policies: specifying policies and mechanisms 
beside encryption that control access to XML content.
[2] http://www.w3.org/TR/2000/WD-xmldsig-core-20001012/#sec-KeyInfo
[3] (e.g., http://www.w3.org/2000/10/xmldsig-p3p-profile/ )
[4] http://www9.org/w9cdrom/419/419.html
[5] http://www.trl.ibm.co.jp/projects/xml/doccont/xacl_e.htm



At 13:10 10/20/2000 -0700, Mark Scherling wrote:
>Attached is a proposed approach that could be used to identify and
>encrypt content.  It is recognized that some content within certain
>documents (i.e. medical records) must be view able by different groups
>with different needs.  The problem is to identify the group, the content
>they need and to ensure that access is restricted to that content is
>restricted.  The proposed example includes a simple example of a medical
>record with an approach using element attributes to identify different
>elements that require protection from unauthorized users.  The objective
>is to provide individually accessible elements to meet the needs for
>diverse access requirements.
>
>Please feel free to comment on the approach and I would be happy to
>present the concept at the next working group session on November 2.
>
>Cheers
>Mark Scherling
>Xcert International Inc.
>(604) 640-6210 Ext. 349
>


__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Friday, 20 October 2000 17:17:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:17 GMT