[OAUTH-WG] Separation of parameters and bindings (was: Alternative ways to pass Authorization Request Parameters)

Nat Sakimura <sakimura@gmail.com> Tue, 27 July 2010 05:34 UTC

Return-Path: <sakimura@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 D49123A6841 for <oauth@core3.amsl.com>; Mon, 26 Jul 2010 22:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 Aw8uLDxH-wTC for <oauth@core3.amsl.com>; Mon, 26 Jul 2010 22:34:36 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4ED553A685F for <oauth@ietf.org>; Mon, 26 Jul 2010 22:34:33 -0700 (PDT)
Received: by iwn38 with SMTP id 38so3684869iwn.31 for <oauth@ietf.org>; Mon, 26 Jul 2010 22:34:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=fS6AoCMulpwf54RWnX62Ppa9plxYxuARHrhKoHeHSuU=; b=tQBz2GE1aotPwze6QOWlIfktq9OrlnypLx6Z1kjamL5dbMTihRYI3cUUueC3uOvE7p QzZ1MjBS4fgjKIIJep7DcDaT2PHN1yxFgTxjTcGN6gzTtZP2HhRkpVDFJjAK/0CJrTvc wzaD83835Bv2/x+tjRj+9/5L2p1ZMCkoNbxnc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=aaSPieisSu7ZiN/92N/KQZKYkpgwOCOd+HWHLPTarPHRwMP5zQo+ciP4bEK/b5s1qa XlhlD3O+Qu44ImbsIN4GITLlRwYSmBXTmuGHxLV0wZU5QSBkaSJ00MsYRknpzp2aq78P 8lBykQDmQ1WgqOq0vhIF3wWJ4JqQR/7fk5R+8=
MIME-Version: 1.0
Received: by 10.231.170.21 with SMTP id b21mr3771931ibz.122.1280208890018; Mon, 26 Jul 2010 22:34:50 -0700 (PDT)
Received: by 10.231.158.67 with HTTP; Mon, 26 Jul 2010 22:34:49 -0700 (PDT)
Date: Tue, 27 Jul 2010 14:34:49 +0900
Message-ID: <AANLkTikyVUg_ycfFqrFvyAqDGzAqAj2am55PGQc9R7qD@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: David Recordon <recordond@gmail.com>, oauth <oauth@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [OAUTH-WG] Separation of parameters and bindings (was: Alternative ways to pass Authorization Request Parameters)
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: Tue, 27 Jul 2010 05:34:41 -0000

Hi David,

Good to see you on Saturday.

This is what I was referring to over the lunch.
Separate endpoint still does not seem to meet the current section 3.

=nat


---------- Forwarded message ----------
From: Nat Sakimura <sakimura@gmail.com>
Date: Tue, Jul 13, 2010 at 11:51 AM
Subject: Alternative ways to pass Authorization Request Parameters
To: oauth <oauth@ietf.org>


As of -10, the Authorization Request Parameters are required to be
passed as part of the Authorization Request URI query component.

I would like to see it relaxed a bit so that they do not have to be a
part of the URL but can be passed by reference.

In the proposal that I have submit a while ago, I proposed to have

1) The parameters to be captured in JSON that can be obtained through a URL
2) Pass this URL to the end-user authorization endpoint through a
parameter 'request_url'

I have enumerated numerous merit of this approach and I believe we had
an agreement that this would be useful from both security and
usability perspective.

However, as the current text is written, the parameters have to be
sent as URI query component.

In -10, it is written as:

  In order to direct the end-user's user-agent to the authorization
  server, the client constructs the request URI by adding the following
  parameters to the end-user authorization endpoint URI query component
  using the "application/x-www-form-urlencoded" format as defined by
  [W3C.REC-html401-19991224]:

    (parm defs)

  The client directs the end-user to the constructed URI using an HTTP
  redirection response, or by other means available to it via the end-
  user's user-agent.  The authorization server MUST support the use of
  the HTTP "GET" method for the end-user authorization endpoint, and
  MAY support the use of the "POST" method as well.

Instead I would propose something like:

  In order to obtain the end-user's authorization, the client sends the
  following parameters to the end-user authorization endpoint.

   (param defs)

  The client directs the end-user to the end-user authorization endpoint
  URI using an HTTP redirection response, or by other means available to
  it via the end-user's user-agent. The authorization server MUST
support the use of
  the HTTP "GET" method for the end-user authorization endpoint, and
  MAY support the use of the "POST" method as well. The authorization
  server MUST support the parameters being passed as the query component
  using the "application/x-www-form-urlencoded" format as defined by
  [W3C.REC-html401-19991224].


I also have a comment on the structure of the section 3.
I should have noticed this much earlier but currently the section 3 is
structured as:

3.  Obtaining End-User Authorization
    3.1.  Authorization Response
    3.2.  Error Response

Would it not be better to be something like below?

3.  Obtaining End-User Authorization
    3.1. Authorization Request
    3.2. Authorization Response
    3.3.  Error Response

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en