RE: Action-146: Starting up a new thread on "future proofing" WSC's recommendations

I think we already have a goal on that:
http://www.w3.org/2006/WSC/drafts/note/#deployment

Discussion is good. However, if discussion is intended to actually change 
the Note, members of the WG need to start explicitly signalling it, so the 
rest of us can tell. Anyone wanting to change the Note should start making 
concrete proposals for changes they would like to see, even if it's a 
"straw" one that they expect to be altered as the team discusses it.  That 
will help us drive the Note to closure, and move on to the Recommendations 
phase of our work. Otherwise, I'll assume discussion is "just" discussion, 
or is about how we get to Recommendations. 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect




Timothy Hahn/Durham/IBM@IBMUS 
Sent by: public-wsc-wg-request@w3.org
02/21/2007 07:44 AM

To
public-wsc-wg@w3.org
cc

Subject
RE: Action-146: Starting up a new thread on "future proofing" WSC's 
recommendations







Hi all, 

In my quick scan of Chuck's information provided below, I have to agree 
with this.  In fact, if I ever get them submitted, some of my comments on 
the draft note I think refer to some of what Chuck is questioning. 

In particular, I think one of our Goals should be to provide information 
to web entity providers (those administrators who are responsible for 
setting up and maintaining the security aspects of the web servers) on how 
to set up their secuirty settings so that the user agents of the world 
(whatever forms those take) have a better chance of discerning a possible 
attack from a mis-configured server.  It seems to me that today, it's not 
so easy to tell, and thus the user agent "throws up its hands" (or, in 
software speak, presents a question to a human) ... and the human doesn't 
have much more to go on, even if they're a security practitioner. 

Regards, 
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Durham/IBM@IBMUS
phone: 919.224.1565     tie-line: 8/687.1565
fax: 919.224.2530



"Doyle, Bill" <wdoyle@mitre.org> 
Sent by: public-wsc-wg-request@w3.org 
02/20/07 09:38 PM 


To
"Doyle, Bill" <wdoyle@mitre.org>, "Brad Porter" <brad@tellme.com>, "Chuck 
Wade" <Chuck@Interisle.net> 
cc
<public-wsc-wg@w3.org> 
Subject
RE: Action-146: Starting up a new thread on "future proofing" WSC's 
recommendations








Not trying to expand beyond Web Services or charter, but thought that is 
if we hand off or take a transaction to/from another service or device 
security services need to kept consistent if possible. 

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] 
On Behalf Of Doyle, Bill
Sent: Tuesday, February 20, 2007 7:22 PM
To: Brad Porter; Chuck Wade
Cc: public-wsc-wg@w3.org
Subject: RE: Action-146: Starting up a new thread on "future proofing" 
WSC's recommendations

Chuck, 
  
 I am glad this was picked up by the WG and you were able to articulate 
the need. 
  
M2C - Even though web service functionality is being embedded into all 
kinds of devices and new systems, the embedded capability can impersonate 
the user or user identity enabling the reuse of existing security context 
currently available. We will need to expand the security context because 
additional protocols are used like Secure Real-Time Protocol (SRTP), SIP 
also has security capabilities built in and I am sure the WG will run into 
others. 
  
The virtual phone can have chrome 
devices like IP phones can have X.509 certs and can use PKI 
infrastructure. 
 
  
Bill Doyle 
 

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] 
On Behalf Of Brad Porter
Sent: Tuesday, February 20, 2007 5:40 PM
To: Chuck Wade
Cc: public-wsc-wg@w3.org
Subject: Re: Action-146: Starting up a new thread on "future proofing" 
WSC's recommendations

I think this is incredibly insightful.  I look at the rapid growth of 
voice, mobile, and desktop widgets all being powered by the "browser" 
metaphor without the traditional browser.

The biggest challenge, I see, however, is that the trust relationship 
still goes from user->user agent->content.  So we still need to figure out 
what bits the user can trust and how they're going to get presented.

I think this also brings us back to asking the question -- what actions 
really require security context information?  The only cases I've heard so 
far are as follows:

1) Establishing that you are submitting your information to the party you 
intended 

2) Establishing that the information you received or are sending is 
"confidential" between you and the third-party

3) Establishing privilege when a site wants to access "privileged 
resources" outside of the typical sandbox 

