XMLP/XMLE Use cases and processing models

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 00:07:32 UTC