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

[Dan Moore <[e-mail]>]

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]
>