RE: Straw man list of goals for WSAWG - AG006

Realizing David's proposal of doc format was in reply to Gerald's,
I should clarify that my "sounds good" endorsement was given
within the context of my last pro-completeness reply [pro_comp]
to David.

My position remains that the 5 sec aspects should be addressed
in the doc(s) to reasonable extent.

Joe Hui
Exodus, a Cable & Wireless service

[pro_comp]
http://lists.w3.org/Archives/Public/www-ws-arch/2002Feb/0096.html
==================================================================
> -----Original Message-----
> From: Joseph Hui 
> Sent: Friday, February 15, 2002 5:43 PM
> To: David Orchard; www-ws-arch@w3.org
> Subject: 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 21:52:21 UTC