Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
Atul Tulshibagwale <atul@sgnl.ai> Wed, 27 March 2024 19:02 UTC
Return-Path: <atul@sgnl.ai>
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 2A5C4C14CE5E for <oauth@ietfa.amsl.com>; Wed, 27 Mar 2024 12:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sgnl.ai
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob1B7Th4skyU for <oauth@ietfa.amsl.com>; Wed, 27 Mar 2024 12:02:00 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55FBC169436 for <oauth@ietf.org>; Wed, 27 Mar 2024 12:01:06 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-5c229dabbb6so88465a12.0 for <oauth@ietf.org>; Wed, 27 Mar 2024 12:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sgnl.ai; s=google; t=1711566066; x=1712170866; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vyzixwehNgk4R7VKRVhj2aBPzTVwUuIy8ydX2w4AGhk=; b=EI3eGwQ/rtTbsqUbGfnmcheBJ2Z1IpKlkmT9psiuxzlBUf2ViSrcjZueHrkhbhufSl 48NUzCRRE2BNGfuuWym3qmG4wmU9g0AB8bas5U93RE1wdaGBxiQYhpaHR9bgtw1JUlAY IZFTBb+UDz61hEBmD4rKnUwlBKCoBUakMV0vloUpZ4q8v8ZFoAfpVQXCsdsTViQ87aye kI//iqBtbyWNddqPtOCncpcY4oDVk9mvUzMRjjtwy85fbpaMEWJD/cceQ+GTJzDHjlhX UbnYsEPYsUi1beGOmieZktvv3Dy7kYDNKMdnQOqZI0bBTtNO8JkaEsTYEGFeVnpLw6R5 SDhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711566066; x=1712170866; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vyzixwehNgk4R7VKRVhj2aBPzTVwUuIy8ydX2w4AGhk=; b=GmgOnsUYN8T4dRpSL+BcI6V1WLzWbCPfzM8Q4QznxSUsACQUs53D9L2TLmKs5tOu+c nxCQplrESQg31ks0vMu3HXh3ylciDrIIBqeOXhNTJZ6Xuzu8qQ5U7z5molkMb4Wbtm+q +h+9m9jiOJvcFAyhSHr0L6qmr3YwwAAkBmEfYj1Ir741jdaWJfazXM3YFjRKW/j5/K3O n3vsL30shMYo1GMGZJtKJobZofBUcpsSrPRfOg38Qt6RpSUTMdwuvtZDUAvgYde2+HbK Evj0XnpPbanR2m95nHi8QbD59dVRqjBUUt47dt7rqm1cQXJaXt4Sy7ONwm2YovYhJlBb gwFQ==
X-Gm-Message-State: AOJu0YyfYQqDqXn1u6aF4Mc33d3++QSpe2R6Cz6lBZTpQqF/FtwHUGEy gLnVoCH7ATqGgEbDGwwz43uG1eGNRfsrd2ZVbcF/0f0UQNUHlmHdfKX74BtaEqn+iWU8l67cvHT iDy/1JIR2M2P2ednMHISWPZhePEtgvd2ktNKykw==
X-Google-Smtp-Source: AGHT+IFOGIzOipY5eR7W0F+upUXUQFBi57fm1OXTUZ5GoF8TInqPpl1udq+ngxdj0vlfbjImtOPqKTRDt3W9VfDVG7k=
X-Received: by 2002:a17:90a:9910:b0:29b:4a20:18b7 with SMTP id b16-20020a17090a991000b0029b4a2018b7mr549333pjp.8.1711566065130; Wed, 27 Mar 2024 12:01:05 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP9QRjmgs5Si4Fj+hSmScwx+4ihQmxfznCCVE4+8F2UFkw@mail.gmail.com>
In-Reply-To: <CADNypP9QRjmgs5Si4Fj+hSmScwx+4ihQmxfznCCVE4+8F2UFkw@mail.gmail.com>
From: Atul Tulshibagwale <atul@sgnl.ai>
Date: Wed, 27 Mar 2024 12:00:49 -0700
Message-ID: <CANtBS9cNXEsiv8UqPSSeRf8pfUXZea5_bftwwFb5PnfG9YSfoA@mail.gmail.com>
To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000527c9e0614a9070d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/s2k0ULLxclU3RHv0GAFuFW3oKig>
Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 27 Mar 2024 19:02:05 -0000
Hi all, I'd committed to reviewing the draft at IETF 119, so here is my feedback up to section 3.1: 1. Section 1: The sentence "Each protected resource publishing metadata about itself makes its own metadata document available at a well-known location rooted at the protect resource's URL, even when the resource server implements multiple protected resources." has two issues: 1. Typo: "protected resource's URL" instead of "protect resource's URL" 2. This contradicts the statement in section 3, which states the "well-known" should be inserted between the host and path components 2. Section 1: The sentence "The means by which the client obtains the location of the protected resource metadata document is out of scope" conflicts with Section 3, which says "Protected resources MUST make ... (it) available at a path ...". 3. Section 2, "authorization_servers": since this is normative language, instead of saying "Protected resources MAY choose not to advertise some supported authorization servers even when this parameter is used.", should we say "the list of OAuth authorization servers MAY be a subset of the authorization servers supported by the protected resource." 4. Section 3, paragraph 1: The last sentence, i.e. "The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry" is a bit confusing. Should it say something like "If not using the default well-known URI, such URI path suffix MUST be registered..." This last sentence of paragraph 1 can actually be dropped, and the first sentence in the 2nd paragraph can be updated to refer to the IANA well-known registry. 5. Section 3, paragraph 2: The first sentence should capitalize "MAY" in "...application-specific ways may define and register..." 6. Section 3, paragraph 2: The first sentence can drop the word "used" here: "...URI path suffixes used to publish..." The sentence will make more sense with that word dropped. 7. Section 3, paragraph 2: The last sentence is additional non-normative language, and could be removed, or could be moved to the "IANA Considerations" section 8. Section 3, paragraph 3: "...specify what well-known URI string..." should be changed to "...specify what well-known URI path-suffix..." 9. Section 3, paragraph 3: Instead of saying "...publish its metadata at multiple well-known locations'', should we say "...publish its metadata using multiple well-known path-suffixes''? 10. Section 3.1, last paragraph: The sentence "This is required in some multi-tenant hosting configurations" may be removed as it is not the only situation in which a host may have multiple OPRM documents. I will continue the review but I wanted to update the WG on my review so far. Atul On Wed, Mar 27, 2024 at 5:54 AM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote: > All, > > This is a *WG Last Call* for the *OAuth 2.0 Protected Resource Metadata* > document. > https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-03.html > > Please, review this document and reply on the mailing list if you have any > comments or concerns, by *April 12*. > > Regards, > Rifaat & Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Michael Jones
- [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource … Rifaat Shekh-Yusef
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Atul Tulshibagwale
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Michael Jones
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Vladimir Dzhuvinov
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Giuseppe De Marco
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Atul Tulshibagwale
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Michael Jones
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Brian Campbell
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Brian Campbell
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Michael Jones
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Brian Campbell
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Brian Campbell
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Michael Jones
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Pieter Kasselman
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Michael Jones
- Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resou… Michael Jones