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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: BPSS issue 57 proposed resolution


1.   The separate signal "isConfidential" requires encryption.  We do not
otherwise permit this requirement, so it should be supported.  Note also
that this would meet the business need for an opaque document transmitted
past a nonauthorized third party - without use of a separate 'envelope".
We should also note nonnormatively that the parties must pass the key in
some manner (probably through the CPA) or this becomes useless.   Do we
need a field for this, or just a textual warning? 
2.   The separate signal "isTamperProof" requires XML-DSIG over encryption.
 We do not otherwise permit this requirement, so it should be supported.
Note that this would duplicate - harmlessly - a signature requirement
generated by a "nonrepudiation of receipt" parameter.   (Same comment about
keys, also.)
3.   The separate signal "isAuthenticated" requires XML-DSIG with a
certificate.  The nature of the certificate is not well specified.  Note
also that no other parameter permits a BP specification to impose (on the
responder's behalf) a signature requirement on the initiating document.  It
should be supported.  Also, we should consider specifying use of XML-DSIG.
  Note that this would duplicate - harmlessly - a signature requirement
generated by a "nonrepudiation of receipt" parameter.   
4.    The signal "isSecureTransportRequired" appears to be a declarative
statement that composites several security parameters, and ALSO includes a
perhaps-unenforceable directio to use a specific messaging channel (e.g., a
VPN or designated forwarder).  This should be unbundled into the above
three specific signals.  
5.    The signal "isGuaranteedDeliveryRequired" appears to be a
perhaps-unenforceable direction to use a specific messaging channel (e.g.,
a VPN or designated forwarder) with certain features.  This should be
converted into a specification of a NAMED delivery channel, and should be
associated only with objects at a level that allow its determinative
resolution in the applicable CPA.

JBC 


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC