Re: [OAUTH-WG] Éric Vyncke's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

Brian Campbell <bcampbell@pingidentity.com> Tue, 03 September 2019 19:29 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 08F1212018B for <oauth@ietfa.amsl.com>; Tue, 3 Sep 2019 12:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ltDt1Pxe2gaf for <oauth@ietfa.amsl.com>; Tue, 3 Sep 2019 12:29:03 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 E81EA120825 for <oauth@ietf.org>; Tue, 3 Sep 2019 12:29:02 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id n197so36665317iod.9 for <oauth@ietf.org>; Tue, 03 Sep 2019 12:29:02 -0700 (PDT)
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=Ax2Tm7THMNCiLbjX2AzxfXEu7vje3sGHhMfSTWHv4f0=; b=fnPrvl+aiBBidODfB/rQED1q2WeaZHmxH7C2zi+pMdBtTqRui4cnwaiwpPQAhKdlt7 2IOCyP97rE7b/m2WEShZ+OpyEKhdfHOlClnUcJZLlwdH1cp0PLk19hn5iwF4PPaByJw0 Tiz2hbWyGAQ98t8+uHLMzichnNPCuclEVNrDk=
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=Ax2Tm7THMNCiLbjX2AzxfXEu7vje3sGHhMfSTWHv4f0=; b=qCrlDXd7cFo/QLqIe3jUeghcewOSeviBcwn9kFlXepVzG5q8EbqzCKXv6U+PxvYS43 hb7wSGKsKhGN7mLMjdKeSSFtXn6j21kDgXNCQbcEgRVku2+QcJI2F1FQFZ2evxOvYRtx 5t2TOU2aFi4yrx5b9aTEr2hCzkoJcQQewYLfEakjr5/rT1PyLyhChEjU815lYY9e8rX/ wn+uNzKlHtboaVDLaVI0mJ/aX7Y8d7bAggD8O1UjNgNqzGXkm6bNIi/Zll0v7XAP3MGU n4yZvxnhPwtGy0JDTJsL0tr0ebIwhFlHFdgtFJx43cK5uXwlkebxFVgZbwRTCrc/u9sN WXVQ==
X-Gm-Message-State: APjAAAU3uIQWqR36bpLY1vA6/himGbsERjRA0kQS5mJeXigrscb3uyhJ 7hhBWvjQ7mIWkmokioc29pb3/4lWgOW3mdEb7529qOO9lbLpzD1BxkmOZUvAZai1jeE6MtN/tYg qp53zCeRhv8hIxw==
X-Google-Smtp-Source: APXvYqz6G1Zgh+EKiHXYUeYZ+Fam1k+E04O7B1SX7wXssKsHB/SrvoaWqAjwRF4PJw274J2S2HmVYKkLy7jKC9ggb4U=
X-Received: by 2002:a6b:b494:: with SMTP id d142mr238122iof.156.1567538942169; Tue, 03 Sep 2019 12:29:02 -0700 (PDT)
MIME-Version: 1.0
References: <156741723195.13041.3519982606374763447.idtracker@ietfa.amsl.com>
In-Reply-To: <156741723195.13041.3519982606374763447.idtracker@ietfa.amsl.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 3 Sep 2019 13:28:35 -0600
Message-ID: <CA+k3eCTJpyO2DOFr9NpGrE9S6QRVHTLhFJbZDhZpsODtxd2X3Q@mail.gmail.com>
To: =?UTF-8?B?w4lyaWMgVnluY2tl?= <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-oauth-resource-indicators@ietf.org, oauth <oauth@ietf.org>, oauth-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d1f3fa0591ab1998"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/QTrkrtyD0SllIF19gYuMK5kxdyY>
Subject: Re: [OAUTH-WG] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-oauth-resource-indicators-05=3A_=28with_COMMENT=29?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 03 Sep 2019 19:29:19 -0000

Thank you, Éric, for the review and ballot position.


On Mon, Sep 2, 2019 at 3:40 AM Éric Vyncke via Datatracker <noreply@ietf.org>;
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-oauth-resource-indicators-05: No Objection

----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the hard work put into this easy to read document.
>

Thanks, I'm happy to hear that you found it readable.



> == COMMENTS ==
>
> -- Section 1 --
> "has uncovered a need, in some circumstances" (and similar sentences in
> section
> 1), it is rather vague for a standard track document... Please add some
> facts
> and data, this could be a companion document about requirements/use cases.
>

Sec 1 is intended to be a general (though not vague) introduction with some
explanation about what an authorization server might be able to accomplish
with an understanding of the location/identity of the protected resource
for which the client is requesting an access token. Which effectively boils
down to being able to produce the token appropriate for the indicated
resource (including the type of token, if and how it's encrypted, what
information is contained or referenced, to whom it is audience restricted).
I've no doubt that the writing could stand to be improved (which is always
the case with content I've written) but those are the use cases and I don't
have more specific facts or data.



>
> -- Section 2 --
> It is rather a question of mine, why does the resource need to be a URI
> (which
> usually bears some visible semantics) rather than an opaque string known
> only
> by the resource owner/server ? This is similar to Mirja's comment about
> privacy.
>

The motivation behind the draft is largely to facilitate this explicit
signal to the authorization server (AS) about the location or identity of
the protected resource for which the client is requesting an access token.
For the reasons previously mentioned. Something that's opaque to the AS
would negate the ability of the AS to do most of that stuff (admittedly not
all but most).

-- 
_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._