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
Arvola recalled an agreement at the F2F not to have any
mechanism to override a BinaryCollaboration's timeToPerform,
since we don't have a good place to put such a parameter
- so far, everything from BPSS that we override is at
the BusinessTransaction level. Arvola will prepare some
text to clarify this point.
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
|