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

Adam Roach <adam@nostrum.com> Fri, 06 September 2019 00:41 UTC

Return-Path: <adam@nostrum.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 5E866120043; Thu, 5 Sep 2019 17:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level:
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 T9SGv5OO9kPY; Thu, 5 Sep 2019 17:41:31 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0EBC1120071; Thu, 5 Sep 2019 17:41:31 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x860fM2R082855 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Sep 2019 19:41:24 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1567730486; bh=xsK5R6ywfbBSYjrqddIZLE+0aujhv6Ksv9jEYNSfMIY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=DyNWvmr3Aml6tSRYpz32w3h43WwTHkcE1YAYgnyGMpRjx28oyhPUYOetn9tdgErXr QrAcJGrfHAFCRAblDpmCKuQk3lE2sahIaRUauYZBYcWvDI7GddiGa114s2cHbn8QSH ok8+wS0+UXeonIj7JSiOhTHRWsVCd89oBQ9DvfOk=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Barry Leiba <barryleiba@computer.org>, Brian Campbell <bcampbell@pingidentity.com>
Cc: draft-ietf-oauth-resource-indicators@ietf.org, oauth-chairs@ietf.org, The IESG <iesg@ietf.org>, oauth <oauth@ietf.org>
References: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com> <CA+k3eCSH5pkMkqBUmcENSdc3kDB0z3kpZoVGrPdB2hbsXvV8Bg@mail.gmail.com> <CALaySJJKt7UM7Xq-azgh1eF8hoBwvf+xatdC-PTeSOYvFBsieA@mail.gmail.com> <CA+k3eCQzTDChVPVZiDPykV7GqU_ibpG9g8Av4Rr+uqd1gtBUsg@mail.gmail.com> <CA+k3eCS-pmo5Htq5=8zxbdV0AZtzb=RuE2PfhjPbBttZe+Tywg@mail.gmail.com> <CALaySJ+8Rov1ghLhyJWDERfR17x1FKo_a3+_v9vFea2chqRt6A@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <354c9b93-271e-9ff2-86a5-9a9e76ab77e7@nostrum.com>
Date: Thu, 5 Sep 2019 19:41:17 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CALaySJ+8Rov1ghLhyJWDERfR17x1FKo_a3+_v9vFea2chqRt6A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/CvMxUEGom_UIHDJ82t6v_evzUbs>
Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)
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: Fri, 06 Sep 2019 00:41:33 -0000

I don't have a strong objection to it. I still think that, if this is 
allowed (even as a SHOULD NOT), we need clarity that any query 
parameters that are used to scope queries to an application necessarily 
form part of the resource parameter. It's significantly less important, 
though, now that the practice is discouraged, and I won't mind if you go 
ahead without adding such text.

/a

On 9/5/19 4:01 PM, Barry Leiba wrote:
> Thanks, Brian.  I hope Adam is happy with that as well.
>
> Barry
>
> On Thu, Sep 5, 2019 at 3:01 PM Brian Campbell
> <bcampbell@pingidentity.com>; wrote:
>> I went ahead with this in -07.
>>
>> On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell <bcampbell@pingidentity.com>; wrote:
>>> Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a change like that at this stage. I guess I'd be looking for a little more buy-in from folks first. Though it's not actually a functional breaking change. So maybe okay to just go with.
>>>
>>> On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba <barryleiba@computer.org>; wrote:
>>>>> Yeah, with query parameters lacking the hierarchical semantics that the path component has, it is much less clear. In fact, an earlier revision of the draft forbid the query part as I was trying to avoid the ambiguity that it brings. But there were enough folks with some use case for it that it made its way back in. While I am sympathetic to the point you're making here, I'd prefer to not codify the practice any further by way of example in the document.
>>>> Is it perhaps reasonable to discourage the use of a query component
>>>> while still allowing it?  Maybe a "SHOULD NOT", such as this?:
>>>>
>>>> OLD
>>>>        Its value MUST be an absolute URI, as specified by
>>>>        Section 4.3 of [RFC3986], which MAY include a query component but
>>>>        MUST NOT include a fragment component.
>>>> NEW
>>>>        Its value MUST be an absolute URI, as specified by
>>>>        Section 4.3 of [RFC3986].  The URI MUST NOT include
>>>>        a fragment component.  It SHOULD NOT include a query
>>>>        component, but it is recognized that there are cases that
>>>>        make a query component useful.
>>>> END
>>>>
>>>> What do you think?
>>>>
>>>> Barry
>>
>> 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.