Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?

Julian Reschke <> Sun, 01 January 2012 19:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A58721F0C47 for <>; Sun, 1 Jan 2012 11:49:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.739
X-Spam-Status: No, score=-103.739 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1gTlQlEvp6RO for <>; Sun, 1 Jan 2012 11:49:28 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id B8CEB1F0C36 for <>; Sun, 1 Jan 2012 11:49:27 -0800 (PST)
Received: (qmail invoked by alias); 01 Jan 2012 19:49:26 -0000
Received: from (EHLO []) [] by (mp028) with SMTP; 01 Jan 2012 20:49:26 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/mav4r3TPmQheJw00Y6ZD/aX3U7t/bWQkCSn7Jda bkdt1tRQudvcSV
Message-ID: <>
Date: Sun, 01 Jan 2012 20:49:18 +0100
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Mike Jones <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Mark Nottingham <>, Barry Leiba <>, OAuth WG <>
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Jan 2012 19:49:28 -0000

On 2012-01-01 20:41, Mike Jones wrote:
> I'll note that in some profiles, the Bearer challenge may be the only one that the application may legally use.  In that case, there's no need to be able parse other challenges that the application can't fulfill in the first place.  The application would fail if an unsupported challenge type was used in either case.

The ability to send multiple challenges with the recipient taking the 
strongest one it supports is an important part of HTTP auth. I'd like to 
understand what scenario would disable that.

> As editor, I'll note that it doesn't seem like this discussion is moving the process forward anymore.  I believe that we've sufficiently clarified that you hold a different position than the working group consensus (which I realize is your right to do).  I also believe that the issues have been sufficiently well discussed on the list for all parties to be well informed.

For completeness, I'll repeat that I don't think that there was WG 
consensus for your point of view, but I'll leave it to the chairs to 
decide how to proceed.

> Therefore, it seems that my earlier observation still holds:  In the New Year, the chairs and area directors (and possibly the OAuth design committee) will need to decide how to proceed on this issue.  It would be good to see the spec finished shortly.

Yes, it would. I still have no idea what's keeping you from doing what 
HTTPbis recommends. It would be extremely helpful to get *technical* 
feedback on that (so far I haven't seen any).

Best regards, Julian