[OAUTH-WG] Seeking clarity on Section 4.3 and the specification of client credentials
Todd W Lainhart <lainhart@us.ibm.com> Tue, 04 October 2011 20:49 UTC
Return-Path: <lainhart@us.ibm.com>
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 8196D21F8D4A for <oauth@ietfa.amsl.com>; Tue, 4 Oct 2011 13:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txkHO+L+rhwc for <oauth@ietfa.amsl.com>; Tue, 4 Oct 2011 13:49:39 -0700 (PDT)
Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id D6EA421F8D44 for <oauth@ietf.org>; Tue, 4 Oct 2011 13:49:38 -0700 (PDT)
Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p94KGxsg000594 for <oauth@ietf.org>; Tue, 4 Oct 2011 16:16:59 -0400
Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p94Kqgr23088422 for <oauth@ietf.org>; Tue, 4 Oct 2011 16:52:42 -0400
Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p94KqgsO002732 for <oauth@ietf.org>; Tue, 4 Oct 2011 16:52:42 -0400
Received: from d01ml255.pok.ibm.com (d01ml255.pok.ibm.com [9.63.10.54]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p94Kqglw002729 for <oauth@ietf.org>; Tue, 4 Oct 2011 16:52:42 -0400
To: OAuth Mailing List <oauth@ietf.org>
MIME-Version: 1.0
X-KeepSent: 7AFAAB2C:12365054-8525791F:00716C91; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: <OF7AFAAB2C.12365054-ON8525791F.00716C91-8525791F.0072B001@us.ibm.com>
From: Todd W Lainhart <lainhart@us.ibm.com>
Date: Tue, 04 Oct 2011 16:52:41 -0400
X-MIMETrack: Serialize by Router on D01ML255/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF11|June 14, 2011) at 10/04/2011 16:52:42, Serialize complete at 10/04/2011 16:52:42
Content-Type: text/plain; charset="US-ASCII"
Subject: [OAUTH-WG] Seeking clarity on Section 4.3 and the specification of client credentials
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: Tue, 04 Oct 2011 20:49:39 -0000
Although it seems like an abuse of the protocol, I'm wondering at Draft 22
as a mechanism for providing authorization without specifying client
credentials (i.e. evaluating it as part of an SSO solution).
Specifically, I'm referencing the scenario/flow in Section 4.3 ("Resource
Owner Password Credentials") where a callback_uri parameter is not
specified. Assume that the client type is "public".
I'm also referencing Section 2.4, "Unregistered Clients", where the text
says that the spec does not exclude the use of unregistered clients (with
the appropriate disclaimers).
Under these conditions then, can I then expect a spec-compliant
authorization server to not require client credentials when requesting an
access token?
-- Todd
- [OAUTH-WG] Seeking clarity on Section 4.3 and the… Todd W Lainhart
- Re: [OAUTH-WG] Seeking clarity on Section 4.3 and… Eran Hammer