RE: Strawman list of goals for WSAWG - AG006

> -----Original Message-----
> From: David Orchard [mailto:david.orchard@bea.com]
> Sent: Friday, February 15, 2002 3:55 PM
> To: www-ws-arch@w3.org
> Subject: RE: Strawman list of goals for WSAWG - AG006
> 
> 
> Let's not get into rhetoric. 
Agree, absolutely!
I think we'll find there's much more agreement between
us than what's come across on the surface.
I actually wanted to pre-qualify "security completeness" 
with "you get what you pay for, but don't pay for what
you don't need."  Not all use cases need the 5 aspects
in [1]; but many do.

> The web cut huge corners in meeting security
> requirements and does pretty well. 
I don't think so.  The web does well indeed.  BUT,
it does so with http and https, not http alone.
B2C commerce didn't take off until https (i.e. HTTP
over SSL/TLS) came along.  SSL (v3 and later) and TLS
are tight as a drum.  There was no corner cutting in TLS.
Well, they IMHO missed "name based virtual hosting;"
but that was an oversight rather than corner cutting.
The web didn't cut corner by shoving the security gunk
to https either.  That was some modulization at work,
wasn't it? ;-)

BTW, please don't get the impression that I'm for 
securing every bits and bytes on and off the wire
indiscriminately.  Hey, don't guard the garbage! ;-)

> Security is really about risk assessment. 
I disagree.  Security is about security, period.
Risk assessment lets you know how secure or insecure your
system is; but doesn't make your system more or less secure.

> If we wanted fully secure systems, we wouldn't 
> connect them to a network among other things.
I'd use "Sufficiently" instead of "fully" here.
I too am a pragmatist.  We want sufficiently secured
systems only for those who need them and are willing
to pay for them, and there's no lack of such customers
in the market.  The WS to be sold to such customers
better be *sufficiently* secure, thus the call for
"completeness," because some do need the 5 (Ref [1]), no dice.

> The web meets a very reasonable level of
> risk, and applications can decrease the level of risk in an 
> modular manner.
> As a great example, people consider SSL part of the "web" and it is
> incredibly easy from a developer perspective to use http/ssl 
> instead of
> http.
  ^^^^ I think you meant s-http. 
I'm reasonably knowledgeable in the nuts and bolts of the two 
(i.e http/ssl & s-http).  S-http secures per object; SSL
secures per channel; ...  Much can be said about why https
outdid s-http, but I won't delve into it here because I
don't see the relevance to the "completeness" discussion.

Cheers,

Joe Hui
Exodus, a Cable & Wireless service

[1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Feb/0055.html.
======================================================================
 
But that has a significant performance impact - many 
> sites use ssl
> hardware encrypt/decrypt - so often sites have both ssl and 
> non-ssl zones.
> This gives control over the risk into the hands of the 
> information supplier,
> which is a good thing.
> 
> We do need to determine what levels of risk we are prepared 
> to accept in our
> specifications.  I specifically want to make sure we don't 
> follow down a
> path of "wonderful" security specifications - shttp, set, .. 
> - that do not
> end up being widely adopted.  Nor should we mandate an 
> arbitrary level of
> risk (ie always use ssl).
> 
> Where the group could also add value is in defining a 
> migration path or best
> practices between different risk levels and how web services 
> could increase
> or decrease the risk level they conform to.  ie "For greater 
> security use of
> a algorithm x in XMLEncryption for encrypting credentials in 
> a web services
> header, but this typically results in y decrease in performance and a
> tighter coupling for synchronization of algorithm input z".
> 
> 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 3:35 PM
> > To: David Orchard; www-ws-arch@w3.org
> > Subject: RE: Strawman list of goals for WSAWG - AG006
> >
> >
> > > -----Original Message-----
> > > From: David Orchard [mailto:david.orchard@bea.com]
> > > Sent: Friday, February 15, 2002 2:58 PM
> > > 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?
> >
> > The context of this thread is security.
> > Completeness fits snugly in security.
> > Where does schedule fit in security?
> >
> > We have to be thorough when it comes to security.
> > Incomplete security is as good as no security at all.
> > If you're a manufacturer of safes, you must ship safe,
> > not boxes.  If the time's up, and you haven't got a safe,
> > then you ship boxes, or don't ship at all.
> >
> > I agree we should be t-o-m sensitive and wouldn't mind
> > letting some minor things slide.  But there's no corner
> > cutting in security.
> >
> > Cheers,
> >
> > Joe Hui
> > Exodus, a Cable & Wireless service
> > ==========================================================
> >
> > > 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:27:26 UTC