IETF Logo Mail Archive

Re: [OAUTH-WG] Question about error response rule described in section 4.3 of draft v.10

"matake@gmail" <matake@gmail.com> Sun, 19 September 2010 00:54 UTC

Return-Path: <matake@gmail.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76FCF3A6818 for <oauth@core3.amsl.com>; Sat, 18 Sep 2010 17:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndsLkFggUL1s for <oauth@core3.amsl.com>; Sat, 18 Sep 2010 17:54:48 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id AF79C3A67B3 for <oauth@ietf.org>; Sat, 18 Sep 2010 17:54:48 -0700 (PDT)
Received: by pwi1 with SMTP id 1so1494661pwi.31 for <oauth@ietf.org>; Sat, 18 Sep 2010 17:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=SGW4jw5qj8/j5SG0BNntt+4iQ0fifzsR7XA4eIM8tLg=; b=v04A2gD/EMjCz9Rn3h6skWEO2nWM6+IhTqfHvut18rQ9IDLEFpgRdoIWkmetL5VJ8/ 0IYLgyJD2bo4Q2H9VNWwo9SyTuDNsAo9g/QjnlHwjeCpv8/UiVghwW+Vi6un+/Xcfxdb MXzvf+YjYMwVIUQoXNoZkKNkzmLHhVJp6U7x8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=OOC1OdpZtIssS/8uiXTmKOLggi77Nf2XCdF4mdnfAiOfbGqH524Ehg4I/gI38dcO0X 3uAyQVtPUsQoNHISiZ3A2xxUBjMxM6vNMuQyNZBGobShNIb70VLKKnjbSLldWoepUAW6 bv+GTAoDdyBfHGmLUwo6VvyjpLyvh87EZjGIk=
Received: by 10.142.97.15 with SMTP id u15mr2657819wfb.238.1284857713084; Sat, 18 Sep 2010 17:55:13 -0700 (PDT)
Received: from [192.168.1.24] (121-82-199-29f1.kyt1.eonet.ne.jp [121.82.199.29]) by mx.google.com with ESMTPS id o9sm4518131wfd.16.2010.09.18.17.55.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 18 Sep 2010 17:55:11 -0700 (PDT)
References: <C636E369-02E8-451F-AC0A-FCDA5555FDD1@gmail.com> <4C95016C.2030302@lodderstedt.net>
In-Reply-To: <4C95016C.2030302@lodderstedt.net>
Mime-Version: 1.0 (iPhone Mail 8B117)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <45A6E0D7-BC59-48A7-A628-DCAB72B8DE25@gmail.com>
X-Mailer: iPhone Mail (8B117)
From: "matake@gmail" <matake@gmail.com>
Date: Sun, 19 Sep 2010 09:54:28 +0900
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Question about error response rule described in section 4.3 of draft v.10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 19 Sep 2010 00:54:50 -0000

Ah, I see.
Thanks!

--
nov

On Sep 19, 2010, at 3:14 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

> Default for client password authentication is HTTP BASIC (cf. http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-2.1)
> 
> regards,
> Torsten.
> Am 16.09.2010 15:52, schrieb matake@gmail:
>> Hi experts,
>> 
>> I'm now developing OAuth2 server library in Ruby, rack-oauth2.
>> 
>> I have one question about error response.
>> 
>> In section 4.3, it says
>> 
>> "If the client provided invalid credentials using an HTTP authentication scheme via the "Authorization" request header field, the authorization server MUST respond with the HTTP 401 (Unauthorized) status code.Otherwise, the authorization server SHALL respond with the HTTP 400 (Bad Request) status code."
>> 
>> In which case, client sends credentials via the "Authorization" request header?
>> In my understanding, client put any credentials in request body when obtaining an access token.
>> Is there some use-cases I'm missing?
>> 
>> Thanks
>> 
>> --
>> Nov Matake (=nov)
>> http://matake.jp
>> http://twitter.com/nov
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>

v2.23.0 | Report a Bug | By Email