Comments on XML Encryption

The XML Encryption Working drafts do not provide sufficient information for
use in SOAP messages, SOAP headers and by SOAP intermediaries.  The
intersection of encryption with body and headers, and the processing model
therein, is underspecified.  

The draft states "  2. XML Instance Validity {WS}
      1. Encrypted instances must be well-formed but need not be valid
against
         their original definition (i.e. applications that encrypt the
element
         structure are purposefully hiding that structure.)"

It seems to me that in most cases, the encrypted instance will not be valid
against their original structure - only wildcard any content would work.  I
find this deeply troubling that a document could have a schema and each and
every application is somehow supposed to know that that schema will only be
valid after some specific processing.

I think that Encryption should allow specification of at least 2 schemas so
that the document is valid in both encrypted and decrypted states.
Alternatively, Encryption should state that it is not solving this problem,
that each application using Encryption must determine 

Given this issue of encryption as a transformation technology, it is unclear
to me how xml encryption would be used with SOAP headers, intermediaries and
various application schemas/processing models.  Let's take a sample use
case, which is that I want to encode an SAML assertion into a SOAP header,
and encrypt it.  I want to send a message to a target going through a SAML
intermediary doing processing of some kind, such as verification of an
authentication assertion.  The Assertion should only be decoded by the
intermediary, and should remain encrypted to the target.  

I imagine developers would create a schema to define the message and the
header.  The header would use some SAML schema type.  The intermediary needs
schemas that specifies the schema for encrypted data, the decrypted SAML
data, SOAP schemas and possibly .  And the target needs a schema for just
the encrypted SAML data.  

The intermixing of SOAP schema, Application/Target schema, intermediary (ie
SAML) schema, and XMLE schema is unclear.  I believe the following points
need to be clarified:

1. How an application uses XMLE in conjunction with it's own Schema,
particularly a SOAP application.  
2. How an application uses the XMLE processing model in conjunction with
it's own processing model.  I think it doubtful that encryption processing
can be "hidden" from the application.  
3. The treatment of encryption at processing nodes, such as SOAP
intermediaries.
4. Error conditions at intermediaries, such as failures of xmle/intermediary
schemas.
5. Specification of canonicalization format used, for recreating message,
either at intermediary or target.
6. Does xml encryption augment the infoset in any way?
7. Are any infoset augmentations lost when encrypting/decrypting?

My belief is that the xmle processing model needs refinement to work with
SOAP.  Taking my sample use case, I think the processing model (in RPC
style) could be:

1. Client, Target agree upon application Schema, which excludes the header.
client, target agree that header will be encrypted when it is at the target,
so agreement upon valid xmle schema
2. Client, intermediary agree upon header schema (SAML in this case) and the
valid xmle schema for the header.  
3. Client creates SAML Assertion header and message.  Client encodes SAML
assertion portion of header, leaving the Actor/mustUnderstand unencoded. 
4. Client sends message to intermediary
5. Intermediary receives message, validates header against the encrypted
schema (XMLE).  If there is an error, intermediary returns some kind of
encryption error, ie invalid
6. Intermediary decrypts message, validates decryption of header values to
ensury security, validates header against the unencrypted (SAML) schema,.
If there is an error, intermediary returns validatoin or application error,
ie invalid SAML assertion version.
7. Intermediary performs processing on header, potentially resulting in new
header (say setting hasHappened).  
8. Intermediary sends message to target
9. Target receives message, validates header against header rules(such as
check for hasHappened) and encrypted schema.
10. Target validates message against application schema. 
....

Cheers,
Dave Orchard
XML Architect
Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
m: 604.908.8425    f: 408.725.4310

www.jamcracker.com - Sounds like a job for Jamcracker.

Dave Orchard
XML Architect
Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
m: 604.908.8425    f: 408.725.4310

www.jamcracker.com - Sounds like a job for Jamcracker.

Received on Sunday, 15 July 2001 16:10:14 UTC