I think we are in agreement.
Martin W Sachs wrote:
>
> Chris,
>
> The main point is that you agree with my (3). However I do want to ask
> what you mean by "Couldn't the CPA provide those parameters to the runtime?
> ". What I meant by "message by message" was that the same message defined
> in the same business transaction might have different security parameters
> each time it is issued. The CPA can't help with that. Apparently what you
> meant by "per message" was "per message definition", which is satisfied by
> my (3).
>
> 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
> *************************************************************************************
>
> christopher ferris <>@Sun.COM on 06/13/2001
> 03:06:43 PM
>
> Sent by:
>
> To: Martin W Sachs/Watson/IBM@IBMUS, Christopher Ferris
> <>
> cc:
> Subject: Re: nonrepudiation (signing messages)
>
> Marty,
>
> Please see below.
>
> Cheers,
>
> Chris
>
> Martin W Sachs wrote:
> >
> > OK, avoiding mentioning specific elements in the existing CPA, I can
> think
> > of only three levels of granularity that are relevant to the CPA.
> >
> > Entire CPA
> > Per delivery channel
> > Per business transaction.
>
> Agreed.
>
> >
> > The above are covered by the existing DeliveryChannel, ServiceBinding,
> and
> > Override elements.
>
> Right.
>
> >
> > The next finer granularity is per message. I don't know how to express
> > that in the CPA. That would be up to the sending software or middleware
> to
> > provide the security parameters to the Message Service on a message by
> > message basis.
>
> Couldn't the CPA provide those parameters to the runtime?
>
> >
> > Another possibility, which is really at the same level of granularity as
> > (3) is to express message security separately from the delivery channel
> so
> > that we wouldn't have to define multiple delivery channels just to vary
> the
>
> Right, that was my thinking. It would also provide a link for the
> packaging and possibly the definition (ala WSDL).
>
> > message security. That MessageSecurity element would have to cover all
> > three levels of granularity listed above. For (2), the delivery channel
> > could point to it with an IDREF as it does for certificate. For (3), the
> > message security element would have to point to the Proc Spec document
> and
> > business transaction within it.
>
> Sounds reasonable.
>
> >
> > Regards,
> >
> > Marty
> >
> > 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
> >
> *************************************************************************************
>
> >
> > christopher ferris <>@Sun.COM on 06/13/2001
> > 01:41:27 PM
> >
> > Sent by:
> >
> > To: Martin W Sachs/Watson/IBM@IBMUS
> > cc: Himagiri Mukkamala <>,
> > ,
> > Subject: Re: nonrepudiation (signing messages)
> >
> > Correct, however, what I am suggesting is that maybe the
> > DocExchange binding is the wrong level of granularity
> > for this sort of thing.
> >
> > Cheers,
> >
> > Chris
> >
> > Martin W Sachs wrote:
> > >
> > > Yes, if Chris meant "per message definition", then the override element
> > > provides the "per message definition" binding.
> > >
> > > 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
> > >
> >
> *************************************************************************************
>
> >
> > >
> > > Himagiri Mukkamala <> on 06/13/2001 01:15:26 PM
> > >
> > > To: Christopher Ferris <>
> > > cc: Himagiri Mukkamala <>, Martin W
> > > Sachs/Watson/IBM@IBMUS, ,
> > >
> > > Subject: Re: nonrepudiation (signing messages)
> > >
> > > I could be wrong, but is'nt this already supported
> > > by the ability of CPA to specify an overriding
> > > "DeliveryChannel" for an "Action".
> > >
> > > This would allow different messages
> > > to be sent with different actions if they need
> > > different "Signature" parameters.
> > >
> > > -hima
> > >
> > > Christopher Ferris wrote:
> > >
> > > > Hima,
> > > > This is true, which suggests that a specific binding
> > > > on a per-message basis may be what is needed, not just
> > > > a per-channel basis as currently provided.
> > > >
> > > > >
> > > > > -hima
> > > > >
> > > > > christopher ferris wrote:
> > > > >
> > > > > > Marty,
> > > > > >
> > > > > > My take on this is that this element could take the form
> > > > > > of a Signature "template" which effectively provided
> > > > > > all of the requisite binding information including
> > > > > > reference URI(s) with only the Digest and actual
> > > > > > signature omitted. The IBM Alphaworks XSS4J DSig
> > > > > > implementation provides for use of a template
> > > > > > to drive the signing behavior, which is a nice
> > > > > > feature of the tool (IMHO).
> > > > > >
> > > > > > I have successfully used the SignatureAlgorithm, HashFunction
> > > > > > and Protocol. I haven't used Certificate yet mostly
> > > > > > for implementation reasons.
> > > > > >
> > > > > > Presently, the ebXML MS specification prescribes the
> > > > > > Transform algorithm(s) that MUST be used, as well as
> > > > > > the Reference URIs necessary for the header, but not the
> > > > > > payload item(s) since that would depend upon the Content-ID
> > > > > > or Content-Location URI which might vary from message to
> > > > > > message even of the same type. Thus, presently this is
> > > > > > not an issue. However, to make this more flexible, it might
> > > > > > be useful to have the ability to fully describe the Transform
> > > > > > as well.
> > > > > >
> > > > > > Another approach would be to leverage the Reference element
> > > > > > from the DSig specification, omitting the DigestValue (like the
> > > > > > Signature "template" but without describing the full Signature.
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Chris
> > > > > >
> > > > > > Martin W Sachs wrote:
> > > > > > >
> > > > > > > The NonRepudiation element specifies signing of the messages
> > using
> > > XMLDSIG.
> > > > > > > Its child elements are Protocol, HashFunction,
> > SignatureAlgorithm,
> > > and
> > > > > > > Certificate. I have recently been asked whether NonRepudiation
> > > also has to
> > > > > > > have a Transform(s) element. If XMLDSIG provides a choice of
> > > Transform,
> > > > > > > then the choice should probably be expressed under
> > NonRepudiation.
> > > > > > > Alternatively, we might prescribe a particular answer in the
> text
> > > and not
> > > > > > > need an element.
> > > > > > >
> > > > > > > If something about transforms is needed in the specification,
> > let's
> > > put it
> > > > > > > on the list for the maintenance release.
> > > > > > >
> > > > > > > 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
> > > > > > >
> > >
> >
> *************************************************************************************
