W3C home > Mailing lists > Public > www-xkms@w3.org > August 2002

Comments on WSA Requirements

From: Joseph Reagle <reagle@w3.org>
Date: Fri, 23 Aug 2002 12:30:04 -0400
To: <austin.d@ic.grainger.com>, <abbieb@nortelnetworks.com>, <sharad.garg@intel.com>, chrisfer@us.ibm.com
Cc: www-wsa-comments@w3.org, www-xkms@w3.org
Message-Id: <200208231229.12479.reagle@w3.org>

These comments on [2] supercede my previous comments [1]

[1] http://lists.w3.org/Archives/Team/w3t-archive/2002May/0016.html
[2] http://www.w3.org/TR/2002/WD-wsa-reqs-20020819

   3.2.1 Top-level Goals

   The Working Group has determined that at the highest level, its goals
   can be divided into 6 categories. Each of these is associated with the
   CSFs and requirements listed in [47]section 3.2.2

While it might be implied that these goals will be further expounded upon in 
3.2.2, it might be useful to state this.

  AC008 is consistent and coherent. This applies to both 
  the reference architecture itself and the document that 
  contains its definition.

What is a "reference architecture"?

    D-AC001.1.1: Ensure that no individual implementor is favored 
   over others.

While I continue to appreciate the sentiment, it sounds as if it will create 
dead locks. What happens if you have to make an arbitrary technical 
decision and *someone* benefits from it, can you not make the decision? A 
decision will always benefit someone more than someone else, however, you 
don't want this to be part of the reason for the decision. I think, 
instead, you want something like, "decisions will be not be made on the 
basis of favoring any particular implementor over others."

     * AG004 Security
       The Web Services Architecture must provide a secure environment
       for online processes.
       Critical success factors and requirements for this goal:
          + [57]AC006 addresses the security of Web services across
            distributed domains and platforms.
          + [58]AC020 enables privacy protection for the consumer of a
            Web service across multiple domains and services.
     * AG005 Scalability and Extensibility
       The web services architecture must promote implementations that
       are scalable and extensible.

What do these terms mean: encourage/promote (perhaps use one?), enable, 
provide, and support?

Encourage X: while out of scope of any technical specification, recommend X?
Enable X: X can be implemented by using the facilities of the archtiecture 
(does this mean X can be implemented using the facilities of the 
architecture and nothing more?)
Provie X: a concrete deliverable?
Support X: Unlinke enable, X can be implemented by using the facilities of 
the architecture amongst other piences?

(A term I sometimes also use is, "not preclude".)

This is relevant to your later non-repudiation requirement. "Non-repudation" 
is typically determined by a combination of algorithm (cryptography) 
properties and policy/legal definitions. Do you plan to require particular 
algorithms necessary for non-repudation? Or define what it means in your 

          + AR016.1 Identify what constitutes interoperability
               o D-AR016.1.1 in architectural realm.
               o D-AR016.1.2 in technological realm.

What's the difference between the architectural and technical realm?
          + AC020.2 Advertised Web Service privacy policies MUST be
            expressed in P3P.

Normative reference?
Received on Friday, 23 August 2002 12:31:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:39 UTC