RE: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases e-Bus ines s Architecture Technical Specification for Public Review])

Just a bit of corrected information here before objections wander off
into the wilderness.

I do not recall Duane's use case for CPAId being discussed within the
CPPA group. Not the reason for these techniques being developed at all,
IMO.

CPAId, along with other metadata in the SOAP ebXML header, could be 
used in looking up the "service" agreements governing collaborations of
participants. This can be done when generating, checking, or processing
the message.

The use of the term "pre-negotiated" is also misleading and contentious
(David).
 
There are ways of using CPAs that involve no negotiation.
CPA templates could present little more restriction on "dynamic" 
collaboration than do URLs (which, as is the case with wsdls, they can
supply).

However, it would be silly to use CPAs if all you needed was a URL--too 
complicated. Same for wsdls. But there are more complicated feature
sets, and more demanding integration and automation requirements, for 
which the information in wsdls or in CPAs can be useful. (CPA
information is like the information provided within the wsdl:binding
elements, not the wsdl:porttype element.)

The CPPA documents are geared for b2b collaborations
involving "Features" such as data confidentiality, digital signatures, 
reliable messaging, and so on. Negotiation services (web services, with
WSDLs) are currently being written for negotiating CPAs in a
semi-automated way. (Because changes in, e.g., trust anchors can be
involved, there is some residual need in many cases to kick approval up
to a human, hence the "semi-")

One reason actually provided for discussing CPAs instead of putting 
all the CPA information in various SOAP headers in every message was
simply to avoid the repetition of the same unchanging configuration
information in each of the messages. A retailer replenishing stocks from
its manufacturer in effect sets up a "delivery channel" for message
traffic whose security, reliability and other Features do not change
over a scale of months, even years. When this aspect of collaboration
dominates, interest in "dynamic" contextless access drops off
considerably. Interest in predictability, monitorability, and simplicity
of lifecycle management of collaboration configuration information go
way up. 


-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Thursday, February 13, 2003 7:44 PM
To: Duane Nickull
Cc: Burdett, David; www-ws-arch@w3.org
Subject: RE: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases
e-Bus ines s Architecture Technical Specification for Public Review])





> -----Original Message-----
> From: Duane Nickull [mailto:duane@xmlglobal.com]
> Sent: Thursday, February 13, 2003 8:51 AM
> To: Assaf Arkin
> Cc: Burdett, David; www-ws-arch@w3.org
> Subject: Re: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases
> e-Bus ines s Architecture Technical Specification for Public Review])
>
>
>
>
> Assaf Arkin wrote:
> > For example, you can have a service level agreement that need to be
> > pre-negotiated and all messages have to carry the SLA number to be 
> > processed and the SLA can be started and managed by some WSDL
> operation.
> > There is no need to negotiate messaging-level agreement, and the
> > negotiation of another agreement could be in itself a service.
> >>>>>>>>>>>
>
> I thought of that in ebXML as well, however I personally pushed for
> the CPA to be required and processed in the outermost envelope.  This 
> was an architectural decision based on the rising popularity of DOS 
> attacks (denial of service).  It is foreseeable that someone could 
> pump in 1000's of bogus messages if they wanted to tie up a specific 
> BSI (Business Service Interface).  The TA team was constrained by 
> making sure we thought of hacker attacks, no single point of failure 
> etc..
>
> By parsing and comparing the CPA ID in the outermost envelope at the
> messaging layer (probably by slurping the first 500 bytes via SAX),  
> it requires far less processor resources than to open the envelope 
> first, then route the message payload to another resource before 
> trying to validate the service level agreement.

Security by obscurity ;-)

If the message is not encrypted it's easy for an attacker to obtain a
CPA ID and use that for a DoS. If the message is encrypted then the
signature is used to filter bogus messages from real messages.
Signatures is the only solution I am aware of for the generals problem
which is basically this form of attack (attacker masquarading as
sender).

I assume we all agree WS-Security provides a better framework for
identifying the sender and determining whether or not to accept a
message from that sender in a manner that is truely secure and with
multiple mechanisms.

I basically think it's wrong for a specification to try and solve
problems that are outside it's jurisdiction. On the other hand, it
should use an open framework to allow such solutions to be used in
combination. So one of the value statements of WSDL is that it allows
such specifications to exist. You can always create a better security
specification and use it to reference WSDL operations to which the
security policy applies. (And a million other things, like transactions,
business commitements, billing, analytics, etc).

arkin

>
> For right or wrong,  that was the thinking.
>
> Duane
>
>
>
> --
> VP Strategic Relations,
> Technologies Evangelist
> XML Global Technologies
> ****************************
> ebXML software downloads - http://www.xmlglobal.com/prod/

Received on Thursday, 13 February 2003 22:55:54 UTC