Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2)

Eran Hammer-Lahav <eran@hueniverse.com> Tue, 22 September 2009 00:14 UTC

Return-Path: <eran@hueniverse.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 E81153A6805 for <oauth@core3.amsl.com>; Mon, 21 Sep 2009 17:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.085
X-Spam-Level:
X-Spam-Status: No, score=-4.085 tagged_above=-999 required=5 tests=[AWL=-1.486, 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 DZFfsuPZAzAA for <oauth@core3.amsl.com>; Mon, 21 Sep 2009 17:14:51 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BEAD03A67C2 for <oauth@ietf.org>; Mon, 21 Sep 2009 17:14:51 -0700 (PDT)
Received: (qmail 8033 invoked from network); 22 Sep 2009 00:15:52 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Sep 2009 00:15:51 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 21 Sep 2009 17:13:36 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Chirag Shah <chiragshah1@gmail.com>, Hubert Le Van Gong <hubertlvg@gmail.com>
Date: Mon, 21 Sep 2009 17:15:19 -0700
Thread-Topic: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2)
Thread-Index: Aco7GG2FH9NdrF2rQHebJeF/HA1kygAAPcCA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D584E8@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <74462b20909211450kf19596eg2df35e13f4836c2d@mail.gmail.com> <6c0fd2bc0909211459t647d0006s728b2630966cf603@mail.gmail.com> <74462b20909211705s78ed9895je7d00411bb6e2a80@mail.gmail.com>
In-Reply-To: <74462b20909211705s78ed9895je7d00411bb6e2a80@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2)
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, 22 Sep 2009 00:14:53 -0000

I think we need to clean up the problem reporting proposal and separate between codes that help debug and codes that call for an action. All the errors which cannot be handled automatically by an application should be just marked as fail. The specifics of such fail are only useful for human debugging and while valuable, should be part of exactly that - debugging capabilities.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Chirag Shah
> Sent: Monday, September 21, 2009 5:06 PM
> To: Hubert Le Van Gong
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due
> 10/2)
> 
> Isn't the purpose of the Problem Reporting extension is to help
> developers debug OAuth issues?
> 
> Currently the text "signature_invalid" isn't very meaningful to
> developers debugging their applications because they want to know the
> exact reason why.
> 
> 
> On Mon, Sep 21, 2009 at 2:59 PM, Hubert Le Van Gong
> <hubertlvg@gmail.com> wrote:
> > I "hear your pain" but I'm not sure this is a good idea.
> > What you describe sounds more like debugging to me.
> > Not something I'd put in the protocol msgs.
> >
> > Hubert
> >
> >
> > On Mon, Sep 21, 2009 at 11:50 PM, Chirag Shah <chiragshah1@gmail.com>
> wrote:
> >>> * The proposed Problem Reporting extension [1], its richness and
> complexity
> >>
> >> I was curious if we could slightly update to the proposed problem
> >> reporting extension.
> >>
> >> The signature_invalid section in the Problem Reporting extension[1]
> >> should encourage service providers to include the
> >> signature_base_string they used in the error response.
> >>
> >> This information is valuable because the consumer can visually
> >> identify why their signature is invalid by comparing their
> >> signature_base string against the service provider's. If the service
> >> provider does not provide this information, the consumer is often
> >> guessing why their signature is invalid.
> >>
> >> [1] - http://wiki.oauth.net/ProblemReporting
> >>
> >> On Mon, Sep 21, 2009 at 1:40 PM, Eran Hammer-Lahav
> <eran@hueniverse.com> wrote:
> >>> http://tools.ietf.org/html/draft-ietf-oauth-authentication
> >>> http://tools.ietf.org/html/draft-ietf-oauth-web-delegation
> >>>
> >>> I plan to publish new revisions of the above drafts to include:
> >>>
> >>> * Error codes and optional debug information
> >>> * Cleanup of the authentication extensibility model
> >>> * Change the version / protocol extensibility model
> >>>
> >>> In addition to general feedback about the drafts, I am looking for
> specific feedback on the following items which I plan to address in the
> next drafts:
> >>>
> >>> * Drop core support for the RSA-SHA1 method
> >>> * Replace HMAC-SHA1 with HMAC-SHA256
> >>> * Define the authentication parameters as method-specific (for
> example, drop nonce and timestamp from PLAINTEXT)
> >>> * The proposed Problem Reporting extension [1], its richness and
> complexity
> >>> * Making the HMAC signature method required for all server
> implementations
> >>> * Changing the delegation flow to require HTTP POST instead of
> recommending it
> >>> * Mandating server support for all three parameter transmission
> methods
> >>> * Adding a token revocation endpoint
> >>> * Adding the ability for servers to declare their configuration
> (methods, etc.) in the WWW-Authenticate header response
> >>> * The value of the client credentials (Consumer Key) and feedback
> from actual implementation experience
> >>>
> >>> In order for your feedback to be included or considered for the
> next revisions it must be received by 10/2 on the oauth@ietf.org list.
> >>>
> >>> EHL
> >>>
> >>> [1] http://wiki.oauth.net/ProblemReporting
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth