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] March 15, 11 EST, OASIS ebXML-CPPA teleconference



Thanks to David Fischer, Rik Drummond and the Drummond Group
for hosting the March CPPA teleconference calls.

Number:  1-800-503-2899
Code:      2947339

Agenda: 

Announcements and Additional Agenda Items.

Residual Disputed Issues 

Issue 194: (Discussion for up to
20 minutes, ending in proposed action!)

Subissue A: "...perisisted locally in an encrypted form.."

On A: Chris Ferris, Pete Wenzel and others have objected
  to having anything about specifying that there should
  be middleware programmatic behavior that specifies, even
  vaguely, that encrypted data is stored when the 
  "isConfidential" attribute is used with a value of 
  "persistent" or "transient". Should we drop this?
   If so, will dropping this conflict with BPSS semantics?
   If so, should we provide a footnote to the BPSS 
   requirement to replace this language? do nothing?
   If no conflict, why retain it? If we do not drop,
   how shall the disputed nature of this requirement
   be indicated?

Subissue B: "made available to the application 
in accordance with local security policies 
implemented to preserve confidentiality." 

On B:  This somewhat vacuous comment imposes little except
that there exists some local security policy that is
implemented to preserve confidentiality. 

  Does anyone think that we have an obligation to say
  what policies should exist, and something normative
  about their implementation? Required for interoperability?
  Required for shared understanding of what "isConfidential"
  being checked means? Is this a rathole trying to define
  security implementation details of the interface of middleware
  with applications? 

Potential Issue ???:  ApplicationCertificateRef clarifications. More
than
  one needed? What if both signing and encrypting operations
  done so that separate application certificates are needed?
  (Example of how this happens.) Move ApplicationCertificateRef
   under ActionBinding? Change cardinality of element? 

Potential Issue ???:  Clarification of NamespaceSupported element usage.
   Under Packaging and Under DocExchange. BPSS also will mention
   Namespaces. 

Next Business:

[ I hope to have a list of issues by number that still may need
discussion before the call. My issues database is not up to date.]

We need to plan to review the "2.0" issues, see that we have them
covered, and report on their resolution to the TC
to prepare for the TC 2nd half of March review (which should start 
after this meeting!)

Any inputs or suggestions about process and procedures that we should
follow (besides the Oasis ones) as we move forward toward a TC
vote on approval?


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


Powered by eList eXpress LLC