Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

Amos Jeffries <squid3@treenet.co.nz> Wed, 13 June 2012 22:53 UTC

Return-Path: <squid3@treenet.co.nz>
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 7533611E80B8 for <oauth@ietfa.amsl.com>; Wed, 13 Jun 2012 15:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.388
X-Spam-Level:
X-Spam-Status: No, score=-4.388 tagged_above=-999 required=5 tests=[AWL=-3.726, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172]
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 G+bU5DnIdINn for <oauth@ietfa.amsl.com>; Wed, 13 Jun 2012 15:53:16 -0700 (PDT)
Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id E948011E80B0 for <oauth@ietf.org>; Wed, 13 Jun 2012 15:53:15 -0700 (PDT)
Received: by treenet.co.nz (Postfix, from userid 33) id 2B717E6F33; Thu, 14 Jun 2012 10:53:13 +1200 (NZST)
To: oauth@ietf.org
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Thu, 14 Jun 2012 10:53:12 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
In-Reply-To: <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com>
References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com>
Message-ID: <a55ad34e52e0f9755e548106d27c4b8c@treenet.co.nz>
X-Sender: squid3@treenet.co.nz
User-Agent: Roundcube Webmail/0.7.2
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions
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: Wed, 13 Jun 2012 22:53:16 -0000

On 14.06.2012 06:40, John Bradley wrote:
> That would probably work as well.  That is why I am not particularly
> concerned about excluding the :
>
> We originally used the URI itself,  mostly for convenience of
> debugging,  but there are other potential options.
>
> The authorization server needs to compare the client_id and the
> redirect uri. But it could compare the hash with not much more work.
> Also a sha256 hash is probably longer than the uri it is hashing.
>
> I am not super concerned with being able to have : in the client_id
>
> John B.
>


If I'm following all these threads correctly the only explicit problem 
with URI in client_id is HTTP username field being : terminated.
As such it does not have to be a hash per-se, just an encoding that 
removes ":" and other reserved characters from the on-wire form *when 
sent via HTTP*.

AYJ