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

Summary: D-AG0006 -- Security

From: Joseph Hui <jhui@digisle.net>
Date: Fri, 29 Mar 2002 18:38:59 -0800
Message-ID: <C153D39717E5F444B81E7B85018A460B081B27A0@ex-sj-5.digisle.com>
To: <www-ws-arch@w3.org>

Goal Statement:

   addresses the security of web services across distributed
   domains and platforms. 

   There has been no new discussion on the goal statement since
   the last D-AG0006 status update in [1].

   It's noteworthy that after some discussion, Privacy has been
   set up as a distinctive goal, separate from Security.  Efforts
   have been made during Privacy discussions to obviate the
   distinction between Privacy and Security, e.g. the protection
   of data privacy falls into the Confidentiality aspect of

   [Note from Joe to Editors: In security literatures, "security
   facets" is more widely used than "security aspects" is, especially
   when writing about problems for which there are known and 
   proven solutions.  The "facet" term may also help some readers
   to imagine securing something in a geodesic dome (with multiple
   facets).  However, I often find "aspect" more handy, because
   it allows me more freedom to write about issues that are not
   yet well understood, or are reasonably well understood but
   lacking in remedies.  For instance, I can comfortably call
   authc, authz, confidentiality, (data) integrity either 
   facets or aspects.  But I feel awkward to call "non-repudiation"
   and "accessibility" security facets because: 1) non-rep
   needs more than security primitives (i.e. Digital Signature)
   to work in complicated situations, e.g. the signer repudiates
   his own signature; and 2) there's no security primitive to
   defend against DOS/DDOS attacks, so the "accessibility facet"
   is actually a chink in the armor than a piece of armor.
   Calling them security aspects, OTOH, allows one to write extensively
   about them without setting the readers up for disappointment.
   It's just my personal preference (for "aspect").  
   Some WG members may prefer "facet" instead.
   If the WG's rough consensus is to go with "facet," then I'll
   go along and switch accordingly for the sake of uniformity
   in our nomenclatures.  Thx!]

Critical Success Factors:
   The CSFs are expressed in terms of executables to accentuate
   the imperative need for a well disciplined approach in the
   design for Web Services security framework.)

   1) The construction of a Web Services Threat Model based on
      thorough analysis of existing and foreseeable threats to
      Web Service endpoints and their communication.

   2) The establishment of a set of Web Services Security Policies
      to counter and mitigate the security hazards identified in
      the thread model.

   3) The construction of a Web Services Security Model that
      captures the security policies (to be executed by security

   4) The realization of the security model in the form of a
      Web Services Security Framework that is an integral part
      of the Web Services Architecture (which is the ultimate
      deliverable of this working group).

Requirements (compiled so far)

   The requirements compiled so far is neither complete nor final.
   The list only contains items that have been reasonably 
   solidified.  It is expected to grow, as there are proposals
   still in the state of being solidified, and new proposals
   may still float in.  
   [*** Dear all, 
    *** consider this a serious call for WSSec requirements!

   General (in the General category, but needed by Security)
     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.
     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.

[1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Mar/0233.html


Joe Hui
Exodus, a Cable & Wireless service
Received on Friday, 29 March 2002 21:39:10 UTC

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