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

[Denis <[e-mail]>]

Hi Rifaat,

I have 10 comments.

1) There are still a few vocabulary issues that relate to confusion 
between "Token Status Lists" and "Status List Tokens".
    This is addressed in subsequent comments.


2) The title of the document is "Token Status List". There is no single 
"Token Status List".
     The goal of this document is to allow the retrieval of Status List 
Tokens, where each Status List Token (SLT)
     contains a Token Status List that provides up-to-date status 
information on several Referenced Tokens.

    The acronym "SLT" should be introduced in the document, in the same 
way as the acronym "CRL"
     has been introduced for "Certificate Revocation List" (RFC 5280).

    The title of this document should rather be: Status List Tokens (SLTs)


3) The current text in section 6.1 (Status Claim) is:

        By including a "status" claim in a Referenced Token, the Issuer is
        referencing a mechanism to retrieve status information about this
        Referenced Token.  The claim contains members used to reference a
        Status List Token as defined in this specification.  Other
    members of
        the "status" object may be defined by other specifications.

    In this specification, only one member of the "status" object is 
defined.
    Taking into account the previous comment, I propose to rephrase 
these sentences as follows:

        By including a "status" claim in a Referenced Token, the Issuer can
        indicate in a "status" object, how status information about a
        Referenced Token can be obtained.  This specification defines one
        member of the "status" object, called "status_list".  Other
    members of
        the "status" object may be defined by other specifications.

4) The examples in sections 6.2 and 6.1 are confusing "status lists" 
with "status list tokens".

The current text in section 6.2 ( Referenced Token in JOSE) is:

        The following is a non-normative example of a decoded header and
        payload of a Referenced Token:

        {
          "alg": "ES256",
          "kid": "11"
        }
        .
        {
          "status": {
            "status_list": {
              "idx": 0,
              "uri": "https://example.com/statuslists/1"
            }
          }
        }


    The uri does not contain "statuslists" (status lists) but "slts" 
(Status List Tokens).
    The uri should be changed into the following way:

          "uri": "https://example.com/slts/1"

    The same comment applies to the example on page 22 within section 
6.3 (Referenced Token in COSE).


5) The current text in section 9 (Status List Aggregation) is:

    9.  Status List Aggregation

        Status List Aggregation is an optional mechanism to retrieve a list
        of URIs to all Status List Tokens, allowing a Relying Party to
    fetch
        all relevant Status List Tokens for a specific type of Referenced
    Token or Issuer.  This mechanism is intended to support fetching and
        caching mechanisms and allow offline validation of the status of a
        reference token for a period of time.

     The wording "for a specific type of Referenced Token or Issuer" 
should be avoided because the retriever of the SLTs
     has no way to know whether the retrieved SLTs will be about a 
"specific type of Referenced Token", about "all the Referenced Tokens
     issued by that Issuer" or about anything else. Depending upon 
choices made by the Issuer, the retrieved SLTs may help or
     *may not help* the Relying Party, depending upon the context and 
the choices made by the Issuer.

The following rewording is proposed:

    9.  Status List Aggregation

    Status List Aggregation is an optional mechanism that allows to take
    advantage of an access to a given Status List Token
    referenced in a Referenced Token to retrieve other Status List
    Tokens published by the same Issuer.
    This feature is intended to support pre-fetching and caching of
    Status List Tokens and allows offline validation of the status
    of further received Reference Tokens for a period of time.


6) The text continues with:

        "If a Relying Party encounters an invalid Status List referenced in
        the response from the Status List Aggregation endpoint, it SHOULD
        continue processing the other valid Status Lists referenced in the
        response instead of fully aborting processing and retrying later".

    This sentence is misleading: the Status List Aggregation endpoint 
does not contain "Status Lists" but contains "Status List Tokens".
    If corrected the quoted sentence, the sentence would become:

        If a Relying Party encounters an invalid Status List Token
    referenced
        in the response from the Status List Aggregation endpoint, it
    SHOULD
        continue processing the other valid Status List Tokens
    referenced in
        the response instead of fully aborting processing and retrying
    later.

    However, when fetching the Status List Tokens, the pre-fetching and 
caching mechanism does not *mandate* any "validation mechanism",
    hence the concept of an " invalid Status List" or of an " invalid 
Status List Token" is irrelevant. The goal of this mechanism is to allow
    fetching SLTs and to place them into a cache without *necessarily* 
verifying their "validity" at the moment of the retrieval.
    I propose to remove that sentence.


