W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2002

RE: D-AG006 Security

From: Krishna Sankar <ksankar@cisco.com>
Date: Tue, 12 Mar 2002 18:06:43 -0800
To: <www-ws-arch@w3.org>
Message-ID: <000001c1ca33$ba27adf0$5ca7153f@amer.cisco.com>
Joseph,

	QoS is not a measurement, SLA is. QoS is architectural, SLA is
operational.

	QoS also can include reliable messaging dimensions. By the by
everything is measured - either in a binary scale (yes or no) or analog
scale (0-100 et al)

	QoS is not included in security because it is a separate
functionality.

cheers
	

 | -----Original Message-----
 | From: www-ws-arch-request@w3.org 
 | [mailto:www-ws-arch-request@w3.org] On Behalf Of Joseph Hui
 | Sent: Tuesday, March 12, 2002 5:07 PM
 | To: Anne Thomas Manes; Krishna Sankar; www-ws-arch@w3.org
 | Subject: RE: D-AG006 Security
 | 
 | 
 | > From: Anne Thomas Manes [mailto:anne@manes.net]
 | [snip]
 | > Perhaps we should define a requirement to specify quality of 
 | > service, which
 | > would include security, transactions, reliability, etc.
 | 
 | QoS is a measurement.  
 | It's not an architectural function, thus security 
 | can't be a part of it.  The two are apple and orange IMHO.
 | QoS is meaningful only (mostly?) in cases where success can
 | be measured in a range of values, say 1 to 100. Say, if your
 | SLA guarantees 99.999% uptime, then you get some rebate
 | from your service provider for services below par.  
 | In security, it's either 0 (for failure, any failure)
 | or 100 for success; but one can hardly claim 100 due to a
 | negative-deliverable argument, which says: "security is a
 | negative deliverable."  (I've borrowed the term "negative
 | deliverable" from Jeff Schiller, a Security Area Director
 | in IETF, who once said (and I paraphrase here): "In security,
 | you work towards a negative deliverable -- you don't know
 | if you have it (i.e. security achieved) until you know
 | you don't!")
 | 
 | Joe Hui
 | Exodus, a Cable & Wireless service
 | ===================================================
 | 
 | > 
 | > Although BTP, ebXML MS, SAML, and other technologies address 
 | > these areas,
 | > they don't specify how a SOAP message should relay this 
 | > information (well,
 | > ebXML does -- but most of the SOAP community doesn't pay 
 | much heed to
 | > ebXML). If we're to enable interoperability, at some point 
 | > we'll need to
 | > form groups to define SOAP extenstions that specify how to 
 | > represent this
 | > information/context in SOAP headers.
 | > 
 | > Anne
 | > 
 | > > -----Original Message-----
 | > > From: www-ws-arch-request@w3.org 
 | > [mailto:www-ws-arch-request@w3.org]On
 | > > Behalf Of Krishna Sankar
 | > > Sent: Tuesday, March 12, 2002 6:01 PM
 | > > To: www-ws-arch@w3.org
 | > > Subject: RE: D-AG006 Security
 | > >
 | > >
 | > > Hi all,
 | > >
 | > > 	Couple of points :
 | > >
 | > > 	1.	Message delivery semantics - Once and Once only or at
 | > > most once or best effort - are not under security per se. 
 | > They can be a
 | > > consideration in some other "bucket"
 | > >
 | > > 	2.	Same goes with transactions - in the strict traditional
 | > > sense (distributed transaction with roll back/commit 
 | > capability) or the
 | > > new paradigm (a la BTP) with compensating trx et al.
 | > >
 | > > 	I think in both cases, the architecture can specify placeholders
 | > > for a web service to specify all these attributes. May be 
 | > we could refer
 | > > to the appropriate disciplines/initiatives to define the actual
 | > > semantics - BTP (for distributed trx), ebXML (for Reliable 
 | > messaging) et
 | > > al.
 | > >
 | > > 	Secure messaging would be under security.
 | > >
 | > > cheers
 | > >
 | > >  | -----Original Message-----
 | > >  | From: www-ws-arch-request@w3.org
 | > >  | [mailto:www-ws-arch-request@w3.org] On Behalf Of Cutler,
 | > >  | Roger (RogerCutler)
 | > >  | Sent: Tuesday, March 12, 2002 2:28 PM
 | > >  | To: 'Joseph Hui'; Cutler, Roger (RogerCutler); Krishna
 | > >  | Sankar; www-ws-arch@w3.org
 | > >  | Subject: RE: D-AG006 Security
 | > >  |
 | > >  |
 | > >  | I'm not quite sure what you mean by "transaction
 | > >  | processing". I have heard
 | > >  | the term used in more than one way.  Is the concern
 | > >  | essentially to have a
 | > >  | mechanism for handling stateful transactions -- for example,
 | > >  | to carry state
 | > >  | information in the messages?  Or are you talking about the
 | > >  | idea of "rolling
 | > >  | back" a transaction if it fails -- or possibly of initiating
 | > >  | compensating
 | > >  | transactions?
 | > >  |
 | > >  | -----Original Message-----
 | > >  | From: Joseph Hui [mailto:jhui@digisle.net]
 | > >  | Sent: Tuesday, March 12, 2002 4:14 PM
 | > >  | To: Cutler, Roger (RogerCutler); Krishna Sankar; 
 | > www-ws-arch@w3.org
 | > >  | Subject: RE: D-AG006 Security
 | > >  |
 | > >  |
 | > >  | > -----Original Message-----
 | > >  | [snip]
 | > >  | > Could we possibly consider putting reliable messaging into
 | > >  | > the security bucket?
 | > >  |
 | > >  | I don't think so.  There's no security primitives that
 | > >  | would fit the bill of reliable messaging (RM), which 
 | I sometimes
 | > >  | characterize as "layer-7 TCP" where a session between two
 | > >  | endpoints may span
 | > >  | over several time-serialized connections, disconnections,
 | > >  | reconnections.
 | > >  | AG006 may include securing RM, but not RM per se.
 | > >  |
 | > >  | While at it, let me mention that if you want to include
 | > >  | RM in WS-Arch, then you may as well not leave out
 | > >  | transaction processing.
 | > >  |
 | > >  | [snip]
 | > >  | > it is a natural
 | > >  | > progression of thought:  "I'm worried about who the 
 | author of
 | > >  | > the message
 | > >  | > is, whether it is distorted, and that IT ACTUALLY 
 | GETS THERE".
 | > >  |
 | > >  | ^^^^^^^^^^^^^^^^^^^^^^ There no
 | > >  | security primitives that can guarantee data arrival.
 | > >  |
 | > >  | Joe Hui
 | > >  | Exodus, a Cable & Wireless service
 | > >  |
 | > >  |
 | > >  |
 | > >
 | > 
 | > 
 | 
 | 
Received on Tuesday, 12 March 2002 21:07:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:24:56 GMT