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 15:31:40 UTC