7) Section 9.3 (Status List Aggregation in JSON Format) states:

    9.3.  Status List Aggregation in JSON Format

        This section defines the structure for a JSON-encoded Status List
        Aggregation:

        *  status_lists: REQUIRED.  JSON array of strings that contains
    URIs
           linking to Status List Tokens.

        The Status List Aggregation URI provides a list of Status List
    URIs.

        (...)

        The following is a non-normative example for media type
    application/
        json:

        {
           "status_lists" : [
              "https://example.com/statuslists/1",
              "https://example.com/statuslists/2",
              "https://example.com/statuslists/3"
           ]
        }


    Given the confusion between "Status Lists" and "Status List Tokens", 
the text from this section should be modified.
    Below is a proposal:

    9.3.  Status List Aggregation in JSON Format

        This section defines the structure for a JSON-encoded Status List
        Aggregation:

        *  status_lists: REQUIRED.  JSON array of strings that contains
    URIs
           linking to Status List Tokens.

        The Status List Aggregation URI provides a list of Status List
    *Token* URIs.

        (...)

        The following is a non-normative example for media type
    application/
        json:

        {
           "status_lists" : [
              "https://example.com/slts/1",
              "https://example.com/slts/2",
              "https://example.com/slts/3"
           ]
        }


8) Section 13.1 (Token Lifecycle) states:

    13.1.  Token Lifecycle

        The lifetime of a Status List Token depends on the lifetime of its
        Referenced Tokens.  Once all Referenced Tokens are expired, the
        Issuer may stop serving the Status List Token.

        Referenced Tokens may be regularly re-issued to mitigate the
        linkability of presentations to Relying Parties.  In this case,
    every
        re-issued Referenced Token MUST have a fresh Status List entry in
        order to prevent this from becoming a possible source of
    correlation.

        Referenced Tokens may also be issued in batches and be presented by
        Holders in a one-time-use policy to avoid linkability.  In this
    case,
        every Referenced Token MUST have a dedicated Status List entry and
        MAY be spread across multiple Status List Tokens.  Revoking batch-
        issued Referenced Tokens might reveal this correlation later on.

    The use of the sub-title 13.1 "Token Lifecycle " is confusing as it 
can apply either to "Referenced Tokens" or to "Status List Tokens".
    The first sentence applies to "Status List Token Lifecycle" but the 
next sentences apply to linkability issues using indexes contained
    in Status List Tokens. I propose to separate these two cases.

The following text is proposed:

    13.1.  Status List Token Lifecycle

        The lifetime of a Status List Token depends on the lifetime of its
        Referenced Tokens.  Once all Referenced Tokens from a Status
    List Token
        are expired, the Issuer may stop issuing the Status List Token.

    13.2.  Linkability issues using indexes contained in Status List Tokens

        To mitigate the linkability of presentations of Referenced
    Tokens to
        Relying Parties using the index contained in a Status List Token,
        batches of one-time-use Referenced Tokens should be issued by the
        Issuer and each Referenced Tokens from the batch should only be
    used
        once by the Holder.

        For each Referenced Token belonging to a batch of one-time-use
        Referenced Tokens, the indexes in the Status List should not be
        placed into the same Status List and hence into the same Status
    List
        Token, but spread among different Token Status Tokens.  In this
    way,
        if the status of a batch of one-time-use Referenced Token changes
        simultaneously, it will be difficult to know whether the Referenced
        Tokens belongs to a batch of one-time-use Referenced Tokens and to
        which one.


9) There is also an issue about the new IANA entries where the "status" 
claim is defined
     and where it is possible to place underneath the "status_list" entry.

    The definition of the Claim Name "status" in section 14.1.1 includes 
the following sentence:

        *  Claim Description: Reference to a status or validity mechanism
           containing up-to-date status information on the JWT.

    A status or a validity mechanism does not *contain* up-to-date 
status information.
    It *describes* how status information is provided for a given 
Referenced Token.

    I suggest to change this sentence into:

        *  Claim Description: Reference to a status or validity mechanism
           describing how status information about a Referenced Token can
           be obtained.

10) Section 14.1.2 defines the Claim Name "status_list"

    Claim Name: status_list

        *  Claim Description: A status list containing up-to-date status
           information on multiple tokens.

    I propose to rephrase it in this way:

    Claim Name: status_list

        *  Claim Description: A status list contained in a Status List
    Token
           providing up-to-date status information on several Referenced
           Tokens.


Denis

> 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 [e-mail]