Re: [OAUTH-WG] draft-ietf-oauth-revocation-04
Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 26 January 2013 17:34 UTC
Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7167B21F8712 for <oauth@ietfa.amsl.com>; Sat, 26 Jan 2013 09:34:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42LYfOPwLG49 for <oauth@ietfa.amsl.com>; Sat, 26 Jan 2013 09:34:48 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 5859A21F86D9 for <oauth@ietf.org>; Sat, 26 Jan 2013 09:34:47 -0800 (PST)
Received: from [91.2.78.85] (helo=[192.168.71.36]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1Tz9eP-0002uW-Up; Sat, 26 Jan 2013 18:34:46 +0100
Message-ID: <510413B5.5050007@lodderstedt.net>
Date: Sat, 26 Jan 2013 18:34:45 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
References: <8B2E9343-A46D-4218-B771-CF4A72AE7E94@gmx.net>
In-Reply-To: <8B2E9343-A46D-4218-B771-CF4A72AE7E94@gmx.net>
Content-Type: multipart/alternative; boundary="------------020506040801020704000702"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-04
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Jan 2013 17:34:49 -0000
Hi Hannes, Am 11.01.2013 09:18, schrieb Hannes Tschofenig: > Thank you Torsten for updating the document. > > Two issues have been raised: > > 1) Terminology: Authorization vs. access grant vs. authorization grant > > There is a little bit of email exchange on that topic: > http://www.ietf.org/mail-archive/web/oauth/current/msg10426.html > > I personally don't have an opinion on the terminology in this case. I propose to change the term to "authorization grant". Any disagreement? > > 2) invalid_token error code > > As mentioned on the list, a new error code has to be registered (which is not a big deal). Re-using an error code with different semantic is of course confusing. > > Re-using an already defined error code and to provide additional text in the error_description is fine as long as the description relates to the originally defined error description. In the case of the invalid_request error code RFC 6749 defines it as > > invalid_request > The request is missing a required parameter, includes an > invalid parameter value, includes a parameter more than > once, or is otherwise malformed. > > and RFC 6750 says: > > invalid_request > The request is missing a required parameter, includes an > unsupported parameter or parameter value, repeats the same > parameter, uses more than one method for including an access > token, or is otherwise malformed. The resource server SHOULD > respond with the HTTP 400 (Bad Request) status code. Peter and George suggested a new error code "invalid_parameter". Do you suggest to reuse the Extension error codes MUST be registered (following the procedures in Section 11.4 <http://tools.ietf.org/html/rfc6749#section-11.4>) if the extension they are used in conjunction with is a registered access token type, a registered endpoint parameter, or an extension grant type. Error codes used with unregistered extensions MAY be registered. > > Let us know how you want to proceed on these two issues. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Torsten Lodderstedt
- [OAUTH-WG] draft-ietf-oauth-revocation-04 Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Torsten Lodderstedt
- [OAUTH-WG] draft-ietf-oauth-revocation-04 Donald F Coffin
- Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 George Fletcher
- Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Donald F Coffin
- Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Torsten Lodderstedt
- Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Donald F Coffin
- Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Torsten Lodderstedt
- Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Torsten Lodderstedt
- Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Donald F Coffin
- Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Torsten Lodderstedt
- Re: [OAUTH-WG] draft-ietf-oauth-revocation-04 Donald F Coffin