Re: [OAUTH-WG] Adding machine readable errors to SPOP?

Bill Mills <> Fri, 14 November 2014 20:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C88511AC405 for <>; Fri, 14 Nov 2014 12:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bv4twoAouj4h for <>; Fri, 14 Nov 2014 12:54:47 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8369C1AC412 for <>; Fri, 14 Nov 2014 12:54:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1415998486; bh=XnF7atv4JPcPRmMEGY6zkzZtgOUH9UHJc/+8gAYGaHk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=uIXIRmdbktaIiUj24C62s7VCfNXZ8H0foAkf79waFZnl6XeI34SkAIfoG2YV3hNpNkp+QsLiGl88IyMLfJO/vcNgS8/iQ+0kvHbW/XIw4ymztVQI/5Ebn/Taz2/D1QVRUirsRNi5Fn5HjkwrggrdQJ5ae+LvETejY14eYgyNvfgN3BQ7GY+zv7GkbK/Qyzuigh6SPZ8p6ztoB7MpAxDHephs86n1XQ1qOPCF5W1vpx2JIeMCSAkOnoq85OgYyPSz+dV4NCvzwAAAPdydmutivntsFZqKxgGfCbGLWLKUdUohNQvnwNn/yC0G8lK7VwSbvqNmENrMqzn0RSv0cJfDgA==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048;; b=qP9p2RESnY9Y+gRhRf8WCi0sZ7WKF4QdIwnuToJXkUftbnYFM0xwS0G66FEvlw2CTW088A1mtp9O0xP/6MKJ0FqBQ/J5PO8VQUIkE2MiTFrZLPB0WYlKUTr1cDEGWc1i8eYMd8g9QhSjsUDYzjYF00MiqIXANOIRl5MTGSHujpkIkp7Tz0OvDZ1+aXnNayvpXT4rYlFC7hr8DS5Sk5vKbvf/VFluxdjEv0iO6Wjuvwn4mvWsXAMGJLGVhIGTRA/BtFpSlZi9DOX3z64XsE+xnrV/d+zcUKZbtTcnWYFWRaNo6D5FE829HuXG2OXm9Q0QIrCk4VrCnKSDWH4jjQt4Uw==;
Received: from [] by with NNFMP; 14 Nov 2014 20:54:46 -0000
Received: from [] by with NNFMP; 14 Nov 2014 20:54:46 -0000
Received: from [] by with NNFMP; 14 Nov 2014 20:54:46 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: .t9zZHgVM1m5Ec_6fY7fQXKuZP6zIK.qT3HY5TsoId4_NFiKfwP3ZSIYVLOcZc0 YdBUaq.u1aOzeTEZAQAi80gJO2jFlHqq3hPCO4BXzDDoaULn_fUDhsFrzDLr97NRAaxkLKyO8e5J ySUah6i59FtgB_Io_SILY1tBFIOiH3JuXY6WHUSkxFbGDwFFz9gmHMMmFDt0Z5z32BX.q0m6Oq2w HS_INXmUHT.isobh9za7Q3sx_Sm3V.zzCruc.E56RBoPc3M1HULq1fzD_EYRFkd7PSkH7lHiJqxA .gD7mLweU1QVXga_KGPF0J_Q1D1naKUImU0NoVWWzUfq5YH3zjL4rrn8Zyv236mXN31rKizUZj2e 9AUUMTx3GWgWEzeTugnq_Y7PEm5K_MQ3lpqyFVKvMpJXsK9J1R5iFD46FIR_1GDewxKNkHRA.OW_ E.E6WbnpUj67uWav53MaoYeS42Ef29Y5xk_Z6.zGMU5Ri7OzLMIkZCQvn6KLa_99obQxrD9Mx
Received: by; Fri, 14 Nov 2014 20:54:45 +0000
Date: Fri, 14 Nov 2014 20:54:44 +0000
From: Bill Mills <>
To: Nat Sakimura <>, John Bradley <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_721576_1895460959.1415998484812"
Cc: oauth <>
Subject: Re: [OAUTH-WG] Adding machine readable errors to SPOP?
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Nov 2014 20:54:50 -0000

I sent some feedback on that section in a different message on list. 

     On Friday, November 14, 2014 12:41 PM, Nat Sakimura <> wrote:

 That pretty much was the conclusion we reached. I believe that it was what the F2F room inclined to. So, for -04, we added a section on error response but it doesn't have those granular errors. 
On Fri, Nov 14, 2014 at 07:07 John Bradley <> wrote:

<hatoff> Nat and I discussed it yesterday and I am still personally unconvinced that the errors from the authorization endpoint are helpful.   So I am personally against adding specific errors for S256_unsupported </hatoff>
On Nov 14, 2014, at 6:52 AM, Nat Sakimura <> wrote:

<editorhatoff>I find not much, if any. </editorhatoff >

On Fri, Nov 14, 2014 at 06:27 Brian Campbell <> wrote:

I struggle to see the value in adding more fine grained machine readable error messages for this. 

Do we really want clients to try and negotiate the code_challenge_method using browser redirects? Especially in light of the fact that we'll likely also be discouraging AS's from redirecting on some error conditions when there's no user interaction. 

On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura <> wrote:

As discussed at F2F today at IETF 91 OAuth WG, there has been some request to have a more fine grained machine readable error messages. 
Currently, it only returns the error defined in RFC6749 and any more details is supposed to be returned in error_descripton and error_uri. 
So, I came up with the following proposal. If WG agrees, I would put text embodying it into the draft-04. Otherwise, I would like to go as is. You have to speak out to put it in. (I am sending out -03, which we meant to send before submit freeze, without it..) 
nErrorresponse to authorization requestlReturns invalid_request withadditional error param spop_error with the following values: ▪S256_unsupported▪none_unsupported▪invalid_code_challengeClientsMUST NOT accept the downgrade request throughthis as it may be a downgrade attack by a MITM. nErrorresponse to token requestlReturns invalid_request withadditional error param spop_error with the following values: ▪invalid _code_verifier▪verifier_challenge_mismatchnAuthorizationserver should return more descriptive information on lerror_descriptionlerror_uri

OAuth mailing list

OAuth mailing list

OAuth mailing list