Re: [Ace] [OAUTH-WG] Resource, Audience, and req_aud

Brian Campbell <bcampbell@pingidentity.com> Mon, 11 February 2019 13:07 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E317C12008A for <ace@ietfa.amsl.com>; Mon, 11 Feb 2019 05:07:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WyNI3qHKHFI for <ace@ietfa.amsl.com>; Mon, 11 Feb 2019 05:07:31 -0800 (PST)
Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D011286D8 for <ace@ietf.org>; Mon, 11 Feb 2019 05:07:31 -0800 (PST)
Received: by mail-it1-x12c.google.com with SMTP id c9so26009005itj.1 for <ace@ietf.org>; Mon, 11 Feb 2019 05:07:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QJ2GrJjjYSfM9gElfYNOVxVZ+ew9YkHHvxBFwZOKeJM=; b=kTj3SWb2alxG3jWwKh55yxaSAh3pXnOdrSDqgT1Wm306RKUqUOH0LWVSmowEwTzFu8 uPMgeceq3fznPlziBhSX7dkHKXi6gsGhbcWyfkE1Wn+gb5AaPRlEMJLfMvcVd5G28OyG ezBcZ7TwdwNy8EdwwRmhoU7FbaO2AanqTcLuM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QJ2GrJjjYSfM9gElfYNOVxVZ+ew9YkHHvxBFwZOKeJM=; b=DEdqmQFrQxIqzTJFJZViO2B+zKzrGpjckX5Voc9h9ZFnkhlL7nl1f+n9jWBby9Qvxs qLuZUexpq+R0YKxjyhZVzATb8CbCMB5g+3NFd7zlJ+b7ZITx84HHOcxAid1Twh//f7rw tdSEFnACA1aOv3HRUTMr4E0do0RXStuCvII/K6XAzy6hFglQLlz9hKqkfl0p+/w9vS4Y SevbEhv5flG1Ph3ODuDw4xwF2ucc3Diik7zzDvN88dlFbRy4ldokVxjnhdQBNTIyzUIp IIi0ArBwhOBWMJbcWaxtKjsubuZeK1frBDJDor6KA3d1NskvYslYV8QiEcg9g6Y/38RC YrXA==
X-Gm-Message-State: AHQUAuYcj36lYUbb2lyLCqGJkbaC2lPoVRl2+gR/LXkU+/JxOXPqjkJi KZrbMUL9KStyUx2oTVFW5a+PFZT59TqiHuSssNL6xEOCKTq18p0C6yA5clChXxxU+HjRnxqiQmy 8NQcSV7w6mhk=
X-Google-Smtp-Source: AHgI3IZCQpgnXp7rvLmyh4G0Se8WPqy7hLzv2vUsGxE3q6v3kHILeBV9eP8gL7Hh8ivdRSspBxKFwfQzaqaDRoKpKn4=
X-Received: by 2002:a02:946e:: with SMTP id a101mr19058985jai.90.1549890450117; Mon, 11 Feb 2019 05:07:30 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR0801MB21126944E558E53992EB7FD3FA680@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CALAqi_9YUWBcUWtaG2g=mXQLJoq1X=dgm72exDU9akqxuhK_HQ@mail.gmail.com> <CA+k3eCQtPXQaY1E9t6CmQh8eb2kUeFxvsj1WLeY8Yfhpzpkm9Q@mail.gmail.com> <20190209223132.GB23225@kduck.mit.edu>
In-Reply-To: <20190209223132.GB23225@kduck.mit.edu>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 11 Feb 2019 06:07:03 -0700
Message-ID: <CA+k3eCTXZvKMsg=ft_0L19qdiF_COah2NVAYkEgByjPNxEBvOQ@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Filip Skokan <panva.ip@gmail.com>, Eric Rescorla <ekr@rtfm.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "oauth@ietf.org" <oauth@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b8768b05819dfd41"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/36vku5P5fWu-bDH5s4tFScwdWlk>
Subject: Re: [Ace] [OAUTH-WG] Resource, Audience, and req_aud
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 13:07:34 -0000

Right, I was just trying to recount what had happened and say that it was
my understanding that the URI registrations were the ones you'd expressed
concern with and moved to early registration while the topic of this thread
was about parameter names. I guess it doesn't really matter but it seemed
like a distinction worth making when I wrote that last week.

On Sat, Feb 9, 2019 at 3:31 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> On Thu, Feb 07, 2019 at 02:28:02PM -0700, Brian Campbell wrote:
> >
> > The token-exchange draft defines both the "resource" and "audience"
> > parameters for use in the context of a
> > "urn:ietf:params:oauth:grant-type:token-exchange" grant type request to
> the
> > token endpoint. There is a lot of overlap between "resource" and
> "audience"
> > and I'm not sure there was necessarily a good reason to have the two but
> it
> > just kind of unfolded that way (the use of a client ID as an audience is
> > one case that's mentioned that isn't a URI).  That document is in IESG
> > evaluation (which is towards the end of the RFC process) and had a few
> > DISCUSS ballot positions raised against it. Resulting from one of those
> > DISCUSSes, which was unrelated to "resource"/"audience" but rather
> because
> > of the OAuth URIs as far as I understand, one of the IESG members steered
> > us in the direction of, and facilitated, the early registration requests.
>
> That was me.  The conclusion to go for early registration was not (AFAICT)
> out of a desire to get the actual value registered more quickly than it
> would have been otherwise (which should be pretty fast, since IANA
> generally makes the live registries reflect changes shortly after IESG
> approval, not even waiting for AUTH48 or final RFC publication), but just
> from it seeming to be the least-effort way to approve and publish the
> document while still following the required process.  (Basically, the I-D
> sent to the IESG was "codepoint squatting", having text in the document
> that claims that a specific URI value will be used, but with no guarantee
> from IANA that that specific value will end up being the one registered.
> I didn't think the IESG should grant its seal of approval to a document
> that was jumping the process in that way, and the other options we could
> think of would require fairly invasive changes to the text that would
> just have to be undone by the RFC Editor.)
>
> -Ben
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._