- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Fri, 20 Oct 2000 17:16:48 -0400
- 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 UTC