" rel="home">

ebXML CPPA Technical Committee Teleconference
(Non Voting)
March 1, 2002

Attendees

Arvola Chan
Brian Hayes
Dale Moberg
David Fischer
Himagiri Mukkamala
Marty Sachs
Peter Ogden
Tony Weida

Minutes

Dale mentioned the ambiguity matter involving wildcards that Arvola raised:

http://lists.oasis-open.org/archives/ebxml-cppa/200202/msg00137.html

Dale thought the proposed solution of putting a wrapper in target namespace should work. We agreed that the wrapper can occur 0 or 1 time and can have one to three XML DSIG signatures. Marty suggested a non-normative note explaining why the wrapper is there; Arvola agreed to write it.

We then reviewed items from Dale's agenda, indicated below in boldface:

1. Can section 8.2 on SchemaLocation attribute be eliminated?

Arvola said we've selected a namespace URI that directly resolves to the schema (refers to an XSD), so technically it's not necessary to specify a SchemaLocation. We'll keep the attribute and remove the redundant discussion of Section 8.2.

2. Under the PartyInfo element, do we need to include a packageId attribute to identify the packaging to be used for non piggybacked MSH level messages?

Without opposition, we agreed to add the packageId attribute and that it be REQUIRED.

3. Do we need to beef up the discussions on ApplicationCertificateRef and ApplicationSecurityDetailsRef?

Peter indicated that the sections were intended to indicate that these are part of the CPP so they can be negotiated, but it was beyond the scope of this specification to go into what they might be used for. Arvola thought that Dale's composition appendix makes specific assumptions about the use of these certificates. He also questioned whether the ApplicationCertificateRef is used for encryption and signing, or just for signing. Peter asked whether that would imply multiple such elements. Peter suggested that we're allowing people in the financial services community, for example, to use their existing mechanisms. He thought that this certificate is not for BPSS signals, but for lower level signals and Arvola agreed that he'd made the same assumption. We'll take this question to the list.

Pallavi's reports on BPSS-related issues to be discussed as needed:

4.Arvola, I just wanted to clarify that timetoPerform in BPSS is present for both BinaryCollaboration and BusinessTransactionActivity. -Pallavi

5.Issue 148:
The CPPA team can close the issue.
They should pick a reasonable URN for their example. Brian

Such an example has been included in the draft. Tony will close the issue.

6. Issue 87 BPSS team have agreed to add Business Level Retries to the BPSS (retrycount added to RequestingBusinessActivity - Aligns with UMM). The message id be different when a retried from business process level and the receiving application will be responsible for detecting for business level duplicates using the unique id((like a purchase order number) ) in the business information.-Pallavi

Arvola asked whether we need a corresponding parameter in our BusinessTransactionCharacteristics element, and pointed out that we don't know exactly what it'll be called in BPSS. Brian thought the BPSS team had agreed to stay with "retry" and document it heavily. We'll leave the question open pending discussion with Pallavi to determine an attribute name that won't confuse implementers.

Hima noted that BusinessTransactionCharacteristics is now under DeliveryChannel, but once we start adding things like application level retries, it doesn't fit there. Marty thought DeliveryChannel should be reserved for MSH-related things. There was some consensus that BusinessTransactionCharacteristics belongs under ActionBinding. Tony will add an issue.

Discussion deferred from last week: Continues.

7. Issue 194
Interpretation of confidentiality attribute in DeliveryChannel

"It MUST be encrypted above the level of the transport and delivered, encrypted, to the application."

Too strong or just right?

Tony thought the mechanism is roughly in place in the current specification, but the spec doesn't specifically say what's meant by persistent confidentiality, and similarly for other attributes with transient and persistent variants. The spec only uses examples of suitable technology, in this case, SSL and S/MIME. Arvola asked if we could just say "persisted in encrypted form" and Tony agreed. In the case of persistent encryption, Tony felt that the application should determine when decryption takes place, regardless of whether MSH functionality is invoked to do the actual decryption. Hima agreed. We discussed ambiguities around the notion of delivery to the "application." Dale was inclined to soften the text by speaking of secure rather than encrypted. Tony suggested looking to BPSS for their definition of persistent confidentiality; Arvola suggested looking at the messaging spec as well. According to Brian, BPSS says that for persistent confidentiality "the receiver shall maintain a copy of the encrypted item" and for transient confidentiality it indicates "transport level encryption". In contrast, Peter quoted MSH as saying "it is not the responsibility of the MSH to provide security for ebXML payloads." He thinks we need two confidentiality parameters. Due to lack of time, further discussion was deferred.

Next Meeting

There will be another teleconference next week on March 8.

Metadata

Please send additions and corrections to Tony Weida (rweida@hotmail.com).

Respectfully submitted,
Tony Weida