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