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