[OAUTH-WG] issues with §8.3 grant type parameters? (was ... draft-ietf-oauth-urn-sub-ns-03.txt)

Brian Campbell <bcampbell@pingidentity.com> Fri, 22 June 2012 15:50 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 34EFE21F8767 for <oauth@ietfa.amsl.com>; Fri, 22 Jun 2012 08:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id T4zDXpnUUadW for <oauth@ietfa.amsl.com>; Fri, 22 Jun 2012 08:50:09 -0700 (PDT)
Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com []) by ietfa.amsl.com (Postfix) with ESMTP id 25F2B21F86FE for <oauth@ietf.org>; Fri, 22 Jun 2012 08:50:08 -0700 (PDT)
Received: from mail-qa0-f50.google.com ([]) (using TLSv1) by na3sys009aob109.postini.com ([]) with SMTP ID DSNKT+SUMIXbuzKgTK3rZLmglLcETenRnZs2@postini.com; Fri, 22 Jun 2012 08:50:09 PDT
Received: by qafl39 with SMTP id l39so638655qaf.16 for <oauth@ietf.org>; Fri, 22 Jun 2012 08:50:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=FX5RaRcF+oMVB6D324kcp6KHevT7//KOqAmZ/13LT7U=; b=QTt3Co10AM/3EpNIF2QJ3csfq+AuC7oCrkR+9IYOeBF2nhgjI23UR60lSbYeq3wnDD bfxq5VT0oGuwmKwVg0VaM+Dv10SRnyCCiDqwggDC26WHY50YPlqpaiddfUHKAg1etwNg AjSk2gjc7oC7tKLBG2pEKrnOEbj7+YnxancM7lqde3oHxo2dg9+oteodMZkleEQxEjVH 8V8qXLj4GZur169vJMGTzRmNHI/ofszoWR2jK17HC0R+Q4IbkuUIp6B3ylRU6snkneyD k8K0JVCzRABuzn3gsfI84vUmVyVTRW3Wjuh2K958e14T3KuQMJvhUI1SpFh4343Px3ra QuIA==
Received: by with SMTP id gq1mr7227236qab.54.1340380207739; Fri, 22 Jun 2012 08:50:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 22 Jun 2012 08:49:37 -0700 (PDT)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 22 Jun 2012 09:49:37 -0600
Message-ID: <CA+k3eCTcNtrna1jacTPuHWC_pYCqGNhiDBXFmGHHtEJ8ut2E8g@mail.gmail.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmF36Y8hDcyXFQ+3MBzvaA5jlkwtSudDGsq4vvfnupbDFelWssIp+6sh5vGACJ4cUD4EXAP
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG] issues with §8.3 grant type parameters? (was ... draft-ietf-oauth-urn-sub-ns-03.txt)
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, 22 Jun 2012 15:50:10 -0000

It was a design decision that seemed most appropriate given the
various factors and goals of my application at the time. My goal in
pointing to that was not to elicit feedback on the design itself but
to show that 'vendor-specific' extension grants will happen, and
already have happened, and that that might suggest a problem with the
text in §8.3 of the core spec. Do others see an issue here?


We can discuses the merits of the introspection as a grant type
approach if/when the WG chooses to take that on as a work item and to
the extent that approach is of interest. My colleague posted an
early/rough draft of that approach as an attachment to

On Fri, Jun 22, 2012 at 12:09 AM, Manger, James H
<James.H.Manger@team.telstra.com> wrote:
>> In fact, I've already got a vendor-specific grant type that uses an
>> unregistered parameter on the token endpoint - it's a simple grant
>> type for access token introspection [2].
>> [2]
>> http://documentation.pingidentity.com/display/PF66/Grant+Type+Parameter
>> s#GrantTypeParameters-1079271
> Why are you trying to overload this new functionality onto a URI used for other purposes?
> Why not just pick a URI specifically for your purpose, eg /as/validate?
> --
> James Manger