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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: [ebxml-cppa] Analysis of issues assigned to me: 5, 123, 146


Issue ID 5 (Packaging)
======================

The current spec and schema allow for individual message parts to be
excluded from being referenced by the signature generated by the MSH. (By
default, all message parts will be included in the signature.) At the same
time, encryption and/or signature transforms to be applied to individual
message parts can also be specified. It is not clear to me if the transform
information is intended for use by the MSH or by the application, or both.

Now that XML Encryption is a W3C Candidate Recommendation, is it permissible
for a conforming ebMS implementation to support XML Encryption at the MSH
level? Do we need more fine grained control on what is encrypted? How can we
specify that certain elements within a message part has to be encrypted, as
opposed to encryption of the entire message part?

We have two sets of certificates that can be used for encryption and/or
signing, depending on whether that is done at the MSH level or at the
application level, but we don't seem to have a way to state that XML
Encryption is to be performed at which level.

Issue ID 123 (Indicate use of basic authentication)
===================================================

We now can have one or more AccessAuthentication element under
TransportSender and TransportReceiver. However, the spec does not say
anything about the fact that user name and password information needed to
implement basic authentication must be exchanged through some other
out-of-band mechanism.

Issue ID 146 (Format of URI PartyID reference)
==============================================

We need to decide if PartyId/@type must be of type anyURI or if it can
simply be a non-empty-string. Personally, I am in favor of requiring it be
of type anyURI. We probably should take up the offer from William Kammerer
to write up a separate document to describe the
oasis:names:tc:ebxml-cppa:partyid-type URN, and the offer from Duane Nickull
to have that work done under the auspices of the UN/CEFACT architecture
specification.

-Arvola



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


Powered by eList eXpress LLC