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

[W3-WSAWG] WS-Arch Requirements

From: Joseph Hui <jhui@digisle.net>
Date: Tue, 5 Mar 2002 11:06:22 -0800
Message-ID: <C153D39717E5F444B81E7B85018A460B081B2727@ex-sj-5.digisle.com>
To: "Austin, Daniel" <Austin.D@ic.grainger.com>
Cc: <www-ws-arch@w3.org>
Hi Daniel,

Looking at the calendar, I think the WG will be well served to take
the cues from you the other day and again from Mike today to start
something on the requirements.

First of all, have you editor folks decided on how the requirements
be organized? E.g. are we to group them by categories, say: 
General (WSAGenReqxxx), Security (WSASecReqxxx),
Messaging (WSAMsgReqxxx), etc?

Separate from whatever you might have already made requirements of
using the WS properties I listed in
http://lists.w3.org/Archives/Public/www-ws-arch/2002Feb/0154.html ,
I've got a few more strawmen to start some Req Def fire.  I've taken
care to keep them dry (thus more flammable ;-) and shall embellish
on demand.  (Please feel free to retag the req IDs as you see fit
to jive with your doc style.)

Here they go.



  [UDI, XML, Standardized API, D&D, etc.  
   You've got them already, right?]

  The architecture MUST provide an interface for web services to
  directly communicate with their underlying infrastructure.

  The interface is for negotiating services that an infrastructure
  may provide to, or perform on behalf of, a requesting web services.
  Such value-added services may include: security, content delivery,
  QoS, etc.  For instance, a web service may instruct (via the
  interface) the security agents of its infrastructure to defend
  against DOS/DDOS attacks on its behalf.
  See also WSASecReq001.


There are six aspects in the security framework for web services
architecture: Accessibility, Authentication, Authorization,
Confidentiality, Integrity, and Non-repudiation.  Together they
form the foundation for secure web services.

  Accessibility to a web service can be impaired by DOS/DDOS attacks.
  It is understood that there's little a web service residing well
  above the transport layer of a network stack can effectively detect
  such transgression, let alone deploy countermeasures.
  Therefore, the security framework MUST provide recourse for
  web services to mitigate the hazard.

  See also WSAGenReq00x.

   In the "security completeness" thread, someone, sorry I forgot who,
   had stated that we should include Accessibility in WS security, and
   I suggested we should do the "five" and treat Accessibility only in
   the form of Security Consideration.  Come to think of it, we may as
   well go for broke and do them all in full.

  The security framework MUST include Authentication for the identities
  of communicating parties.

  The security framework MUST include Authentication for data (sent and
  received by communicating parties).

  The security framework MUST include Authorization, with allowance
  for the coexistence of dissimilar authorization models.

  The security framework MUST include Confidentiality.

  The security framework MUST include (data) Integrity.

  The security framework MUST include Non-repudiation between
  transacting parties.

  Note that there is a close relationship among WSASecReq002.1,
  WSASecReq002.2, WSASecReq005, and WSASecReq006, a la digital

  The security framework MUST include Key Management, pertaining
  to Public Key Encryption (PKE) and Key Distribution Center (KDC).

  The security framework document SHOULD provide some guidelines for
  securing private keys, though the methods for securing private
  keys is outside the scope of the architecture.

  The security framework document SHOULD recommend a baseline for
  trust models.


Joe Hui
Exodus, a Cable & Wireless service
Received on Tuesday, 5 March 2002 14:07:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:54 UTC