Re: [OAUTH-WG] Comments on Assertions draft 00 by Yaron Goland

Brian Campbell <bcampbell@pingidentity.com> Fri, 26 August 2011 18:24 UTC

Return-Path: <bcampbell@pingidentity.com>
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 2F8DA21F8C39 for <oauth@ietfa.amsl.com>; Fri, 26 Aug 2011 11:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.909
X-Spam-Level:
X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
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 nTTR0gMgXEDY for <oauth@ietfa.amsl.com>; Fri, 26 Aug 2011 11:24:08 -0700 (PDT)
Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F121F8B5E for <oauth@ietf.org>; Fri, 26 Aug 2011 11:24:06 -0700 (PDT)
Received: from mail-qw0-f46.google.com ([209.85.216.46]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKTlflEnU9uyCmhG5dShSavKqiIU4+GtKT@postini.com; Fri, 26 Aug 2011 11:25:24 PDT
Received: by mail-qw0-f46.google.com with SMTP id 3so3042537qwk.33 for <oauth@ietf.org>; Fri, 26 Aug 2011 11:25:22 -0700 (PDT)
Received: by 10.229.26.3 with SMTP id b3mr1869808qcc.290.1314383122071; Fri, 26 Aug 2011 11:25:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.53.207 with HTTP; Fri, 26 Aug 2011 11:24:52 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739434A80B5D4@TK5EX14MBXC201.redmond.corp.microsoft.com>
References: <AcxXpfuhAGBqMyEFSg+Pg2ZI+qDJdg==> <4E1F6AAD24975D4BA5B16804296739434A80B5D4@TK5EX14MBXC201.redmond.corp.microsoft.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 26 Aug 2011 12:24:52 -0600
Message-ID: <CA+k3eCSEogbiTCGGQyCEp6wQeN_gW56mZ0JEtaHgQ2PxF0T7bg@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Comments on Assertions draft 00 by Yaron Goland
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: Fri, 26 Aug 2011 18:24:09 -0000

Couple comments on the comments inline:

On Wed, Aug 10, 2011 at 3:39 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>
> 4.1. Using Assertions for Client Authentication:  Comment on “client_id”:
> “It seems like a bad idea to have the client_id outside of the assertion.
> It’s either redundant or insecure.”
>

I tend to agree with this.  Now that treatment of client_id seems to
have stabilized in the core spec, this draft is probable due for some
reconciliatory changes around the parameter.


>
> 7.  Error Responses:  Comment on “Audience validation failed”: “Isn’t
> returning this kind of information just helping an attacker to hone their
> attack by trying various values and seeing what errors they get? I’m not
> sure how serious this threat is though. But I get nervous any time we leak
> data about security validation failures.”

Trying to walk the line between security and having useful feedback
available for troubleshooting during the early stages of deployments.
Given that there's a signature over the assertion, providing details
about other semantic validation issues doesn't seem like an issue to
me.  But I know that such information disclosure is usually considered
a no no in security related contexts.  Anyway, the error_description
parameter is optional so individual implementation/deployments can
make their own decisions about what, if anything, to put there and/or
when to put info there.