Re: [Ace] [Last-Call] Opsdir last call review of draft-ietf-ace-revoked-token-notification-06
Dhruv Dhody <dhruv.ietf@gmail.com> Mon, 01 April 2024 17:55 UTC
Return-Path: <dhruv.ietf@gmail.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 9EEEFC151062; Mon, 1 Apr 2024 10:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.com
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 f0AS1rZBfrjv; Mon, 1 Apr 2024 10:55:25 -0700 (PDT)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 9F308C14CE3B; Mon, 1 Apr 2024 10:55:17 -0700 (PDT)
Received: by mail-ua1-x92f.google.com with SMTP id a1e0cc1a2514c-7db1a2c1f96so1757280241.0; Mon, 01 Apr 2024 10:55:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711994116; x=1712598916; 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=Qy1WZBGTRgfHd9HcVEfNCTwgiiinGJEJq/FPehIfD8I=; b=EhJKa8+q8BsTw5gr67MRMTjnvuLyuZ1JCEg2md9h2wPdl5P5Q8kiRCzdMV0iUcGTeo HebbYXJH20hFfJJbL8jV20f4PUpYW6C/qQGZ0186Qz8kdMeMtuwET8V2ok1e6HEp6QrJ Gt2fWM6si+Dhu/CZ4LL6//Qd7jjyXvo3M6/R42XQe8ZFw0stQ5j2/0nCGTSJ9CDaPKwD yK9yl+HFsTJKdl0met+ywBKvQArFFI5mQuhZdZydaY+y0QxnQc5D67a0qTfWqf7biW1F 4UHzb8T+oEHOhs9D4vPhtTOz9BO8SJ+9gD61N1G8q0qO0XkZKJpR6INiSAweazCNnOT4 TxOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711994116; x=1712598916; 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=Qy1WZBGTRgfHd9HcVEfNCTwgiiinGJEJq/FPehIfD8I=; b=Mk5YKUCldIPF9wSXLgE8akrUjBt/1Ou7m+0SBVHEV634NaMV60rb6t66TW2hVxzZTI eEYhWzb7XfMFPlsvsAq6sBg2O5UGShDYOGBqDaJMnwVCxHiatjwbN6M9zBbCdZxWv0kt GFofym5A6x/r7Y/y5hEeNQWPVGSr7MCxhAlX4rJExl2jhZnZUsCN19HVVRPRM9Zl723B Bh1+yXpxt176l94wiiycLu1TZH7yjoct37PBY6HSnbB/WJdPkVSvMEMSawZXRplwfVgY c7/lWaOXizWuNi+FsDIpaTdZJjIotVgZjyiwvruRpVltOTt30V3nOwx8WOTBTdeoH6vd Icsg==
X-Forwarded-Encrypted: i=1; AJvYcCWoUZLSJsApdL6r7vD/ZKm948mvLgYoifXeSFi5Z2/7KenGlG+f/16LnPjO61H/YIFtIM1wOF8L28ojuiIrCtz+9iEzosuRf9iBG2TqphKRTUxffAbiLYOl/MhzsyCWeSmVKC6gn95Kmy1qzwzcI6ia9TR8i40JxEvxeO6Os5JEhAJyer1u8A9I
X-Gm-Message-State: AOJu0YxIhGu6UjM6nCXgzwSIQWDShuNBZh9ZjX20j0QHf6dT5deohm+C oP37Dn6mNtO/f1gc/hqrhyCGJCmoLjTz3TXt9E9Sal6dcFFPAL6iys49dS5JU7IZcagPSoRG8v/ d7heMxpHjM/P/WRn4BwmqljiXOHXLz3MKiYI=
X-Google-Smtp-Source: AGHT+IExRghGBd/cCbWp8Lu1qmA0odiu6i4jvEKuvBke6+LaZe5f8pAV3wVCk3ZMv2y5mTTnmsCbFca1/ydbZVeti7s=
X-Received: by 2002:a05:6102:291f:b0:478:42d7:c4cf with SMTP id cz31-20020a056102291f00b0047842d7c4cfmr8359410vsb.26.1711994115960; Mon, 01 Apr 2024 10:55:15 -0700 (PDT)
MIME-Version: 1.0
References: <171199386128.27279.11626228587925083773@ietfa.amsl.com>
In-Reply-To: <171199386128.27279.11626228587925083773@ietfa.amsl.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Mon, 01 Apr 2024 23:24:39 +0530
Message-ID: <CAB75xn5cn3uEWRF-K8m8wo8UVx-3C8LCOSNL27jwt3HtFBsnaw@mail.gmail.com>
To: Dhruv Dhody <dd@dhruvdhody.com>
Cc: ops-dir@ietf.org, ace@ietf.org, draft-ietf-ace-revoked-token-notification.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="00000000000023c05506150cb1cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/oc0qa6PvRgHxi11VqkOVPMlH_us>
Subject: Re: [Ace] [Last-Call] Opsdir last call review of draft-ietf-ace-revoked-token-notification-06
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.39
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, 01 Apr 2024 17:55:26 -0000
Hi, I see that the list formatting got messed up somehow. Well you can find the review also at - https://notes.ietf.org/draft-ietf-ace-revoked-token-notification-06?view Hope that helps! Thanks! Dhruv On Mon, Apr 1, 2024 at 11:21 PM Dhruv Dhody via Datatracker < noreply@ietf.org> wrote: > Reviewer: Dhruv Dhody > Review result: Has Issues > > # OPSDIR review of draft-ietf-ace-revoked-token-notification-06 > > I have reviewed this document as part of the Operational directorate's > ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects > of > the IETF drafts. Comments that are not addressed in the last call may be > included in AD reviews during the IESG review. Document editors and WG > chairs > should treat these comments just like any other last-call comments. > > The document provides a mechanism for the Authorization Server to notify > about > revoked access tokens via access to a Token Revocation List (TRL) on the > Authorization Server via CoAP. The document is clear and well-written. The > motivation is described well. The document is almost ready for publication. > > ## Operational Concern > - I am worried that the admin authorization is kept out of scope. I could > not > find how it is handled in the ACE framework and if this is acceptable. At > the > very least some hint or example can be provided... ```` > * Administrator: entity authorized to get full access to the TRL at > the AS, and acting as a requester towards the TRL endpoint. An > administrator is not necessarily a registered device as defined > above, i.e., a Client requesting access tokens or an RS consuming > access tokens. How the administrator authorization is established > and verified is out of the scope of this specification. > ```` > - Section 5.1, if the TRL maintains MAX_N items only and if the diff is > larger > than that wouldn't some of the diffs be lost when the requester finally > makes a > request? I would have assumed that in such a case we indicate it that to > the > requester and it could issue a full query instead. But MAX_N is applicable > for > full query as well. Perhaps that is okay for most deployments, but let's be > explicit about that in the document. > > ## Minor > - Thanks for including the description of "endpoint" in Section 1.1 but the > term is used in the Abstract and Introduction where it confused me on first > reading. I suggest adding a forward reference in the Introduction to avoid > confusion. Also in section 1.1, it would be better if we have a reference > to > the OAuth document where the term originates from. - Is there a suitable > reference for "CBOR diagnostic notation"? - Section 3, I suggest mentioning > that 0x58 identifies byte string with one-byte for n. - Section 5.1 "The AS > SHOULD provide requesters with the value of MAX_N, upon their > registration", > how about we make it a MUST and quality it with if diff is supported? - > Section > 5.1.1 "If supporting the "Cursor" extension, the AS SHOULD provide > registered > devices and administrators with the value of MAX_DIFF_BATCH...", why > SHOULD? I > think this should be a MUST! - Section 7, "SIZE <= MAX_N" but it is unclear > what exactly SIZE is, please add explicit text. - Section 14.1, should the > change controller be IETF instead? > > ## Nits > - Don't use "the CoAP protocol", the P in CoAP is already protocol! > - s/as interested to receive notifications/as interested in receiving > notifications/ - s/recent updates occurred over the list/recent updates > that > occurred over the list/ - s/with value the token hash of an access > token/with > the value of the token hash of an access token/ - s/The processing of a > full > query and the related response format are defined in/The processing of a > full > query and the related response format is defined in/ - s/other than 0 or > than a > positive integer/other than 0 or a positive integer/ - s/registers at the > AS > until a first update/registers at the AS until the first update/ - > s/pertaining > to the requester occurred to the TRL./pertaining to the requester that > occurred > to the TRL./ - s/registers at the AS until a first update/registers at the > AS > until the first update/ - s/Once completed the registration procedure at > the > AS,/Once the registration procedure is completed at the AS,/ - s/the > Client is > not aware about that yet,/the Client is not aware of that yet,/ > > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call >
- [Ace] Opsdir last call review of draft-ietf-ace-r… Dhruv Dhody via Datatracker
- Re: [Ace] [Last-Call] Opsdir last call review of … Dhruv Dhody