Re: [OAUTH-WG] WGLC on Assertion Drafts

Brian Campbell <bcampbell@pingidentity.com> Thu, 12 April 2012 22:14 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 BD0A921F8755 for <oauth@ietfa.amsl.com>; Thu, 12 Apr 2012 15:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.95
X-Spam-Level:
X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.028, 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 cIpC8SfzGPpq for <oauth@ietfa.amsl.com>; Thu, 12 Apr 2012 15:14:53 -0700 (PDT)
Received: from psmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) by ietfa.amsl.com (Postfix) with ESMTP id E0E6C21F875B for <oauth@ietf.org>; Thu, 12 Apr 2012 15:14:52 -0700 (PDT)
Received: from mail-vx0-f181.google.com ([209.85.220.181]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKT4dT3F+IuebNQnz2zoYpBZAvQMYIM1Gq@postini.com; Thu, 12 Apr 2012 15:14:52 PDT
Received: by vcge1 with SMTP id e1so2014163vcg.26 for <oauth@ietf.org>; Thu, 12 Apr 2012 15:14:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=SVEi5LIFyeJMScU2TKNk+2+tYIvLTupdhTEwQcDe8IA=; b=iMYbpQfKiLfrDwEBjP0ZaRQqfKqlaNeMgZ4u9zSei04wTkTjQVIrOlk17L0WHTwco9 +vw52/dUa6xi3BidQBTejYGiT1yIdOdo4FptbVZCM2f8CnW7EVmiNvEdfcVKt4wpkElW JyyzqevO/NqoU+VxEH6KBRPBdtWVYca3qTBh1uo2Ze3FOcznqho+f1Anrl1nRDzbbjn5 2nwsnNuQJ4XMuLHF+CL4BZBZibtEjNxNTlRuyyC8nKkHGWdNjM5aY2WYPey4UNPHfAD7 iJ9yaUliHIlzT6zeIL/qVj2zUykSBiCrPeLDFwNFna1+xJBKFz2zo7mAlxWa/qiRZbk1 eX9Q==
Received: by 10.52.65.170 with SMTP id y10mr1717703vds.48.1334268891484; Thu, 12 Apr 2012 15:14:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.38.104 with HTTP; Thu, 12 Apr 2012 15:14:21 -0700 (PDT)
In-Reply-To: <4F7DCE03.3020009@mitre.org>
References: <999913AB42CC9341B05A99BBF358718D014D5CD1@FIESEXC035.nsn-intra.net> <4F7DCE03.3020009@mitre.org>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 12 Apr 2012 16:14:21 -0600
Message-ID: <CA+k3eCSTFuPoswQ=e6NQyJtyF4DB=21YG4zy8KFv4iemxSDhhQ@mail.gmail.com>
To: Justin Richer <jricher@mitre.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQndcb4bo1AJ1AZzNFKO8MUfYqjkq1hdyg7/z1/q826O/RQnVJ72VfHRxMasecdRIz82j5Q6
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC on Assertion Drafts
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: Thu, 12 Apr 2012 22:14:53 -0000

Thanks Justin, a couple comments/questions are inline...

On Thu, Apr 5, 2012 at 10:53 AM, Justin Richer <jricher@mitre.org> wrote:
>
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-01
>
>
> Section 7's second portion about a client including multiple credentials
> types seems buried down here in the Error Responses section for something
> this fundamental.

Yeah, I can see that. Although the restriction on multiple client
authentication methods is actually inherited from core OAuth (last
sentence in http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.3)
so maybe there shouldn't even normative language about it in this doc?

> It also conflates discussion of selection of this client
> authorization type in here, where it ought to be in its own section, closer
> to the top.

I'm not sure I follow you here? As I re-read §7 I think it might make
sense to break it into two pieces, one on grants and one on client
auth.  Maybe a 7.1 and a 7.2 or maybe subsections of §4, like a §4.1.1
for client authentication errors and §4.2.1 for authz/grant errors.
But I don't think that was what your comment was about?

Was your comment that this text should live somewhere else?
  "Token endpoints can differentiate between assertion based
   credentials and other client credential types by looking for the
   presence of the client_assertion and client_assertion_type attributes
   which will only be present when using assertions for client
   authentication."

I wouldn't disagree with you there, if that was the case.