- From: Charles McCathieNevile <chaals@opera.com>
- Date: Tue, 04 Apr 2006 14:02:23 +0200
- To: "Web API public" <public-webapi@w3.org>
Hi, trying to clear old actions. At the face to face we discussed the question of whether open() should be allowed/obliged/forbidden/... to use the authentication information that had been provided to access a page. In summary, I think the answer is "Yes, subject to security restrictions that may be imposed by a browser". The basic scenario is that http://example.com/example has some XHR request to http://example.com/exampleData where both of these are secured by basic HTTP authentication. In general, this doesn't expose any new risk, although there is a risk that it can be used to pass information to exampleData that the user would not have done. Where the scenario becomes, for example, http://example.com/example passing the data to http://valid.example/dodgyScript it is clear that this could imply a risk. However, the realistic scenario of logging into http://flickr.com using an HTTP authentication, and then wanting to access linked data at http://my.yahoo.com provides an obvious use case for this if the security risks can be deemed acceptable. That question should not be up to this group to decide. Browsers may choose to block any kind of request, or to deny it access to or use of authentication information. Typically they do today, in the absence of a well-deployed trust framework, but there are some important exceptions. A similar issue is faced with cookies. (warning: The following is an IETF URI that will just vanish at some unspecified point in time) http://www.ietf.org/internet-drafts/draft-pettersen-dns-cookie-validate-00.txt describes one approach that is used to determine security restrictions, but there are other possibilities. cheers Chaals -- Charles McCathieNevile chaals@opera.com hablo español - je parle français - jeg lærer norsk Peek into the kitchen: http://snapshot.opera.com/
Received on Tuesday, 4 April 2006 12:02:36 UTC