Return-Path: X-Original-To: oauth@mail2.ietf.org Delivered-To: oauth@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id C31EC3557B69 for ; Sun, 15 Jun 2025 23:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmx.de Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gGqQXhrwfW1 for ; Sun, 15 Jun 2025 23:46:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B1CBB3557B5F for ; Sun, 15 Jun 2025 23:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1750056383; x=1750661183; i=chris.bormann@gmx.de; bh=cbbKq+RhNGD1OtA6BK4JDVA5J3KbAWSuR4LI2PDVlps=; h=X-UI-Sender-Class:From:Message-Id:Content-Type:Mime-Version: Subject:Date:In-Reply-To:Cc:To:References:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=nAsQSUU6V5lrfhhPvlbRn8Ya1aU10jiQ5pOYXIF+8q9U5+50WzE5IAge6shibS4A xfeK4gc19EIugEeGXMjyxTA+5liKB7mhsSELkpcQfsT+OtUt2zRuwMY0UeVfTU0TP RI86xLQZ07RVqNk9bZm5R5AcLCT4Ih8jjtr+TtlU3IlsFoXjD1FHzdvN+J3hC+Wqq 8Vxcy1hhWJXEqjK9ignEYhnqAlU52CLap8PZgbc9YsVVnQSEkduqE2zLJPmYmUZyE MLJ76XEiwohaU6ErGy2HcBgiCRR6L/w+tbNKiDZdwAtNYMx9nnJe7gcVWJ+Rc7FPN y3TOnsY7cFmUE5yAmA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([95.208.68.89]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MGQnP-1uacF8280j-00EwSh; Mon, 16 Jun 2025 08:46:23 +0200 From: Christian Bormann Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B66D442F-86E3-46DE-A2CE-701ECC82A045" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\)) Date: Mon, 16 Jun 2025 08:46:12 +0200 In-Reply-To: To: Dan Moore References: <174799089870.946359.11727607923903135413@dt-datatracker-59b84fc74f-84jsl> X-Mailer: Apple Mail (2.3826.600.51.1.1) X-Provags-ID: V03:K1:+P5r3PyMv7FjwQUvz4OjCQCcIfFM1Z1TKC2S55o+5N/eCqE7FgC sVJQ2hmgoUcQcHi7JcvZtx7WA+qgh+7j6UbDZ1AHmIL8ESyDU8NEXzOuPawDH2Sk8MZGigy kIf8qiCildx/n9Q90w8GcG13iMNf+nbqNiOBuyYeT8aB9cu/VpX+SjkM6QrM1An53GQsgEm lk3fE4XAODIT5wjl7m3lw== UI-OutboundReport: notjunk:1;M01:P0:wY/1u1gMxoE=;NWyKWPFj3K6xt4gbGhYHdLISc/M Gi5agtpEiGWQDq4P1RI2KSNcamp8UlPvZabXKqZeKo309Qnm3+tjMoHwXPj8LGIz82lsfMVqZ PEC03pLL0hYVr5wPdOBocGRcyX/JAK+TVSRYw5KLOyXE6LU7lt5OrQOdTDixTxGOa9hHn6EeD YVbQRlRIdScCAGD1IUwiTei1NSj1YOoU361+/kyeiZlE91EvcbRC9l5Ol+F069cQf6Ymb2TIW xMOFwPMNkxhoT4KG20sTSdhVMfafsT2t5uFumt4+d8vK/h1Jy+UAiw4lO6YHtxFmzcce96Qjm qoRzzDinF8m9TrjsvsnAb0RkunUCz0W3KWR8Bmd7g83MzFyuumo/dVRKyyBRxmOGcuBk7WgZQ 8UQZRdyjxZR3U9Jprg5Htw0+Z2QLd6Is7Kec5A8XEiuT5Yd6cHq00CLGcayAgzLMaDH5q13oF 54bgrLoqfpiTmHAftLMARwUpESF+fjJJXdygjbsn6rV6ccSxWw9nVRTBpRtgJFjfmOl37/+EI SFGMngUlTae8a3Ng6H1pxhw+l+SgJy/1hVl7qnqpogW8uU/FXnGhTVvD2UmPGJturn9I1oS0J rSriUn4sClHcJ4QhYvG+vfgGD/twbqaogmduggJq9ep5UdV14YYx5IR8Z81G+TvalXlJF+lwI ggancSKWcZgwxwTHsHJ0uZ/FJegrDQzF2KknBnEabUkGcJInThjnqm6Vn8giIH7eSebM+qldO s1T/XqC9+qGu6a8Llk350Rz3AHgjaqpwDnnxJmZvorf6MpI26dyWZgzrM7M4BvXzZcAkNiUjH B26inrsP0LTqCJ+jZ36hBXCdC7hL5pEm92limZJwMvrqrZEh5QV+B+xoJU44MV1jhN1PUIMnQ w71J5HXxlb9HNTlQWizcTuYcWtKS/ZxsGDOmrWflYTUrRM5RDzdpe4buOlh5jkxtTbsL4uv6O rifilRiyZ8skMVwDKPSs+PhjV4wgLD1bjGRiIqt48zaLjjbjeNPxFa7cRbgW99n3hdZRVNoRQ tIFTQRdWoVfmVLN/Be0+4cNtZ8MkTFGzPrvRAvgrryednquOIuzy4MdrDKkgYUsKPxLeOfyIO gc1fdcusF6MqHQoJT6a0lFaAzIlMISnk+o1YZZ0vXnLPftlcNW0iUEBOGMRnXx0dofFX03D6W YyZi6sJ3W+0UXop9LD/KHqdGDEoSsgHCDi1oPlzn2rwDIIneFODy52q93JJ22SBI4DLg0HFCw Cfjrdc5AcFaAifB7+i/fOlmelm6HSOBdn7qFdRKSdJFkluKBeY8qasy206OlInkYvYCXgWUaj q/BH2osWCKsZvxlDqmXnlyWGsOt+yoKYmI5fTpUtcDSXCXrFoJXCt+79jFU3lBjd32XOCBjB3 LjvnbdzZhaEfj42pPQALc53KFoqWW4ji+I3OcX0PbN0CzFKc/dFZdV+AgbtMHqUMpVWkTspR8 zZqEnDAMrrRocwJ8SK4t0rsykaC3xGu7hLiwtjpRu/i4OZ8tvf8OoJ4IpgDm6l0oVolvQj5DX zSRPJisN0Dxid6k9Hztx8H0Sjjpi4CPZBfX01Mhlt6X9n68H2hVMSPMZ3DH5LKqyB3W/OucBo RhVCf+54/yb7auzXpLPCwtduR0JrSDi2RBubzCGgAkmzAbK0IL9FVxrDW1iYCCfOIG/RCy7KJ btkKxEtp7Fs7BgWkGpUXugaA8IE48px1o9e2jgracC7rWp6jRrKtBl7Jb7pEGvg4SPyCx8T73 ZOtZw13T4P7DyVf5btM5vI2efwPemcS46tnvXnW8ny4TqiJxhMfQhXMxqhs5HB3dXfB3Lycd6 bovp3A822G7+8+6kdaC8SG2HZEHmMteWJQDEHzTYDr2iJgGH9QnyzpFO8sVDkAk8AEZMnjpCG hrZXSF1QdUqlnsLInOUC9AOlihqjRNkaTq67uioLzKUHFmMxBRk9zH0Mk9C1REiFq5HuGf0NY nLud5G5yWTyaGR2LtOxhOr2RfbqLHxJRBhzGuAcPf9PmMtMOv2ypWASCbUAzFO4CLnr/5twS6 kWnr/X6k40wV9AnXJXfgCHaWw8hzB7SHgAVhGVMsYgkbfO78COtkev8t9DrdtWfuHfEolhlfC L3HxTBADCpJPcMUet2OJt009wFGUVmDeN0Z/cokvkjKqkpf6VcxNQHe5p7iMuKE43DiHRP9cM k3VzH17h07wBtsTS89GFxuPuCO7BfPIwjAAqKPqsP80pdW/H4gGkt+T4bgQ0knKXHIOAMFKsL DrjHP80DVZiz/LZ3xLZE5XH7v6QFRQIeF/4ix/mwrkq7ZSwBBej0bdBzyN7UdvJYwF95b+nG/ qQbqChdn87Gq1gyD7fbFXVwdUqGVp3gGHCehDvKDk4nVYov52R/3gcp6cb79/VcznS7EaNG+c l/NzUu28TuWC2EvJQXsXbkpTNdeNfrhP6MemDPpwqYZMZ9w34HgVQFitkuLB2LeMlNESrmm3m +VVsybCIUYeTvXsiDZspOLlZPjbQ2vtUddwRPhpRF3dyb++L5QwbH79M4aWho5VrOHGfI+3VY jz3f5l8y/WUFM8YeIYBGk+NxAAbaGwnOnl30eJ0GkpBrp51b8JcwOlf9tuMZnXGfzhN/FPGlx qq3hhGXbhFpQJIkHRN8kqZ45nLdtwa6XcaD5ocAqXwXGrBILLNC9KvzjZoSBbYV5Ci5yIlaSh LOkBjmUnvb0l7FNkxWlVjRPR5qUPzThhjm1Z4qfD5lAamCKD09qW7pvxeJc9EqMoIDvc4GUjZ fFS09twEJ/rko2rRbELlFvKJ/fAuJXdENs3fcqcviRFVAFiEW3a7HnLzsO+OBEeF8aLveAIoD QzWgcu1GmA8Od3yKYjVt29S9hAGYXyNKxQT3LnilApvU/aBDmMDkGy9ZOwlWnCUd5z6nqx854 mRgDrF9rjO8hZuPzqlb7qEdG2WUwgXIkZRPXtbcCeCbVeD5NedqCOz8cTwk9lhAe45Wv4A0Jd 7EUgHBZrkGRhzAF68FWhD2eKXXOyWN7fZ5TFZ1hCr9dcjnOz0HJQ+7nveGxo0DWXd7U0DpJCr VQS3mwNxSn7u0krVaffNBWg3dqn9JyyeCp5CNYfLpT+HBuK/VVI/WSuw+9513BKtQMqzEg4L4 4TryNz4/y77NnFvtCtUNIYwfMBt95jRmQgPFf8QPHFruaJWpt+sTyTKZMtOcXD4iZMPRnBWsN bVZo46+/XT2WWRjvT13cXhXZYinXHMX9AU/vc4cWVDb1nCEkbkTuPvFh3Y2VBkyt82OdlZOQx 6JvcEELYRSGezIVcqqKTDcEVbY131J0fUTWmrWITWyKb6bH0ykrvpNsYUu7N07g+xpXd9QtPn M1DvFgCi42hnN0DccQxs6ocbV3Znrnn6qGjlq4EqYTdFmf4FA7PhICIrWAalKyve+y62K9NdU AidRiZ2wHERfeZ0kyuxMaMoHPCJ+NQx7j7sTW2UFBCCcpPuTBwydd039MUTM5wfF2zbSz4L+b su6wcy5CfEQ== Message-ID-Hash: YWU3OG3XGRBQ5PU7H6BNEUXETJFTLVZ2 X-Message-ID-Hash: YWU3OG3XGRBQ5PU7H6BNEUXETJFTLVZ2 X-MailFrom: chris.bormann@gmx.de X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: oauth@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_I-D_Action=3A_draft-ietf-oauth-status-list-11?= =?utf-8?q?=2Etxt?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_B66D442F-86E3-46DE-A2CE-701ECC82A045 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dan, Thank you for your feedback! We created a PR that incorporates your points: = https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/293. Would = you be able to do a review? Regarding the =E2=80=9Cstatus=E2=80=9D claim: We did an initial search = as well and didn=E2=80=99t find any collisions and there has been no = feedback indicating problems so far , so our proposal would be to keep = it as is. Best Regards, Christian > On 9. Jun 2025, at 20:49, Dan Moore = wrote: >=20 > Hi folks,=20 >=20 > I have the following comments. >=20 > As a general comment, I worry that Referenced tokens may already = define a "status" claim for their own purposes. Since this was not a = previously registered or public claim, I fear there may be collisions = with existing private claims. I'd suggest using a less common claim. = Perhaps _status (like the _sd claim in the SD-JWT RFC) or even = "token_status", which are both less likely to collide. I searched around = and didn't see "status" as a claim in any public documentation. This = affects section 3 and 6.1, among others. I'm new to this RFC discussion, = so perhaps this has been discussed already.=20 >=20 > Other comments: >=20 > Section 1: >=20 > There's a typo. "data structures" -> "data structure". >=20 > Section 1.2: >=20 > I found this sentence confusing: "Placing large amounts of Referenced = Tokens into the same list also enables herd privacy relative to the = Status Provider." >=20 > Would suggest this rewording: "Placing large numbers of Referenced = Tokens into the same list also offers Holders and Relying parties herd = privacy, even from the Status Provider." >=20 > Section 3: >=20 > Another possible typo: "Also known as Verifier." -> "Also known as a = Verifier." >=20 > Section 4.1.4: >=20 > This is the first introduction to status values, would be nice to = define the values of 0x00 and 0x01 or at least reference section 7.1. It = was confusing to not know the value meanings. In the next paragraph = there is a new status type, SUSPENDED which is defined. >=20 > There's also a status listed of value 3 (status[3]) but that value is = never defined. Would suggest either defining or mentioning that this is = application specific, as defined in 7.1. >=20 > Section 4.2: >=20 > This states the status_list claim is REQUIRED but it is not present in = the examples. Would it not be better to show that? For the first = example, display something like: >=20 > { > "status_list":=20 > { > "bits": 1, > "lst": "eNrbuRgAAhcBXQ" > } > } >=20 > Section 6.2:=20 >=20 > This sentence has a redundant phrase: "The value of idx MUST be a = non-negative number, containing a value of zero or greater." Could it be = replaced with "The value of idx MUST be a non-negative integer."? >=20 > There's a self-reference to section 6.2: "The "status" object uses the = same encoding as a JWT as defined in Section 6.2."=20 >=20 > But this sentence is in section 6.2. Is that intended or should it be = a reference to something else? What am I missing?=20 >=20 > Section 7.1: >=20 > There's a phrase that is not a full sentence: "Meaning the processing = of Status Types using these values is application specific." You could = drop 'Meaning'. >=20 > The following paragraph feels important: >=20 > "The processing rules for Referenced Tokens (such as JWT or CWT) = precede any evaluation of a Referenced Token's status. For example, if a = token is evaluated as being expired through the "exp" (Expiration Time) = but also has a status of 0x00 ("VALID"), the token is considered = expired." >=20 > Could add a MUST before 'precede' and change it to: >=20 > "The processing rules for Referenced Tokens (such as JWT or CWT) MUST = precede any evaluation of a Referenced Token's status. For example, if a = token is evaluated as being expired through the "exp" (Expiration Time) = but also has a status of 0x00 ("VALID"), the token is considered = expired." >=20 > It is a MUST in section 8.3, so maybe it'd be better to refer the = reader to that section? >=20 > Section 8.1: >=20 > I was confused by these two sentences: >=20 > "The Relying Party MUST send the following Accept-Header to indicate = the requested response type:" >=20 > "If the Relying Party does not send an Accept Header, the response = type is assumed to be known implicitly or out-of-band. " >=20 > I was under the impression that a MUST was non-negotiable, but in the = second sentence guidance for not sending the Accept-Header is given. = Maybe change MUST to SHOULD? >=20 > Section 8.3 >=20 > Perhaps Step 4.3 and 4.4 should reference section 13.6 which gives = implementation guidance? >=20 > Section 11.3: >=20 > Looks like a formatting issue with lists not being rendered.=20 >=20 > For example, "- the same x5c value or an x5t ..." and "- the same = x5chain value" >=20 > Section 12.1: >=20 > We refer to the "issuer" as "he" or "him" a few times in section 12. >=20 > Could replace it with "the issuer" without any loss of meaning and it = would read better: >=20 > "this would enable him" -> "this would enable the issuer" >=20 > Section 12.2: >=20 > Same as in section 12.1=20 >=20 > "By these means, he could maintain" -> "By these means, the issuer = could maintain" >=20 > Section 12.4: >=20 > "and his related business" was confusing. Maybe instead: "and related = implementation details" >=20 > The list prefaced with "This behaviour could be mitigated by:" needs = the tense to be changed. Suggest: >=20 > This behaviour could be mitigated by: > - disabling the Status List Aggregation Section 9 = > - choosing non-sequential, pseudo-random or random indices >=20 > - using decoy entries to obfuscate the real number of Referenced = Tokens within a Status List >=20 > - choosing to deploy and utilize multiple Status Lists simultaneously >=20 >=20 > Section 13.2 >=20 > The link appears broken: "see (#privacy-considerations) for more = details" >=20 > Section 13.3=20 >=20 > Similar to section 11, this section appears to have some list = formatting issues. "Status List Tokens depends on: - the size..." >=20 > Thanks, > Dan >=20 >=20 > On Fri, May 23, 2025 at 10:56=E2=80=AFAM Rifaat Shekh-Yusef = > wrote: >> All, >>=20 >> Please, review this version of the document and make sure that your = comments, if you had any, were addressed. >> I will start working on the shepherd write-up in a week or two. >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> On Fri, May 23, 2025 at 5:05=E2=80=AFAM > wrote: >>> Internet-Draft draft-ietf-oauth-status-list-11.txt is now available. = It is a >>> work item of the Web Authorization Protocol (OAUTH) WG of the IETF. >>>=20 >>> Title: Token Status List >>> Authors: Tobias Looker >>> Paul Bastian >>> Christian Bormann >>> Name: draft-ietf-oauth-status-list-11.txt >>> Pages: 72 >>> Dates: 2025-05-23 >>>=20 >>> Abstract: >>>=20 >>> This specification defines a mechanism, data structures and >>> processing rules for representing the status of tokens secured by >>> JSON Object Signing and Encryption (JOSE) or CBOR Object Signing = and >>> Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO >>> mdoc. It also defines an extension point and a registry for = future >>> status mechanisms. >>>=20 >>> The IETF datatracker status page for this Internet-Draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ >>>=20 >>> There is also an HTML version available at: >>> https://www.ietf.org/archive/id/draft-ietf-oauth-status-list-11.html >>>=20 >>> A diff from the previous version is available at: >>> = https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-oauth-status-list-1= 1 >>>=20 >>> Internet-Drafts are also available by rsync at: >>> rsync.ietf.org::internet-drafts >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list -- oauth@ietf.org >>> To unsubscribe send an email to oauth-leave@ietf.org = >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-leave@ietf.org = > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org = --Apple-Mail=_B66D442F-86E3-46DE-A2CE-701ECC82A045 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Dan,

Thank you for your feedback!
We = created a PR that incorporates your points: https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/293. = Would you be able to do a review?
Regarding the =E2=80=9Cstatus=E2= =80=9D claim: We did an initial search as well and didn=E2=80=99t find = any collisions and there has been no feedback indicating = problems so far , so our proposal would be to keep it as = is.

Best Regards,
Christian

On 9. Jun 2025, at 20:49, Dan Moore = <dan=3D40fusionauth.io@dmarc.ietf.org> wrote:

Hi folks, 

I have the following comments.

As a general = comment, I worry that Referenced tokens may already define a "status" = claim for their own purposes. Since this was not a previously registered = or public claim, I fear there may be collisions with existing private = claims. I'd suggest using a less common claim. Perhaps _status (like the = _sd claim in the SD-JWT RFC) or even "token_status", which are both less = likely to collide. I searched around and didn't see "status" as a claim = in any public documentation. This affects section 3 and 6.1, among = others. I'm new to this RFC discussion, so perhaps this has been = discussed already. 

Other comments:

   Section = 1:

There's a typo. "data structures" -> = "data structure".

   Section = 1.2:

I found this sentence confusing: "Placing large amounts of = Referenced Tokens into the same list also enables herd privacy relative = to the Status Provider."

Would suggest this rewording: = "Placing large numbers of Referenced Tokens into the same list also = offers Holders and Relying parties herd privacy, even from the Status = Provider."

   Section 3:

Another possible typo: = "Also known as Verifier." -> "Also known as a = Verifier."

   Section = 4.1.4:

This is the first introduction to status = values, would be nice to define the values of 0x00 and 0x01 or at least = reference section 7.1. It was confusing to not know the value meanings. = In the next paragraph there is a new status type, SUSPENDED which is = defined.

There's also a status listed of value 3 (status[3]) but = that value is never defined. Would suggest either defining or mentioning = that this is application specific, as defined in = 7.1.

   Section 4.2:

This = states the status_list claim is REQUIRED but it is not present in the = examples. Would it not be better to show that? For the first example, = display something like:

{
   = "status_list": 
  =  {
     "bits": 1,
     "lst": = "eNrbuRgAAhcBXQ"
  =  }
}

   Section = 6.2: 

This sentence has a redundant = phrase: "The value of idx MUST be a non-negative number, containing a = value of zero or greater." Could it be replaced with "The value of idx = MUST be a non-negative integer."?

There's a = self-reference to section 6.2: "The "status" object uses the same = encoding as a JWT as defined in Section = 6.2." 

But this sentence is in section = 6.2. Is that intended or should it be a reference to something else? = What am I missing? 

 &nbs= p; Section 7.1:

There's a phrase that is not a full = sentence: "Meaning the processing of Status Types using these values is = application specific." You could drop 'Meaning'.

The = following paragraph feels important:

"The = processing rules for Referenced Tokens (such as JWT or CWT) precede any = evaluation of a Referenced Token's status. For example, if a token is = evaluated as being expired through the "exp" (Expiration Time) but also = has a status of 0x00 ("VALID"), the token is considered = expired."

Could add a MUST before 'precede' and change = it to:

"The processing rules for Referenced = Tokens (such as JWT or CWT) MUST precede any evaluation of a Referenced = Token's status. For example, if a token is evaluated as being expired = through the "exp" (Expiration Time) but also has a status of 0x00 = ("VALID"), the token is considered expired."

It = is a MUST in section 8.3, so maybe it'd be better to refer the reader to = that section?

   Section = 8.1:

I was confused by these two = sentences:

"The Relying Party MUST send the = following Accept-Header to indicate the requested response = type:"

"If the Relying Party does not send an Accept Header, the = response type is assumed to be known implicitly or out-of-band. = "

I was under the impression that a MUST was non-negotiable, but = in the second sentence guidance for not sending the Accept-Header is = given. Maybe change MUST to = SHOULD?

   Section = 8.3

Perhaps Step 4.3 and 4.4 should reference = section 13.6 which gives implementation = guidance?

   Section = 11.3:

Looks like a formatting issue with lists not being = rendered. 

For example, "- the same x5c = value or an x5t ..." and "- the same x5chain value"

&nbs= p;  Section 12.1:

We refer to the "issuer" as "he" or = "him" a few times in section 12.

Could replace = it with "the issuer" without any loss of meaning and it would read = better:

"this would enable him" -> "this = would enable the issuer"

   Section = 12.2:

Same as in section = 12.1 

"By these means, he could maintain" = -> "By these means, the issuer could = maintain"

   Section = 12.4:

"and his related business" was confusing. Maybe = instead: "and related implementation details"

The list prefaced = with "This behaviour could be mitigated by:" needs the tense to be = changed. Suggest:

This behaviour could be = mitigated by:

- disabling the Status = List Aggregation Section = 9

- choosing non-sequential, = pseudo-random or random indices

- = using decoy entries to obfuscate the real number of Referenced Tokens = within a Status List

- choosing to = deploy and utilize multiple Status Lists = simultaneously


   Section = 13.2

The link appears broken: "see = (#privacy-considerations) for more details"

   Section = 13.3 

Similar to section 11, this section appears to have some list = formatting issues. "Status List Tokens depends on: - the = size..."

Thanks,
Dan


On Fri, May 23, 2025 at 10:56=E2=80=AFAM = Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> = wrote:
All,

Please, review this version of the = document and make sure that your comments, if you had any, were = addressed.
I will start working on the = shepherd write-up in a week or = two.

Regards,
 Rifaat

On Fri, May 23, 2025 at 5:05=E2=80=AFAM <internet-drafts@ietf.org> = wrote:
Internet-Draft draft-ietf-oauth-status-list-11.txt is now = available. It is a
work item of the Web Authorization Protocol = (OAUTH) WG of the IETF.

   Title:   Token = Status List
   Authors: Tobias Looker
    =         Paul Bastian
  =           Christian Bormann
  =  Name:    draft-ietf-oauth-status-list-11.txt
  =  Pages:   72
   Dates:  =  2025-05-23

Abstract:

   This specification = defines a mechanism, data structures and
   processing = rules for representing the status of tokens secured by
  =  JSON Object Signing and Encryption (JOSE) or CBOR Object Signing = and
   Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web = Token and ISO
   mdoc.  It also defines an extension = point and a registry for future
   status = mechanisms.

The IETF datatracker status page for this = Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-status= -list/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-status-= list-11.html

A diff from the previous version is available = at:
https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-o= auth-status-list-11

Internet-Drafts are also available by = rsync = at:
rsync.ietf.org::internet-drafts


________________________= _______________________
OAuth mailing list -- oauth@ietf.org
To = unsubscribe send an email to oauth-leave@ietf.org
_________= ______________________________________
OAuth mailing list -- oauth@ietf.org
To = unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To = unsubscribe send an email to oauth-leave@ietf.org

= --Apple-Mail=_B66D442F-86E3-46DE-A2CE-701ECC82A045--