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