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

[Dan Moore <[e-mail]>]

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