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

[Paul Bastian <[e-mail]>]

Our proposed changes are in this PR: 
https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/295

On 6/20/25 13:06, Paul Bastian wrote:
>
> Hi Denis,
>
> I've responded to your issues in detail in this Github issue: 
> https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/294
>
> I also copied my answers inline as well.
>
> A PR will follow later today.
>
> Best regards, Paul
>
> On 6/9/25 09:06, Denis wrote:
>> 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)
>
> The name "Token Status List" of the draft makes sense:
>
>   * the naming is similar to Certificate Revocation List - read:
>     Revocation List for Certificates, here the same: Status List for Token
>   * Token is a very common term in the OAuth ecosystem, similar to
>     "Certificate", so the naming sequence is exactly the same as CRL
>   * the Status List Token is still its own thing, it's defined in the
>     section 5 and covers how a Status List structure from Section 4 is
>     integrty/authenticity-protected, however a Status List Token is
>     usually not relevant from the high-level outside look
>
> Conclusion:
>
>   * I agree that it makes sense to establish an official abbreviation
>     like CRL
>       o I think that TSL makes more sense
>   * Status List Token should remain as an internal terminology apart
>     from TSL
>
>>
>>
>> 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.
>>
> Partly accepted
>> 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).
> The URI is a non-normative example, so I don't believe it is relevant. 
> If other group members think this is important, we may change this.
>>
>>
>> 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.
>>
>
> The Section 9 on Status List Aggregation lists two mechanisms:
>
>     There are two options for a Relying Party to retrieve the Status
>     List Aggregation. An Issuer MAY support any of these mechanisms:
>
>     Issuer metadata: The Issuer of the Referenced Token publishes an
>     URI which links to Status List Aggregation, e.g. in publicly
>     available metadata of an issuance protocol
>
>     Status List Parameter: The Status Issuer includes an additional
>     claim in the Status List Token that contains the Status List
>     Aggregation URI.
>
> So while the Relying Party may not know whether an Issuer uses a 
> particular Status List Aggregation to link /all/ Status Lists or only 
> for a specific type of Referenced Token, an Issuer has still the 
> choice to do so, therefore the text is correct in my opinion. Your 
> proposed text removes functionality that does not match the rest of 
> Section 9.
>
>>
>> 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.
> You are correct that it is slightly better to say Status List Token 
> here. Apart from this, I believe that validation at caching time makes 
> sense. There are multiple options ins COSE and JOSE that require 
> fetching additional resources, like |kid| for |x5u|, that wouldn't 
> work if you only pre-fetch Status List Tokens without validation?
>>
>>
>> 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"
>>           ]
>>        }
>>
> Accepted
>>
>> 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.
>>
> Accepted to split the sections.
>>
>> 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.
>>
> Indeed the existing text is not ideal. I propose: "A JSON object 
> containing a reference to a status mechanism from the JWT Status 
> Mechanisms Registry."
>> 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.
>>
> Indeed the existing text is not ideal. I propose: "A JSON object 
> containing up-to-date status information on multiple tokens using the 
> Token Status List mechanism."
>>
>> 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]
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list [e-mail]
>> To unsubscribe send an email [e-mail]