User Study Results of Status Quo
Status Quo - Secure Web Services incorporates the use of Internet Infrastructure, Web Services, Protocols, User Agents, Web Servers and the User. These services are discussed below in order to provide context for WSC WG activities.
Although web services have powerful security capabilities noted in the security context section of the note, some of the current problems with web security is that the user experience and ability for a "User" to determine "User Agent" security status is far from ideal. The problems are bad enough that IT people and security professionals can become frustrated in trying to determine what security is in place when a "secure" connection is attempted, completed or in error. If an error occurs, the user is often unable to determine if web security services are working, if the desired protection is in place and how to correct problems.
This section is designed to document current capabilities within the WG charter and goals. Section heading are created/edited by users supporting WG tasks.
PKI Certificates
PKI certificates such as X.509 and EV Certs enable HTTPs, the protocol that WSC is focusing on to support secure and trusted user sessions. Certificates are generated by third party or by local users.
Certificates need to be managed, created, updated and removed. The user interfaces and dialog boxes supporting the use of certficates is being taken up in the wiki xx,
X.509
Certificate Authority
EV Certs
extended validation - in IE, it will turn the URL green http://www.cabforum.org/certificates.html
HTTP
cookies [HTTP Cookie]
The P3P Policy (/P3P/) provides some information about what data is being stored in the cookies and how it's used. Several user-agents (IE6.0/7.0 at least) already provide visual Indicators about these and also provide ways for the user's to accept/deny cookies automatically (without showing cookie information in Annoying popups).
context-type
Response codes (e.g. 401 unauthorized). The User Agent must accurately use response codes provided by the server.
Referring page - Redirection path content-type -
Does the content come from multiple domains? - I know of no way I'm currently told about this.
HTTP Auth
HTTP-Auth handshake - Type of authorization is requested by the server “Authenticate header”.
- Basic (ID / Password)
- Digest (Additional name value pairs e.g. user name + realm + password)
- Integrated (GSS-API, Intranet / SSO domains)
HTTPs
Was the content requested to transmitted securely? The URL will begin with https if it was. The lock icon appears as well. If some content is secured this way and some not, there's this extra prompt before display. Some browsers also change the color of the URL display.
SSL server certificate chain - Seems to tell the user only tells me when things go wrong. Here's what Mozilla does: /2006/WSC/wiki/NoteMozillaCertificateValidationErrors. George couldn't suck it up and post the KDE errors, and no one seems to be able to say what IE does. User can drill down through browser specific errors in an attempt to determine what is wrong.
HTTP Status and response codes
HTTP provides status messages and response codes enabling user agents to interact with web servers in a defined manner.
- Response Code (401 unauthorized) HTTP authentication-handshake failed.
- Page Status
User Agents - Code and Language Capabilities
The User Agents are comprised of code and language capabilities (e.g. HTML, Java Script, Java, Windows .NET). User Agents provide the functionality that enables a User to interact with data services provided by the web server. It is expected that the capability (User Agent) created by the code supports security, data and message integrity and helps the user make correct decisions within the context of the web session
presence, capabilities and control of dynamic content
* ActiveX * Java Script
HTML, Code Capabilities
- Target URI for a hyperlink or form submission
- URIs, anchors, embedded images and other elements that contain URIs as parameters
- Status Codes
- cookies - application guidance, User Agent guidance.
Chrome User Agent managed screen realestate providing visable clues to the user
- Document Status
Messsages / Dialogs
- PKI verification of certificates if verification required
- Does the content come from multiple domains?
- Page Status
- Has the page completed loading?
- Page errors
- presence of dynamic content
- server hostname - re displayed the hostname somewhere.
- server IP address -
- localhost versus intranet versus internet - Some browsers display
- a picture and text in the lower right hand corner.
Configuration
- certificates
- Pre-installed
- User configured
- installed search engines
- default window layout
- default bookmarks
- default configuration
- Bookmarks
- Browsing History
- Pre-installed certificates
Chrome~+ Mouse Overs, target URI for a hyperlink or form submission. A mouse over over a hyperlink shows the URL in a status area in the chrome in many browsers.
~+NOTE: Status Messages
[Praveen]
With the new Web2.0 applications (most of them sending requests asynchronously), the progress indicator doesn't anymore mean that the page is still loading. It's just some data the web site/app is trying to load to provide better user-experience to the user.
[Praveen]
Some mentioned on the call today that the back ( & forward) buttons provide this info. I don't think that's always true. They only display the url (page title if available) if the request returns a HTTP response status code 200. If the response code is 302/301 for example - the most commonly used mechanism to redirect a user-agent from one url to another, the original Page/Url requested is no longer stored in the browser's history - and hence not displayed in the back/forward button list.
Today all user-agents, with their default settings (which most users disable anyway), only display warnings to the user when the redirects are from Secure (SSL) to insecure (non-ssl) urls and vice versa. But there are no such warnings when a user is being redirected automatically from one site (domain) to another. Not sure if it really helps or not in all cases but might be helpful against url spoofing.
In the federated single sign on use cases, where users are redirected from one site to another for authentication and single sign on, this might be useful for the user to identify his own Identity Provider.
Web Server
Provides session security, integrigy and status messages
Connection Security
- Server config - connection (e.g. HTTP protocol used in a secure mode)
- Acceptable Ciphers negotiated
- Mutual Certificate Authentication (verify the client cert)
Application Security
- Authentication Robustness
- addition fields/services used by the web server to verify the users authenticity
- Authentication Robustness
- ID/PW
- ID / PW + Personalisation
- Two Factor ID / PW + Token, Smart Card, Biometrics
Authentication Robustness can limited capabilities of a user session based on authentication mechanism (e.g. Id/Pw = basic services Buy sell stock < $10,000, Smart cart = buy sell stocks < $1M
User
- submitted form values
- bookmarks
- browsing history
- site introductions
- introductions from friends / trusted source
- certificates added by the User to the User Agent
- How was the URL entered?
- typed into address bar
- pasted into address bar
- clicked hyperlink
- command from another application
- user agent customization
Site Introductions
Third-party
- reputation service
- hyperlinks on visited web pages
- search engine results
reputation service - Michael M produced the best writeup I know on that http://lists.w3.org/Archives/Public/public-wsc-wg/2007Feb/0081.html hyperlinks on visited web pages - not sure what we're getting at here; perhaps more future looking. introductions from friends search engine results - I search, I see them. I've heard it referred to as the "ten blue links" paradigm.