OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]