RE: Attribute encryption & Blair's message

I'll let others say more about key distribution but let me just point
out that including key info in <EncryptedData> is optional.  In the
example Steve has laid out, it may well be feasible to NOT include any
key information at all in the <EncryptedData> and let the authorization
engine provide the key according such as what Daniel suggests.  Note that 
in such a scenario, it could still be disadvantageous to encrypt everything
because if Sally from accounting just needs the patient Joe Smith's
VISA card number, it could be inefficient to have decrypt the whole
dataset for that chunk of data.

Actually, I see the authorization model Daniel suggests as working
very well with the model Steve described.  Because XML Encryption enables 
the structure of an XML instance to
remain in plaintext while encrypting only sensitive content, it
would be quite feasible to perform a transformation on the encrypted
version of the example put forth by Steve.  In other words,
the document is encrypted as Steve suggests; the authorization engine
(as always) has rules like "you're from accounting, then I'll extract
the accounting-relevant elements, and send you the result".  The 
authorization may, or may not, be aware the accounting-relevant elements
contain encrypted data (that's up to the system designers). When the
accounting person gets accounting-relevant elements, she decrypts
their contents, and goes on with life as usual.

Ed

-----Original Message-----
From: Toth, Daniel (D.L.) [mailto:dtoth3@ford.com]
Sent: Monday, January 15, 2001 2:16 PM
To: 'xml-encryption@w3.org'
Subject: RE: Attribute encryption & Blair's message


Although I support the idea of attribute encryption in general,
the practical aspects of key distribution in Steve Wiley's example
elude me. How do we ensure that only those that require access to
encrypted attributes have access to the keys. Which health care
professionals have a need to know?
It seems that we're mixing up authentication with authorization
here. By encrypting attributes for various departments, we encode
authorization levels into the message itself; something that is 
usually left externally configurable. A better solution here might
be to have the entire message encrypted with one key, and have the
accessing applications sort out authorization based on role,
transforming the original message to one that is appropriate for the
individual (or role).

-DanT

Daniel Toth -- dtoth3@ford.com
Senior Integration Architect, PL Implementation - IT Research & Planning
Desk:(313)322-9103    FAX:(313)621-8392


> -----Original Message-----
> From: Steve Wiley [mailto:steve@myProof.com]
> Sent: Friday, January 12, 2001 6:48 PM
> To: Blair Dillaway; 'Thane Plambeck'; 'xml-encryption@w3.org'
> Subject: RE: Attribute encryption & Blair's message
> 
> 
> At 02:39 PM 1/11/2001 -0800, Blair Dillaway wrote:
> >I remain unconvinced that there is sufficient value in 
> encrypting only 
> >attribute values, while trying to maintain some similarity 
> to the original 
> >schema. I simply don't buy the argument that recipients of 
> such encrypted 
> >docs can do meaningful and robust interpretation of the containing 
> >elements while ignoring the cipher text and encryption 
> information. If the 
> >recipient only understands the original schema, then the encrypted 
> >document in invalid. On what basis should they decide to 
> ignore improperly 
> >encoded and/or extraneous data within an element? Simply ignoring 
> >everything you don't understand in an element, while 
> assuming the rest is 
> >something you do understand, seems incredibly brittle and 
> error prone.
> 
> Here is an example that is close to real applications that 
> our company is 
> working with.  It is very workable without forcing the 
> customer to change 
> their XML schemas.
> 
> Medical establishment example:
> 
> <Patient contagion-alert="blood" contagion-level="high" . . . . >
>    <name>Jane Doe</name>
>    <address> . . . . . .
>    <account-balance>$120.00</account-balance>
>    . . .
> </Patient>
> 
> The above patient record alerts practitioners that the 
> patient has a highly 
> contagious blood condition (possibly HIV). The practitioners 
> need to know 
> this, but for patient privacy the billing department should 
> not see this 
> information.  Likewise the medical practitioners should not see the 
> <account-balance> because all patients should be treated equally.
> 
> The following document is sent to both departments:
> 
> <Patient contagion-alert="HJE8...UHE==" 
> contagion-level="IjBHy...jkJM=" . . 
> . . >
>    <name>Jane Doe</name>
>    <address> . . . . . .
>    <account-balance>UHyhJ...J87Hn</account-balance>
>    . . .
> </Patient>
> 
> The company could distribute a single application for viewing patient 
> records.  The treatment room has the key to decrypt the 
> 'contagion-alert' 
> and 'contagion-level' attributes. Someone in the treatment 
> room would  see 
> this display:
> 
> The patient name is: Jane Doe
> Contagion Info: WARNING, high risk of blood contagion
> Account balance: UHyhJ...J87Hn
> 
> The billing department has the key to decrypt the <account-balance>. 
> Someone in the billing department would see this display:
> 
> The patient name is: Jane Doe
> Contagion Info: NOT AVAILABLE
> Account balance: $120.00
> 
> The application assumes that if 'contagion-level' is not 
> "high", "low", or 
> "none" then the information is not available.  At worst the 
> application can 
> just display the cypher-text.
> 
> In the case of the <account-balance>, it just displays the 
> data.  If it 
> isn't readable, that is what is desired.  Or, the application 
> could check 
> for currency formats but it is not necessary.
> 
> As for automated processing of the information, the billing 
> department 
> application should not need to process the 'contagion-alert' and 
> 'contagion-level' attributes.
> 
> The treatment room record processing does not need to process the 
> <account-balance> element.
> 
> It all works.  It is not complex.
> 
> 
> >Robust processing of encrypted docs implies knowledge of the schema 
> >against which the encrypted document is valid. Hence, moving 
> sensitve 
> >attribute info into child elements for those few apps that 
> only want the 
> >attribute encrypted, doesn't seem that onerous to me. 
> Especially if it 
> >signficantly simplifies building encryption/decryption processors.
> 
> It could be very onerous for companies that have pre-existing 
> XML data and 
> applications.
> 
> But the main issue for me is "What is my job as a software 
> engineer?".  I 
> believe that (in the XML world) it is my job to provide simple and 
> maintainable applications and standards for handling data.  Elements 
> contain significant data.  Attributes contain significant 
> data.  My job is 
> to supply solutions for encrypting that data if there is a need for 
> it.  And, there is a need for it.
> 
> Good development tools should simplify the building of 
> encryption/decryption processors.  Restricting the 
> flexibility of business 
> applications is not a good way to simplify.  Attributes were 
> designed into 
> XML to be used.
> 
> >BTW, I am still open to changing my mind on this if we can identify 
> >applications where the value of attribute only encryption 
> justifies the 
> >complexity.
> 
> See the <Patient contagion-alert. . .> example above.
> 
> I admit that as a designer I am looking at these issues from 
> a business 
> perspective rather than an academic perspective.  I can 
> supply some other 
> examples if need be.  I want to give businesses easy concepts to 
> understand.  I would much rather sell or explain a simple 
> concept to a 
> customer, and write more complex code, than the reverse.  
> Customers are 
> used to using attributes and elements to store data.  I 
> really do not want 
> to have to explain why they can only store non sensitive data 
> in attributes.
> 
> Respectfully,
> Steve Wiley
> 
>