RE: Straw man list of goals for WSAWG - AG006

> -----Original Message-----
> From: David Orchard [mailto:david.orchard@bea.com]
> Sent: Friday, February 15, 2002 3:36 PM
> To: www-ws-arch@w3.org
> Subject: RE: Straw man list of goals for WSAWG - AG006
> 
[snip]
> How about we list security in the requirements and NFR 
> sections (assuming we
> have such things), and then differentiate underneath each 
> security section
> the appropriate func or nf reqs?  If it turns out one of them 
> is empty, then
> we'll delete it.

Sounds good, Dave.  

Have a nice weekend,

Joe Hui
Exodus, a Cable & Wireless service
==================================================
> 
> Cheers,
> Dave
> 
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org]On
> > Behalf Of Edgar, Gerald
> > Sent: Friday, February 15, 2002 3:20 PM
> > To: 'David Orchard'; www-ws-arch@w3.org
> > Subject: RE: Straw man list of goals for WSAWG - AG006
> >
> >
> > This is reasonable, to start with a rough sketch, and refine
> > it as we move
> > forward. My intent is to be as complete as possible, while
> > considering time
> > and other constraints too.
> >
> > I do NOT to place security as a non-functional requirement
> > though.  There
> > should be some level of security addressed from the start.
> >
> > Gerald W. Edgar <gerald.edgar@boeing.com>
> > Architecture support, BCA Architecture and e-business
> > 425-234-1422
> >
> > Mailing address:
> > The Boeing Company, M/S 6H-WW
> > PO Box 3707, Seattle, WA 98124-2207
> > USA
> >
> >
> >
> > -----Original Message-----
> > From: David Orchard [mailto:david.orchard@bea.com]
> > Sent: Friday, February 15, 2002 14:58
> > To: www-ws-arch@w3.org
> > Subject: RE: Strawman list of goals for WSAWG - AG006
> >
> >
> > Completeness can be a nice to have, but where does it fit in
> > the schedule?
> > Again, my suggestion is that we sketch out the rough areas of
> > requirements,
> > leaving all requirements not fully complete.  We then start a
> > select # of
> > working groups, and iterate to complete the requirements and receive
> > feedback on the initial requirements.
> >
> > I am strongly opposed to completeness of requirements being a
> > "requirement"
> > for starting additional working groups.  Again, time to
> > market is crucial
> > for us.
> >
> > The trade-offs that we will have to make will need to be
> > discussed further.
> > In the architecture documents I've produced in the past,
> > there is typically
> > a section for "non-functional" requirements (NFRs), like 
> performance,
> > scalability, composability, reliability, ease-of-use, security,
> > evolvability, accuracy, interoperability, portability, etc.  This is
> > sometimes referred to as the "ilities" section.  There is never an
> > architecture that can fully match all the NFRs, so 
> organizations make
> > choices about which ones to favour.  We will need to do the same.
> >
> > To look at a few NFRs, the web made scalability of # clients
> > and server
> > robustness extremely high priorities, compared to message
> > reliability or
> > security.   You can see this because there are no reliability
> > guarantees nor
> > security in the core web specs - adding ACLs and SSL came
> > later.  And it
> > never added non-repudiation or audit trails.  Even
> > performance at a message
> > level was not a high priority - typical RMI/CORBA/DCOM
> > systems outperform
> > HTTP for any given message interaction at a protocol level.
> > A wonderful
> > example of doing the right prioritization and ordering of
> > specification,
> > with completeness (in this example security and message
> > reliability) not
> > being high priorities.  I remember many a debate on why "distributed
> > objects" were going to win out over the web, but it turns 
> out the web
> > priorities were much better made.  Hence why we are all here ;-)
> >
> > On the specific topic, I believe we can start with a sketch
> > of security, and
> > then after we have decided the requirements priorities, we
> > decide which
> > security requirements are addressed in which order.  I
> > believe completeness
> > of your step 2)(which I slightly change from security issues
> > to security
> > requirements) is not required before beginning your step 3).
> > FWIW, I favour
> > leaving audit trails and non-repudiation out of scope for us.
> >
> > To fully flesh out which requirements have priorities, we
> > also need use
> > cases.  Different security related use cases will help us
> > determine what we
> > need to stdize.
> >
> > Cheers,
> > Dave
> >
> > > -----Original Message-----
> > > From: www-ws-arch-request@w3.org
> > [mailto:www-ws-arch-request@w3.org]On
> > > Behalf Of Joseph Hui
> > > Sent: Friday, February 15, 2002 12:32 PM
> > > To: Edgar, Gerald; www-ws-arch@w3.org
> > > Subject: RE: Strawman list of goals for WSAWG - AG006
> > >
> > >
> > > Completeness should be a very-nice-to-have WS architectural
> > > quality.  (I'm not expecting arguments against it. :-)
> > > WS security is not complete if any of following five aspects
> > > is not addressed: confidentiality, authentication, authorization,
> > > integrity, and non-repudiation.  (See [1] for the example/use
> > > case I gave.)
> > >
> > > Accessibility should also be addressed, but IMHO only in the
> > > form of Security Consideration, because frankly there's not much
> > > one can do *effectively* at the XML layer against DOS/DDOS.
> > >
> > > Also, we can't really have a meaningful WS security discourse
> > > in an arch doc without first setting the premise of trust
> > > What's the trust model that will be most recommendable?
> > > I see issues such as this as more overriding in our current
> > > context.  We are at the goal setting stage; we have a goal;
> > > and the goal is good enough.
> > >
> > > So I suggest we not get hung up on the splitting thing at this
> > > juncture.  Instead, in steps: 1) keep the goal as-is; 2) start
> > > compiling what WS-Sec issues there are; 3) determine what we
> > > shall and shall not address, and set subgoals accordingly.
> > > Only at step 3 can we have a clear vision on what and how
> > > to do the splitting.
> > >
> > > BTW, I'm withholding my judgment on whether the IETF philosophy
> > > and models are directly transplantable to WS-Sec, notwithstanding
> > > my inclination to capitalize on the good Sec works from there.
> > >
> > > Cheers,
> > >
> > > Joe Hui
> > > Exodus, a Cable & Wireless service
> > >
> > > [1]
> > http://lists.w3.org/Archives/Public/www-ws-arch/2002Feb/0055.html
> > >
> > 
> ======================================================================
> > >
> > > > -----Original Message-----
> > > > From: Edgar, Gerald [mailto:gerald.edgar@boeing.com]
> > > > Sent: Friday, February 15, 2002 10:22 AM
> > > > To: www-ws-arch@w3.org
> > > > Subject: RE: Strawman list of goals for WSAWG - AG006
> > > >
> > > >
> > > > I think that breaking this into Communications and Systems
> > > > security would be
> > > > sufficient.
> > > >
> > > > Systems security could in turn be addressed as message and
> > > > applications
> > > > security. Higher level would fit this effort better so
> > that we could
> > > > determine who is addressing these requirements. Security for
> > > > each area would
> > > > then cover the confidentiality, integrity, and
> > > accessibility aspects.
> > > >
> > > > for these I use:
> > > >
> > > > confidentiality : to protect data  against unauthorized
> > > disclosure to
> > > > unauthorized individuals or processes. (not privacy which
> > > > refers to the
> > > > right of someone to determine how it will interact with its
> > > > environment,
> > > > including how much to reveal)
> > > >
> > > > integrity : protecting against unauthorized changes to 
> data, both
> > > > intentional and accidental-ensuring that changes to data are
> > > > detectable.
> > > >
> > > > availability : protection against unauthorized deletion or
> > > > otherwise cause a
> > > > denial of access to the data or service
> > > >
> > > >
> > > >
> > > > Gerald W. Edgar <gerald.edgar@boeing.com>
> > > > Architecture support, BCA Architecture and e-business
> > > > 425-234-1422
> > > >
> > > > Mailing address:
> > > > The Boeing Company, M/S 6H-WW
> > > > PO Box 3707, Seattle, WA 98124-2207
> > > > USA
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com]
> > > > Sent: Thursday, February 14, 2002 17:09
> > > > To: www-ws-arch@w3.org
> > > > Subject: RE: Strawman list of goals for WSAWG - AG006
> > > >
> > > >
> > > > > > AG006 addresses the security of web services across
> > > > > > distributed domains and
> > > > > > platforms
> > > >
> > > > W.r.t. AG006, we need to address transport-, message-,
> > > > and application- level security for web services.
> > > >
> > > >
> > > > This does not imply that we split the security objectives
> > > > into three sub-areas necessarily though; it implies we
> > > > define the principal components of web services security
> > > > and their relationships with other elements of a web
> > > > services system (transaction, routing, registry, auditing,
> > > > etc.)
> > > >
> > > >
> > > > ---Zahid
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Joseph Hui [mailto:jhui@digisle.net]
> > > > Sent: Thursday, February 14, 2002 10:49 AM
> > > > To: Sandeep Kumar; Champion, Mike; www-ws-arch@w3.org
> > > > Subject: RE: Strawman list of goals for WSAWG
> > > >
> > > >
> > > >
> > > > Splitting sec into Message and Transport levels has one
> > disadvantage
> > > > I can think of: extra work.
> > > >
> > > > E.g. a connection between A & B conducting WS
> > transactions requires:
> > > > confidentiality, authentication, (mutual) authorization,
> > integrity,
> > > > and non-repudiation.  The five requirements can be
> > > satisfied by using
> > > > XML-sig messages over TLS with client authentication.  In
> > this case,
> > > > XML-sig is at Message level; and TLS is at Transport level.
> > >  Splitting
> > > > the sec work into two levels will necessitate extra work to
> > > > define some
> > > > glue between the two levels.
> > > >
> > > > Of course there may be advantages in splitting Ag006.  (What
> > > > may they be?)
> > > > I'd like the group to consider the above while
> > deliberating to split
> > > > or not to split.
> > > >
> > > > Cheers,
> > > >
> > > > Joe Hui
> > > > Exodus, a Cable & Wireless service
> > > > =================================================
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Sandeep Kumar [mailto:sandkuma@cisco.com]
> > > > > Sent: Thursday, February 14, 2002 9:56 AM
> > > > > To: Champion, Mike; www-ws-arch@w3.org
> > > > > Subject: RE: Strawman list of goals for WSAWG
> > > > >
> > > > >
> > > > > A good compilation!
> > > > >
> > > > > I think AG006 should be split into Message Level Security and
> > > > > Transport
> > > > > Level Security.
> > > > > Cheers,
> > > > >
> > > > > Sandeep Kumar
> > > > > Cisco Systems
> > > > > sandeep.kumar@cisco.com
> > > > >
> > > > > -----Original Message-----
> > > > > From: www-ws-arch-request@w3.org
> > > > [mailto:www-ws-arch-request@w3.org]On
> > > > > Behalf Of Champion, Mike
> > > > > Sent: Thursday, February 14, 2002 9:43 AM
> > > > > To: www-ws-arch@w3.org
> > > > > Subject: RE: Strawman list of goals for WSAWG
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Austin, Daniel [mailto:Austin.D@ic.grainger.com]
> > > > > > Sent: Thursday, February 14, 2002 12:02 PM
> > > > > > To: www-ws-arch@w3.org
> > > > > > Cc: Carroll, Tom
> > > > > > Subject: Strawman list of goals for WSAWG
> > > > > >
> > > > > Thanks for doing this, it is an excellent "strawman".  Let me
> > > > > take a few whacks at it ... If I don't mention something,
> > > > > it means I generally agree with the point as written.
> > > > >
> > > > > >
> > > > > > AG001 ensures the interoperability of web services software
> > > > > > products from
> > > > > > different implementors based on well-defined standards
> > > > >
> > > > > Isn't that a pretty ambitious goal for a "reference
> > architecture"?
> > > > > I would think that only the *designs* of software could be
> > > > > consistent in that they refer to the same concepts e.g.,
> > > > > "a Web service endpoint" in the same way.
> > > > >
> > > > > > AG005 provides simplicity and ease-of-use that does not
> > > > impose high
> > > > > barriers
> > > > > > to entry for users of web services
> > > > >
> > > > > Again, I just don't see how a "reference architecture" could
> > > > > hope to do this.
> > > > >
> > > > > > AG006 addresses the security of web services across
> > > > > > distributed domains and
> > > > > > platforms
> > > > >
> > > > > Here, we need to be more specific about what "security means."
> > > > >
> > > > > >
> > > > > > AG007 is reliable, and stable, and whose evolution is
> > > > > > predictable over time
> > > > >
> > > > > I'd suggest that there's no point in mentioning what we cannot
> > > > > control.  If we do a good job on the other goals, and
> > > > > implementers find it useful, it will be evolve in a
> > > > > predictable manner.
> > > > > If not, it will end up in the bitbucket of history, end
> > of story.
> > > > >
> > > > > >
> > > > > > AG008 is coherent and consistent in its definition
> > > > >
> > > > > The highest priority, IMHO.
> > > > >
> > > > > >
> > > > > > AG009 is aligned with the semantic web initiative at W3C and
> > > > > > the overall
> > > > > > existing web architecture
> > > > >
> > > > > I'd suggest that the point is to come up with coherent
> > > architecture
> > > > > for web services that uses what is valuable from the
> > semantic web
> > > > > initiative and web architecture principles, but doesn't
> > treat them
> > > > > as formal constraints.  It is possible (HIGHLY unlikely,
> > > IMHO) that
> > > > > a coherent and consistent web services architecture could
> > > "violate"
> > > > > some of the web architecture principles as we think we
> > > > understand them
> > > > > today.  To constrain this group too heavily by the current
> > > > > understanding
> > > > > views on the subject could lead to some quasi-religous
> > > > > debates rather than
> > > > > a two-way dialog to clarify both the web architecture and
> > > > web services
> > > > > architecture in a fruitful way.  A casual glance at the
> > > > > xml-dist-app or
> > > > > xml-dev archives should give one reason for caution on
> > > this subject.
> > > > > And a casual glance at the trade press this week should
> > > > give us pause
> > > > > about formally tieing the web services and semantic web
> > activities
> > > > > together!
> > > > >
> > > > > >
> > > > > > AG011 is consistent with the existing web and its
> > > > > > heterogenous environment
> > > > > > and distributed architecture to the greatest extent 
> possible.
> > > > >
> > > > > Another EXTREMELY high priority goal IMHO.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> 
>

Received on Friday, 15 February 2002 20:42:46 UTC