Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt
Bill Mills <wmills_92105@yahoo.com> Wed, 17 September 2014 00:04 UTC
Return-Path: <wmills_92105@yahoo.com>
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 3D1761A03F1 for <kitten@ietfa.amsl.com>; Tue, 16 Sep 2014 17:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.131
X-Spam-Level:
X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] 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 KNCzHCenvVci for <kitten@ietfa.amsl.com>; Tue, 16 Sep 2014 17:04:10 -0700 (PDT)
Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEF81A00AE for <kitten@ietf.org>; Tue, 16 Sep 2014 17:04:10 -0700 (PDT)
Received: from [66.196.81.173] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 17 Sep 2014 00:04:09 -0000
Received: from [98.139.212.207] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 17 Sep 2014 00:04:09 -0000
Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 17 Sep 2014 00:04:09 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 739512.82850.bm@omp1016.mail.bf1.yahoo.com
Received: (qmail 36521 invoked by uid 60001); 17 Sep 2014 00:04:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1410912249; bh=3JZZKlvVHvPDCCv16CalGWm3Rep2+rS/Iax0Jke/f0Q=; h=References:Message-ID:Date:From:Reply-To:Subject:Cc:In-Reply-To:MIME-Version:Content-Type; b=gNnzlJnbVE/DqIPY0EwXe5VspHfklWJGjJKaj8i7itsZVEAb56NyA9FESup/WswWdHNijLmvxh8umRNYOc9o/u8+fS5kZZheO/STnCbNXlW+C30rR/OVIB2lrFnN8aOKnK79Z+z33jNSPVqQn21CFRjjGf0+BCUq+6f11QeSp8I=
X-YMail-OSG: Qc.w.dgVM1nuQDuaNINBSj2Ya8DOmlKZda3E_CpxBZdnIsB rCQE2QWIsKmQCqX0k1.qGoh0bY1YCP98cveTpE2t0CbQ4A2F35Q0Oq8FqjTa 06tjUsH00zQ9MElbmjH2So3PJbBgLhSvG9J4ngSC.KK7.bQiQHMHV99iCtjU 1YoT4R5SMlxdAEa5DMoSVjYeipVPGYsyDC_cXvXUnwt9n.dxxGdVCVQi4j2_ 9hGfvv27.cACfrxKgwewGx5C14iiw54wxQYc8l.r4bsyD9TfKyG4cY_9qsDQ qd_iVVCGqso9OKPl9SW7SQd1iR6nZNznGm9WcSEIpArIRd9EXbHfHS5IA1Bs L_cZiDCAwDJU6erXs3yOuaGn7.OQAlLQezMbWktQBzeDuUIavzeoF.2jyUAW AQd3s.WXZVdIMzVqraWhk16CXTHa8F56lZu09SKyGsuDQV32LlQNcZM6yvei Bpd0is6hWXzyXSAjgaq5ZT5eABYgmLY.IBGqZudAcS3Cpa.0EQOrCk0x98h6 7mi3gKNfeZvyo0eMufO3Ch6gPATA10lg0KNpxVMlTINhB3oJ56m16LH8EwvM rYcsa50Q0_qoh72d_ga3O1qqfzlxaDx2dqAaX0dbJCr_8iNhhrlNi
Received: from [167.220.24.156] by web142801.mail.bf1.yahoo.com via HTTP; Tue, 16 Sep 2014 17:04:09 PDT
X-Rocket-MIMEInfo: 002.001, LTE2IGlzIHN1Ym1pdHRlZCwgYW5kIHRoZXJlIGlzIG9uZSBzdWdnZXN0ZWQgY2hhbmdlICh3aGljaCBJIHdhcyBzdXBwb3NlZCB0byBoYXZlIGFkZGVkIGluIGFscmVhZHkgYW5kIGJsZXcgaXQpLCB3aGljaCBpcyB0byByZXBsYWNlIHNlY3Rpb24gMy4yLjIgd2l0aCB0aGUgdGV4dCAoZmFydGhlcikgYmVsb3cuCgpNeSBjb21tZW50cyBvbiB0aGUgc3VnZ2VzdGVkIHRleHQ6CgojMSkgIEkgZG9uJ3QgdGhpbmsgdGhlIGR5bmFtaWMgcmVnaXN0cmF0aW9uIHN0dWZmIGlzIGJha2VkIGVub3VnaCB0byB3YW50IHQBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.203.696
References: <20140916234519.22685.47362.idtracker@ietfa.amsl.com>
Message-ID: <1410912249.50514.YahooMailNeo@web142801.mail.bf1.yahoo.com>
Date: Tue, 16 Sep 2014 17:04:09 -0700
From: Bill Mills <wmills_92105@yahoo.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
In-Reply-To: <20140916234519.22685.47362.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/L7RrrBcTKlwmeiSPvx8xzfyxBos
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <wmills_92105@yahoo.com>
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: Wed, 17 Sep 2014 00:04:13 -0000
-16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text: #1) I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations. #2) I didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible. #3) I am against recommending scope names at all in any way. I would not include the last sentence of paragraph 5 below and strike the scope names. New text for 3.2.2: ----------------------- 3.2.2. Server Response to Failed Authentication For a failed authentication the server returns a JSON [RFC4627] formatted error result, and fails the authentication. The error result consists of the following values: status (REQUIRED): The authorization error code. Valid error codes are defined in the IANA "OAuth Extensions Error Registry" specified in the OAuth 2 core specification. scope (OPTIONAL): An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a scope value. If a scope is specified then a single scope is preferred, use of a space separated list of scopes is NOT RECOMMENDED. oauth-configuration (OPTIONAL): The URL for a document following the OpenID Provider Configuration Information schema, as described in Section 3 of the OpenID Connect Discovery [OpenID.Discovery], that is appropriate for the user. The server MAY return different URLs for users from different domains and a client MUST NOT cache a single returned value and assume it applies for all users/domains that the server suports. The returned discovery document MUST have all data elements required by the OpenID Connect Discovery specification populated. In addition, the discovery document MUST contain the 'registration_endpoint' element to learn about the endpoint to be used with the Dynamic Client Registration protocol [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of parameters necessary for the OAuth protocol exchange to function. Authorization servers MUST implement the authorization code grant and other grant types MAY be supported. Furthermore, authorization servers MUST implement the ability to issue refresh tokens for use with native applications to benefit from an abbreviated protocol exchange. The use of the 'offline_access' scope, as defined in [OpenID.Core] is RECOMMENDED to give clients the capability to explicitly request a refresh token. If the resource server provides a scope (as part of the element of the configuration payload) then the client MUST always request scoped tokens from the token endpoint. This specification RECOMMMENDs the use of the following scopes: imap: The 'imap' scope value is used to interact with IMAP mail servers. pop3: The 'pop3' scope value is used to interact with POP3 mail servers. xmpp: The 'xmpp' scope value is used to interact with XMPP servers. If the resource server provides no scope to the client then the client SHOULD presume an empty scope (unscoped token) is needed. Since clients may interact with a number of application servers, such as email servers and XMPP servers, they need to have a way to determine whether dynamic client registration has been performed already and whether an already available refresh token can be re-used to obtain an access token for the desired resource server. This specification RECOMMENDs that a client uses the information in the 'issue' element to make this determination. ----------------------- I think we're getting very close :) -bill Draft -16 notification follows: ---------------------------------------------------- On Tuesday, September 16, 2014 4:45 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-16.txt Pages : 22 Date : 2014-09-16 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten
- [kitten] I-D Action: draft-ietf-kitten-sasl-oauth… internet-drafts
- Re: [kitten] I-D Action: draft-ietf-kitten-sasl-o… Bill Mills
- [kitten] Suggested changes for -16 Re: I-D Action… Bill Mills
- Re: [kitten] Suggested changes for -16 Re: I-D Ac… Benjamin Kaduk
- Re: [kitten] Suggested changes for -16 Re: I-D Ac… Bill Mills
- Re: [kitten] Suggested changes for -16 Re: I-D Ac… Benjamin Kaduk
- Re: [kitten] Suggested changes for -16 Re: I-D Ac… Bill Mills
- Re: [kitten] I-D Action: draft-ietf-kitten-sasl-o… Torsten Lodderstedt
- Re: [kitten] [OAUTH-WG] I-D Action: draft-ietf-ki… Phil Hunt
- Re: [kitten] I-D Action: draft-ietf-kitten-sasl-o… Bill Mills
- Re: [kitten] I-D Action: draft-ietf-kitten-sasl-o… Torsten Lodderstedt
- Re: [kitten] I-D Action: draft-ietf-kitten-sasl-o… Bill Mills
- Re: [kitten] I-D Action: draft-ietf-kitten-sasl-o… Torsten Lodderstedt
- Re: [kitten] I-D Action: draft-ietf-kitten-sasl-o… Bill Mills
- Re: [kitten] [OAUTH-WG] I-D Action: draft-ietf-ki… Richer, Justin P.
- Re: [kitten] I-D Action: draft-ietf-kitten-sasl-o… Torsten Lodderstedt
- Re: [kitten] I-D Action: draft-ietf-kitten-sasl-o… Phil Hunt
- Re: [kitten] I-D Action: draft-ietf-kitten-sasl-o… Bill Mills
- [kitten] proposed softer revision to 3.2.2 Re: I-… Bill Mills
- Re: [kitten] proposed softer revision to 3.2.2 Re… Benjamin Kaduk
- Re: [kitten] proposed softer revision to 3.2.2 Re… Torsten Lodderstedt
- Re: [kitten] proposed softer revision to 3.2.2 Re… Bill Mills
- Re: [kitten] proposed softer revision to 3.2.2 Re… Shawn M Emery
- Re: [kitten] proposed softer revision to 3.2.2 Re… Bill Mills
- Re: [kitten] proposed softer revision to 3.2.2 Re… Bill Mills
- Re: [kitten] proposed softer revision to 3.2.2 Re… Benjamin Kaduk
- Re: [kitten] proposed softer revision to 3.2.2 Re… Bill Mills
- Re: [kitten] proposed softer revision to 3.2.2 Re… ⌘ Matt Miller
- [kitten] draft-17 Re: proposed softer revision to… Bill Mills