RE: [ebxml-msg] Schema problem with encryption in the AS4 draft

[Moberg Dale <dmoberg@axway.com>]

Additional factors to ponder:

In XML Schema 1.1 an element can have multiple attributes of type ID
http://www.w3.org/TR/xmlschema11-1/

Schema 1.1 is backwards compatible with 1.0 in that it supposedly won't invalidate any valid 1.0 documents (but apparently will validate some 1.0-invalid documents)

In SOAP 1.2, 

"SOAP does not require that XML Schema processing (assessment or validation) be performed to establish the correctness or 'schema implied' values of element and attribute information items defined by Parts 1 and 2 of this specification.

Combine these with,

wsu:id usage is a "should" in WS-I (Pim)

encryption of headers is not a requirement of AS4 (Pim)

encryption of some headers would cause problems for part 2

All together it is worth considering issuing a clarification (or erratum?) cautioning users about the raised issue for schema 1.0 validation. But other possibilities for action should also be considered.

I think we should try to gather up all the relevant considerations, and then consider what action seems most useful.

Thanks to Theo for raising this point before the conformance documents are approved. We might also consider including the appropriate cautions in the conformance profiles (AS4 and the generic ones). 


-----Original Message-----
From: Theo Kramer [mailto:theo@flame.co.za] 
Sent: Tuesday, May 17, 2011 5:57 AM
To: Pim van der Eijk
Cc: ebxml-msg@lists.oasis-open.org; Mike O Connell
Subject: Re: [ebxml-msg] Schema problem with encryption in the AS4 draft

Hi Pim

Thanks for the comments. Our responses inline

On 17 May 2011, at 1:42 PM, Pim van der Eijk wrote:

> 
> Hello Theo,
> 
> Two comments:
> 
> 1)  I think we should simplify this and say that the
> eb:Messaging header should never be encrypted.  A capability
> to selectively encrypt parts of a message header seems
> neither simple to implement nor something that would rank
> highly (if at all) on a list of required features for the
> market we want to address with AS4.  
> 
> If confidentiality is important peer-to-peer (no
> intermediaries), transport security could and usually is
> used.
> If confidentiality is important end-to-end (across
> intermediaries), then simple guidelines (e.g. don't use the
> credit card number of your customer as the ConversationId of
> a message) and proper access controls, audits etc. of the
> intermediaries in practice cover virtually all remaining
> cases.

Does this not have repercussions for ebMS 3 ?

> 2)  The eb:Messaging element already has an optional "id"
> attribute of type xsd:ID.  At least one XML schema engine
> does not allow a wsu:Id to be added to eb:Messaging even if
> that "id" attribute is not present:
> 
> cvc-complex-type.5.2: In element 'eb3:Messaging', attribute
> 'Id' is a Wild ID. But there is already an attribute 'id'
> derived from ID among the {attribute uses}.  
> 
> Now the WS-I BSP says to use "wsu:Id" preferentially
> (SHOULD), this still allows the use of the "id" attribute.
> So my assumption was that the header should be identified
> using the "id" attribute to make sure the header is schema
> valid.  Does your WS-Security processor support this?  The
> SOAP Body element would be identified using a wsu:Id.

The WS-Security processor (wss4j) we are using is namespace specific and, to our knowledge this can not be adjusted. Ie. an "id" under one namespace could be different to another namespace "id".

> I agree we want to allow schema validation for the full SOAP
> header. 

<snip>
-- 
Regards
Theo


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php