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 18:20:08 UTC