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 <[email protected]> > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > _______________________________________________ > OAuth mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
