A SASL and GSS-API Mechanism for OAuth
draft-mills-kitten-sasl-oauth-04

Document Type Replaced Internet-Draft (individual)
Last updated 2012-02-06 (latest revision 2011-10-31)
Replaced by draft-ietf-kitten-sasl-oauth
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-ietf-kitten-sasl-oauth
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-mills-kitten-sasl-oauth-04.txt

Abstract

OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses OAuth over the Simple Authentication and Security Layer (SASL) or the Generic Security Service Application Program Interface (GSS-API) to access a protected resource at a resource serve, and additionally defines authorization and token issuing endpoint discovery. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a token. Tokens typically provided limited access rights and can be managed and revoked separately from the user's long-term credential (password).

Authors

William Mills (wmills@yahoo-inc.com)
Tim Showalter (timshow@yahoo-inc.com)
Hannes Tschofenig (Hannes.Tschofenig@gmx.net)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)