[kitten] Last Call: <draft-ietf-kitten-sasl-oauth-22.txt> (A set of SASL Mechanisms for OAuth) to Proposed Standard

The IESG <iesg-secretary@ietf.org> Thu, 30 April 2015 18:31 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5B01B2EA9; Thu, 30 Apr 2015 11:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFDcJKExi4B5; Thu, 30 Apr 2015 11:31:47 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA141AC44E; Thu, 30 Apr 2015 11:31:47 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.2
Auto-Submitted: auto-generated
Precedence: bulk
Sender: <iesg-secretary@ietf.org>
Message-ID: <20150430183147.6167.76957.idtracker@ietfa.amsl.com>
Date: Thu, 30 Apr 2015 11:31:47 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/DzxDnrz5HccdIroeWF8nES_o9HE>
Cc: kitten@ietf.org
Subject: [kitten] Last Call: <draft-ietf-kitten-sasl-oauth-22.txt> (A set of SASL Mechanisms for OAuth) to Proposed Standard
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Apr 2015 18:31:57 -0000

The IESG has received a request from the Common Authentication Technology
Next Generation WG (kitten) to consider the following document:
- 'A set of SASL Mechanisms for OAuth'
  <draft-ietf-kitten-sasl-oauth-22.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-05-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ballot/


No IPR declarations have been submitted directly on this I-D.

This defines a way to use the obsolete OAUTH1.0a mechanism
as well an OAUTH2 mechanism. That is deliberate and reasonable.