Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt

Brian Campbell <> Thu, 21 June 2012 20:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4854C21F85A1 for <>; Thu, 21 Jun 2012 13:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[AWL=1.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fN3kDYDN4G1G for <>; Thu, 21 Jun 2012 13:49:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 070C421F859F for <>; Thu, 21 Jun 2012 13:49:11 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKT+OIxyN7vRzEsaBh8jZY8yGZ8MJ/; Thu, 21 Jun 2012 13:49:12 PDT
Received: by qcsp15 with SMTP id p15so993842qcs.16 for <>; Thu, 21 Jun 2012 13:49:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=oOBdtv6sg6cxC8irT4ebqBNK1GEEbpJwNxSYcnDED68=; b=PdEMGs6g3Blj+zbCM9HXbPymVUrBr2k2pvn7H3pVUVxbrBSruo2yz9u6BvDTOk0K2+ 669KL5s3Rtoqr1Fbq5qIvLfxxmWrinYCPYd85KhIVsY/VgM+oCkQ2++8dhV6nuG13zCh nAnITJtqDbW9mLCju4PwFdKbwRr6oDm8+7DNUm7asEc1t+n+2vDjgCC2PeOp0fByN4+a yjLLbnhKNRgOHjh5iOZ5ftdgTs9EIyDVfpZF1A2O9ZthNtxFQG8L7zDAFhr53Kgcny/f CYF/L7QlYdmRe+AiEfgO6peJq3e3WlPOmEQKWmbJX0X28FY2POnUYM45UDSZtpdMNCCZ EJHw==
Received: by with SMTP id n13mr7838833qct.105.1340311750776; Thu, 21 Jun 2012 13:49:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 21 Jun 2012 13:48:39 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Brian Campbell <>
Date: Thu, 21 Jun 2012 14:48:39 -0600
Message-ID: <>
To: Hannes Tschofenig <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQn6LH/TsQS1DlBrcVWSHSjZ6vfu0KQMz93kN4cMJ4Blu7vV9VLT1Imp+4+5PD/SmXbVcQR6
Cc: "" <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt
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: Thu, 21 Jun 2012 20:49:13 -0000

On Thu, Jun 21, 2012 at 1:48 PM, Hannes Tschofenig
<> wrote:
> Btw, in a discussion with Brian we check the policies for the three extensions in the OAuth core specification
> 1) Section 8.3.  Defining New Authorization Grant Types
> If you don't define additional token endpoint parameters then there is actually no requirement for expert review or a specification.
> It is probably FCFS.

That raises a different question/issue.

My understanding of the core spec was that it used URIs in extension
points that might be profiled by actual specifications as well as by
vendor-specific or other less rigorous implementations.

To the extent that's true, §8.3 of OAuth core[1] is problematic in
that it allows for any URI defining the grant type but requires
additional parameters the grant type might use to be registered in the
The OAuth Parameters Registry (and new grant types will most likely
need additional parameters).

Inf 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]. At the time I was thinking
the parameter was implicitly qualified by the grant type and this was
all okay. But looking at it again, per the letter of the spec, this
would seem to be a violation. But what should we have done? How does a
vendor-specific extension go about registering a parameter? Would that
even be a good idea?