[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] March 15, 11 EST, OASIS ebXML-CPPA teleconference
Regarding issue 194, it seems to me that the requirement is to be able override the isConfidential attribute in the BPSS instance document. The only issue is how to describe what it is and what its values are. We should say (or summarize) whatever the BPSS specification says. If the BPSS specification remains unsettled, we could simply list the enumeration and put in a reference to the BPSS specification for explanations. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* Dale Moberg <dmoberg@cycloneco To: "Cppa (E-mail)" <ebxml-cppa@lists.oasis-open.org> mmerce.com> cc: Subject: [ebxml-cppa] March 15, 11 EST, OASIS ebXML-CPPA teleconference 03/14/2002 03:59 PM 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? ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC