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

Brian Campbell <bcampbell@pingidentity.com> Fri, 14 November 2014 16:27 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318071A0010 for <oauth@ietfa.amsl.com>; Fri, 14 Nov 2014 08:27:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.318
X-Spam-Level:
X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbjKw6HBn5gZ for <oauth@ietfa.amsl.com>; Fri, 14 Nov 2014 08:27:20 -0800 (PST)
Received: from na3sys009aog137.obsmtp.com (na3sys009aog137.obsmtp.com [74.125.149.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192491A1AA6 for <oauth@ietf.org>; Fri, 14 Nov 2014 08:27:18 -0800 (PST)
Received: from mail-ig0-f179.google.com ([209.85.213.179]) (using TLSv1) by na3sys009aob137.postini.com ([74.125.148.12]) with SMTP ID DSNKVGYtX+6KEvWuzt7pBjQAx+j/YcYnzjqO@postini.com; Fri, 14 Nov 2014 08:27:19 PST
Received: by mail-ig0-f179.google.com with SMTP id r10so1755752igi.12 for <oauth@ietf.org>; Fri, 14 Nov 2014 08:27:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=i8wcriPeaFRAPmqhc+B44xAlHU4lCHxJ62bq09u3G6E=; b=evYGvBOWBeTbVizydpUD/68awSrXnsnaM1A+kGLYZy1E1ehpd2u6PDlLYKH/gTox6o WqEAlQIYn+mxhrx+I/ekbm+P3JINCzGHeMOmQYobQxS4nImkXkWo8Yrzf08dIzmRljHM c5C4VIEvzqTQZVVU7kcWGHXlwYdIgd8VOwywEb/iXVOuwDXGd7atvBBrR/DjiyrQRXWP WkTcmqWXwgM1gsxsCh2+gmjyZ/kAuNRSO7qc/x5SJXNfhZJkWNzXFleUNQ4RUzVH7gJr P/ticPX7KTt30D+rwFNBNNFyH1K/e18heRsSX8W4XzLv/lkz60iZ48uoFUbvzVEAmNoN YcSg==
X-Gm-Message-State: ALoCoQkAG+tFaRxgEyZqZ0uav0+6A1xUVY9WFchnSRL1KhNW4k59TySm5/WzId8ANLryrPDevY2gelhE/Aezd6X7U/cTsOAxm3K+44rR/OglCtqy+ZF8luxFYFspY8vbFv3v75wG/cMv
X-Received: by 10.50.39.67 with SMTP id n3mr7126655igk.43.1415982431335; Fri, 14 Nov 2014 08:27:11 -0800 (PST)
X-Received: by 10.50.39.67 with SMTP id n3mr7126634igk.43.1415982431207; Fri, 14 Nov 2014 08:27:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.28.15 with HTTP; Fri, 14 Nov 2014 08:26:41 -0800 (PST)
In-Reply-To: <CABzCy2AqUvaJSpA3sKxWp8zs+kkTnq++Kv0a81JpBor825eaKg@mail.gmail.com>
References: <CABzCy2AqUvaJSpA3sKxWp8zs+kkTnq++Kv0a81JpBor825eaKg@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 14 Nov 2014 09:26:41 -0700
Message-ID: <CA+k3eCTF=SnWP2rE7pRCe4ve_KUhZoCj+h7NhRUjjpEpXEWUVA@mail.gmail.com>
To: Nat Sakimura <sakimura@gmail.com>
Content-Type: multipart/alternative; boundary="047d7bdca67ed217d80507d419f7"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/NvbRtKDbcirHUjrfYUOAt4xccYY
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Adding machine readable errors to SPOP?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 14 Nov 2014 16:27:22 -0000

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 <sakimura@gmail.com> 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..)
>
> nError response to authorization request
> lReturns invalid_request with additional error param spop_error with the
> following values:
> ▪S256_unsupported
> ▪none_unsupported
> ▪invalid_code_challenge
>
> Clients MUST NOT accept the downgrade
>
> request through this as it may be a downgrade
>
> attack by a MITM.
> nError response to token request
> lReturns invalid_request with additional error param spop_error with the
> following values:
> ▪invalid _code_verifier
> ▪verifier_challenge_mismatch
> nAuthorization server should return more descriptive information on
> lerror_description
> lerror_uri
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>