My thoughts on XML Encryption

["Orchard, David" <dorchard@jamcracker.com>]

I sent the following to the XML Protocols working group.  Some or all of
this can be used by SAML.

Cheers,
Dave


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.  

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 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.

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.