Hi Christian, I'd be happy to do a review. Will get back to you by Wed latest.
Meta-note: is opening a PR a better way to give this kind of feedback in the future? Thanks for your response about the status claim; appreciate the fact you looked into it already. Dan On Mon, Jun 16, 2025 at 12:46 AM Christian Bormann <chris.bormann= 40gmx...@dmarc.ietf.org> wrote: > 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 “status” claim: We did an initial search as well and didn’t > 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=40fusionauth...@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? > > 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" > > 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 > <https://www.ietf.org/archive/id/draft-ietf-oauth-status-list-11.html#aggregation> > > - 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 AM Rifaat Shekh-Yusef < > rifaat.s.i...@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 AM <internet-dra...@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=draft-ietf-oauth-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-le...@ietf.org >>> >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-le...@ietf.org >> > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > > -- <https://fusionauth.io> Dan Moore Principal Product Engineer @ FusionAuth <https://fusionauth.io/> 11080 Circle Point Rd Suite 405, Westminster, CO 80020 <https://github.com/FusionAuth> <https://twitter.com/FusionAuth> <https://www.linkedin.com/company/fusionauth> <https://www.youtube.com/c/fusionauth>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
