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

Brian Campbell <> Fri, 26 August 2011 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F8DA21F8C39 for <>; Fri, 26 Aug 2011 11:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.909
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nTTR0gMgXEDY for <>; Fri, 26 Aug 2011 11:24:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0E6F121F8B5E for <>; Fri, 26 Aug 2011 11:24:06 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Fri, 26 Aug 2011 11:25:24 PDT
Received: by with SMTP id 3so3042537qwk.33 for <>; Fri, 26 Aug 2011 11:25:22 -0700 (PDT)
Received: by with SMTP id b3mr1869808qcc.290.1314383122071; Fri, 26 Aug 2011 11:25:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 26 Aug 2011 11:24:52 -0700 (PDT)
In-Reply-To: <>
References: <AcxXpfuhAGBqMyEFSg+Pg2ZI+qDJdg==> <>
From: Brian Campbell <>
Date: Fri, 26 Aug 2011 12:24:52 -0600
Message-ID: <>
To: Mike Jones <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [OAUTH-WG] Comments on Assertions draft 00 by Yaron Goland
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: 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 <> 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.