(arguably #1 is a subproblem of #3)

I'll again observe that I think these can be solved as part of the 
active-task-flow instead of part of the passive-browser-context and 
therefore can be made far more robust and work far better across different 
user agents.

Brad

Chuck Wade wrote: 
Folks, 

During today's conference call, I opened my big mouth and introduced some 
new thoughts about the work of this group. For penance, I've been assigned 
the task of starting a new thread that will hopefully serve as a 
constructive dialog on how we can make useful recommendations for 
improving the ability of users to understand whether or not they should 
trust their Web interactions--not just for today's browsers and 
severs--but within the context of an evolved Web where users will use a 
variety of platforms and applications to interact with an increasingly 
diverse set of services. 

A concern I'd like to voice is that what really matters to users is their 
ability to establish confidence in their Web /interactions/, not their Web 
/browser/. This Group's "Notes" document does a commendable job of 
outlining the problems in presenting security information within the 
context of a browser, but if the majority of Web interactions in the 
not-too-distant future involve non-traditional browsers and other Web 
agents, then we run the risk of recommending improved practices and 
proposing solutions to last year's technology. By analogy, we could be 
describing how to make and use better buggy whips, just as the horse is 
being replaced with an engine. 

Note that I'm assuming that these future interactions will still employ 
the http and https protocols we know and love--they've already withstood 
the transition from HTML 1.0 through to XML. Continuing with my analogy, 
we may be replacing some horses, but we'll still be riding on the same 
roads--potholes and all. 

Mind you, I'm not predicting the demise of the venerable Web browser. I 
anticipate using a browser for everyday Web interactions for many years 
into the future. However, I am suggesting that we could soon see the 
majority of Web interactions (at least as measured by transaction volumes) 
based on non-traditional browsers or applications that are not in any way 
"browsers" as this term is currently understood. In many cases, Web 
interactions will move to special-purpose applications that alter the 
entire user experience. Apple's iTunes application and the way it 
integrates with their music store is one currently popular example of an 
evolved Web interaction model. Google Earth is a somewhat more extreme 
example. [What is the "security experience" for users with these sorts 
applications?] 

At the same time, it is quite likely that the Web is going to rapidly 
evolve beyond the current "page" model, and become a set of interactive 
services that blur the distinction between client and server, or page and 
viewer. Content is clearly becoming more dynamic and more multimedia. 
While these evolutionary trends will certainly be compelling to most 
users, there will also be further confusion about what entity a user is 
interacting with, especially as fraudsters and other n'er-do-wells move to 
exploit the new and evolved Web. 

So, why does any of this matter? Don't we have enough on our plates with 
trying to clean up security for today's Web browser/server model? 
Shouldn't we stick to our knitting and deal with the problem at hand? 
[Shouldn't I stop with all of these metaphors?] While it is tempting to 
declare that our scope should be constrained to the security "experience" 
offered by modern browsers, I would like to argue that doing so would be a 
mistake. 

Throughout the evolution of information processing systems, we have 
consistently introduced new features, capabilities, and services without 
security baked in, or even considered as a matter of fore thought. 
Security through hind sight has been the norm. However, to give credit 
where it's clearly due, early Web browsers and servers may be one of the 
few examples of where a mass market information service was developed with 
useful security mechanisms built in. True, there were many mistakes, and 
the promise of better security has not yet been realized. At the same 
time, this is the very experience that should be instructing new 
initiatives to evolve the Web. If we don't carry forward the lessons that 
have been learned from the past, then....... 

To stimulate further dialog along these lines, let me offer some arguments 
for a broader approach that attempts to anticipate future evolution of the 
Web: 

 1. New applications offer new opportunities to employ better 
    approaches to security usability than can be practically 
    retrofitted to traditional browsers and servers. 

 2. The classic browser model has become a constraint on improving the 
    "security experience" for users. Because it has to work in a 
    familiar way, it cannot easily require users to change their 
    approaches. 

 3. It is time to rethink the relationship between browsers and the 
    platforms on which they operate. How much better could the 
    security solutions be if vital security functions were 
    incorporated into the platform? Based on the experience this group 
    represents, what useful guidance could we offer to platform 
    developers? Conversely, what could we learn from platform 
    developers? [What would happen if all http/https services moved 
    into the platform?] 

 4. Platforms are evolving as well. Not just new OSs, but new hardware 
    form factors, new computational models, and new embedded security 
    functions are all ingredients in an ever more diverse set of 
    platforms. The "one laptop per child" and the "iPhone" are just 
    two examples of platforms that should be forcing radical new 
    thinking about how Web services should be delivered. [We all know 
    this, but shouldn't we actually be addressing the potential role 
    of new platforms in the recommendations we deliver from our mountain?] 


 5. It is increasingly important for security context to be carried 
    across multiple applications in a way that is visible and 
    comprehensible to real users. With today's browsers, this actually 
    does happen, but not in ways that most users could figure out 
    what's going on. [Try visiting the W3C site, logging in, and then 
    switching to a different browser and accessing the same 
    pages--there's a lot going on under the covers that depends on 
    your platform and the browsers you use.] What should happen when a 
    user "browses" the world using Google Earth, enters a shopping 
    mall, and then goes to buy something from a merchant that has 
    extended their physical mall presence into cyberspace? [There's a 
    similar scenario for the user that starts out in Second Life.] 

 6. With an evolving Web will come evolving threats. Before new 
    applications are introduced, it would be highly advantageous to 
    put forward guidance for how to extend the Web without introducing 
    major new vulnerabilities that open new threats. Here is where our 
    "voices of experience" coupled with the credibility of W3C can 
    influence future outcomes in a positive manner. Just establishing 
    some discipline for how users are presented with security context 
    they can use would be a positive force in shaping the future of 
    the Web. 

 7. Security functions like "Basic Auth" started down a useful path, 
    but got hopelessly off track. Can we propose new security 
    functions that not only get it "right," but that could also be 
    consistently offered within all future Web application contexts? 

 8. The Web can also be evolved to support more constrained 
    environments, not just glitzy new multimedia flash dances. For 
    example, why does a banking application need to be anything more 
    than a simple interface that operates in a highly constrained, but 
    [hopefully] more secure environment. Can we propose ways to allow 
    the Web to evolve to support such constrained interactions where 
    the client application and server support a fundamentally more 
    secure interaction model that reinforces user trust and 
    confidence? If we were to postulate a "banking widget" sitting on 
    our virtual desktops, what would be the optimal way to present 
    security context to the user? 


The issues I've raised above are not easily addressed, and they do expose 
the work of this group to the threat of unconstrained scope creep. At the 
same time, I contend that these issues will be difficult to avoid, so 
perhaps we should think about possible frameworks in which we can propose 
better ways to reinforce user trust in Web interactions--now, and in the 
near future. 

...Chuck