- From: David Orchard <david.orchard@bea.com>
- Date: Wed, 6 Feb 2002 00:07:34 -0500 (EST)
- To: "'xenc'" <xml-encryption@w3.org>, <www-xenc-xmlp-tf@w3.org>, <xml-dist-app@w3.org>
This message represent Dave Orchard's comments on XMLE, as requested of the XMLP working group. I had suggested that more use cases and scenarios should be described to explain the processing model(s) for XMLE. I have created 2 use cases, a decrypting intermediary and a decryping ultimate recipient. In XMLE Section 2.1, there is an example with a credit card element, and there are examples of various encryption forms. I will take the first of the examples, specifically 2.1.1, and use it in the use cases, as well as exploring a processing model. Use case #1: SOAP decrypting intermediary ---------------- Let us assume that a soap intermediary is decrypting the credit card. The receiver exposes a contract, say WSDL, that says it accepts a credit card. An intermediary is introduced that decrypts the credit card. The accepts encrypted credit card intermediary is then exposed in addition to the intended receiver. The steps that the soap decrypting node might go through - assuming that every step passes validation - are: 1. Receive the message. 2. Validate the message with the encrypted content. 3. Decrypt the encrypted content. 4. Forward the message to the ultimate receiver. The the ultimate receiver would: 1. Validate the message with the decrypted content against the schema without encryption 2. Pass the message to the application software. Use case #2: SOAP decrypting in one node ------------------ Similar model to #1, except the intermediary is collapsed and one node does the validation. 1. Receive the message. 2. Validate the message with the encrypted content. 3. Decrypt the encrypted content. 4. Validate the message with the decrypted content against the schema without encryption 5. Pass the message to the application software. Questions ---------- 1. I have anticipated that the intermediary has to know about the receiver schema and must expose the "merged" schema or a schema without the unencrypted credit card info to senders. There is tight coupling there, but how else would the intermediary know which messages and which portions to decrypt? Is this valid or does XMLE expect that a SOAP encrypting/decrypting intermediary would not know about the receiver schemas nor would it expose a "merged" schema? This assumes the first or second solution in the processing requirements (3.2.2) [1]. 2. Should the encrypted message use the same namespace name as the unencrypted message IF the schema does not allow the encrypted content? I tend to think no, as URIs in namespace names tend to include versions and be very specific. That means that there should be different namespace names for the encrypted versus unencrypted content. In the processing requirements, 3.2.1, there is no mention of whether preserving the original definitions namespace name should or should not be done. 3. Does XML Schema and the PSVI deal with use case #2, where there are 2 runs of schema validation? On XInclude, XML Schema gave extensive comments on infoset "fixups" that had to occur after inclusion. I've tried to think of a number of problem areas but I'm not a schema expert so I'm sure there are others. It seems to me that the decrypting software MUST ensure that the infoset is completely fixed up and de, ie namespace names, base URIs, PSVI infoset additions like type. Specifically, what infoset fixups should an XMLE processor do to enable with single node processing and multiple schema validation steps? An example is removing all the type information. 4. Given the first solution in the processing requirements 3.2.2, a problem emerges. The first recipient REQUIRES the encryption to be in force, and that the second recipient REQUIRES the credit card. Yet the schema allows both. Could the XMLE give guidance on when to use the first solution versus the second solution (separate schemas)? Maybe this is one area where an XMLP/XMLE liaison could give guidance, ie "when using intermediaries and multiple validation phases, provide 2 separate schemas" I wish to make clear that I have tried desparately to avoid the intermediaries discussions. I have also avoided WSDL issues. I couldn't avoid the namespace and schema issues ;-) Elaboration of examples -------------- I decided to create the merged and unmerged xml documents and schema documents to illustrate some of the issues. I did have to perform some changes to the examples and xmle schema to get them to work in my tools. 1. Construct a Schema for the Payment Info. I have created one, shown below. <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://examples.org/Payment" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://examples.org/Payment" elementFormDefault="qualified" attributeFormDefault="unqualified"> <element name="PaymentInfo" type="tns:PaymentInfoType"/> <complexType name="PaymentInfoType"> <sequence> <element name="Name" type="string"/> <element name="CreditCard" type="tns:CreditCardType"/> </sequence> </complexType> <complexType name="CreditCardType"> <sequence> <element name="Number" type="string"/> <element name="Issuer" type="string"/> <element name="Expiration" type="string"/> </sequence> <attribute name="Limit" type="string"/> <attribute name="Currency" type="string"/> </complexType> </schema> 2. Adjust Example to validate. In my example, I have created a schemaLocation attribute. With SOAP, this is not required. Indeed, SOAP messages will have their interface defined, probably by WSD ?.?. The use of schemaLocation for a WSD entry is syntactic sugar for specifying a schema to be validated by a tool. 2.1 - the Name/ should be /Name. A validatable example is shown below. <?xml version="1.0"?> <PaymentInfo xmlns="http://examples.org/Payment" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://examples.org/Payment D:\AllMaterial\BEA\XMLEScenario\Paymentv2.xsd"> <Name>John Smith</Name> <CreditCard Limit="5,000" Currency="USD"> <Number>4019 2445 0277 5567</Number> <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo> 3. Construct Schema for the encrypted Payment Info, example 2.1.1. The reason is that the example is now no longer valid against the PaymentInfo Schema. This is the critical point, that the first schema may have to "know" about the encryption schemas in order for validation to correctly work. Currently, the XMLE examples "mixes-in" the type at the element instance. But that means a WSDL or XML Schema that is expecting a PaymentInfo will NOT validate. This is the first solution as per XMLE requirements section 3.2.2 3.1 Fix Schema for XMLE 3.1.1 change KeySizeType to string - a hack because KeySizeType isn't in xmle schema 3.1.2 change OAEPparamsType to string - a hack because OAEParamsType isn't in xmle schema 3.1.3 change Encrypted type ref to properties to minOccurs=0, ie <element ref="xenc:EncryptionProperties" minOccurs="0"/> The schema is shown below: <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://examples.org/Payment" xmlns:tns="http://examples.org/Payment" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <import namespace="http://www.w3.org/2001/04/xmlenc#" schemaLocation="D:\AllMaterial\BEA\XMLEScenario\xenc-schema.xsd"/> <element name="PaymentInfo" type="tns:PaymentInfoType"/> <complexType name="PaymentInfoType"> <sequence> <element name="Name" type="string"/> <choice> <element name="CreditCard" type="tns:CreditCardType"/> <element ref="enc:EncryptedData"/> </choice> </sequence> </complexType> <complexType name="CreditCardType"> <sequence> <element name="Number" type="string"/> <element name="Issuer" type="string"/> <element name="Expiration" type="string"/> </sequence> <attribute name="Limit" type="string"/> <attribute name="Currency" type="string"/> </complexType> </schema> 4. Adjust the encrypted example to have schemaLocation attribute, xml is shown below: <?xml version="1.0"?> <PaymentInfo xmlns="http://examples.org/Payment" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://examples.org/Payment D:\AllMaterial\BEA\XMLEScenario\Paymentv2EncryptedData.xsd"> <Name>John Smith</Name> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#' xsi:schemaLocation="D:\AllMaterial\BEA\XMLEScenario\xenc-schema.xsd"> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </PaymentInfo> Other samples ------------- I took a look through WS-Security, OASIS SAML, and SOAP-sec to find encryption and headers. There is little use of XMLE, not suprisingly. But I found that the model occurs in WS-Security, where a wsse:confidentiality element contains encrypted content, and thus is not valid according to the confidentiality schema. This relates to question #2. Cheers, Dave Orchard [1] http://www.w3.org/TR/2001/WD-xml-encryption-req-20010420#sec-Processing
Received on Wednesday, 6 February 2002 08:54:54 UTC