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
