Every existing use of Cookies, HTTP Basic, and HTTP Digest relies on clients 
being told by the server about the sites at which the secret 
(cookie/password/token) can be used (and, more importantly, where is must not 
be used). This occurs without requiring service-specific knowledge in the 
client app. OAuth aims to replace some of these uses.



HTTP Basic authentication works safely from clients with no service-specific 
knowledge because the client knows not to send the password it gets from the 
user to other sites.



HTTP Digest authentication allows a password to used to across a set of domains 
specified in a WWW-Authenticate response header, but the password will not be 
used at arbitrary other sites.



Cookies are sent in requests to the same site, sites with the same parent, or 
only https sites, depending on details from the service when setting the cookie.





To date, OAuth has assumed every client app has lots of service-specific 
knowledge to make these choices. OAuth needs to remove the need for so much 
service-specific knowledge to be as interoperable as other standard auth 
mechanism, otherwise it is a poor replacement.



--

James Manger



From: David Recordon [mailto:record...@gmail.com]
Sent: Friday, 7 May 2010 2:05 PM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid



Hey James,

Do you have a specific example in mind where this either has been an issue or 
will be an issue? Most client implementations I've seen of OAuth (and 
technologies like OAuth) have a strong binding between the access token(s), 
site they were issued by, and user they belong to. So I haven't heard of this 
being a problem in the wild...



--David



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to