Technical Summary
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 credentials
obtained via OAuth over the Simple Authentication and Security Layer
(SASL) to access a protected resource at a resource serve. 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 shared
secret with higher entropy, i.e., the token. Tokens typically
provide limited access rights and can be managed and revoked
separately from the user's long-term password.
Working Group Summary
The review process for this document was very long and complicated.
See the shepherd write-up for details, it is comprehensive and...
...long... but ends with:
The fourth WGLC achieved consensus with support from both kitten and
the oauth working groups. It did result in a few clarifications to
the document, fixing the ABNF and examples, noting the generic SASL
cancellation token functionality, and reiterating the TLS requirements
for using this mechanism, but these changes were not controversial.
Document Quality
The long gestation period here has resulted in pretty high
quality documentation of this not that hard to understand
combination of schemes. I'm not sure about implementation
status.
Personnel
The document shepherd is Benjamin Kaduk. The responsible Area
Director is Stephen Farrell.