[OAUTH-WG] Re: I-D Action: draft-ietf-oauth-status-list-11.txt

[Paul Bastian <[e-mail]>]

Hi Dan,

if you have typos or things that you are certain about, feel free to 
open a PR directly. For things that you are unsure or that likely need 
discussion first, write on the mailing list or open a Github issue.

Best, Paul

On 6/16/25 21:20, Dan Moore wrote:
> 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=[e-mail]> 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=[e-mail]> 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 AggregationSection 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
>>     <[e-mail]> 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 <[e-mail]> 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 [e-mail]
>>             To unsubscribe send an email [e-mail]
>>
>>         _______________________________________________
>>         OAuth mailing list [e-mail]
>>         To unsubscribe send an email [e-mail]
>>
>>     _______________________________________________
>>     OAuth mailing list [e-mail]
>>     To unsubscribe send an email [e-mail]
>
>
>
> -- 
> <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 [e-mail]
> To unsubscribe send an email [e-mail]