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

[Denis <[e-mail]>]

Hi Paul,

Unfortunately, this change proposal does not address my concern.

I have the following approach in mind:

The Relying Party fetches all the Status List Tokens mentioned at the 
Status List Aggregation endpoint. It does not verify any signature at 
this time.
When later on, it needs to verify the status of a Referenced Token, it 
looks whether one of these Status List Tokens contains the status of 
this Referenced Token.
If it is the case, the Relying Party then validate it, including its 
signature.

If the Relying Party encounters an error while validating this Status 
List Token, it does not continue processing the other Status List 
Tokens, but,
if it is online, it attempts to get the relevant Status List Token.

I still prefer to remove this sentence. However, if you really want to 
add a sentence, I would propose the following:

    If a Relying Party encounters an error while validating a Status
    List Token returned from the Status List Aggregation endpoint, if it
    is online,
    it SHOULD attempt to get the relevant Status List Token online.

Denis

> Hi Denis,
>
> we changed Line 842 to: "If a Relying Party encounters an error while 
> validating one of the Status List Tokens returned from the Status List 
> Aggregation endpoint, it SHOULD continue processing the other Status 
> List Tokens."
>
> This removes any indication whether this is happening during fetching 
> or during runtime and hopefully addresses your concerns.
>
> Best, Paul
>
> On 7/4/25 19:24, Denis wrote:
>>
>> Hi Paul,
>>
>> In the Editor's copy, the abbreviation "TSL" does not yet appear. It 
>> should be inserted into the document, as well as in the title:
>>
>>     *Token Status List (TSL)*
>>
>> *Line 840:*
>>
>>     - 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.
>>
>>     + Status List Aggregation is an optional mechanism offered by the
>>     Issuer to publish a list of one or more Status List Tokens URIs,
>>     allowing a Relying Party to fetch Status List Tokens provided by
>>     this 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.
>>
>> This change is fine for me.
>>
>> *Line 842:*
>>
>>     - 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 Lists
>>     referenced in the response instead of fully aborting processing
>>     and retrying later.
>>
>>     + If a Relying Party encounters an error while validating Status
>>     List Token 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 change is still not fine for me.
>>
>> As already said, processing options should be left open. Fetching 
>> does not imply or mandate any validation. If validation were done at 
>> caching time, this would slow down the process.
>> Validation can be done either asynchronously at any time *after* the 
>> caching or at the time of use of a TSL. There are many ways to take 
>> advantage of the caching and hence recommanding a given way
>> would not be appropriate. For example, the signature of a Status List 
>> Token can only be validated when it contains the reference of the 
>> Referenced Token. As another example, all Status List Tokens can be 
>> validated
>> asynchronously in the background, in particular when a 
>> multi-processor environment is available. In this way, if the 
>> processing is complete, Status List Tokens from the Status List 
>> Aggregation endpoint are already validated.
>>
>> The simplest way to solve this issue is to remove this sentence.
>>
>> Denis
>>
>>
>>> Hi Denis,
>>>
>>> responses inline. We intend to merge this PR  by Monday before IETF 
>>> cutoff.
>>>
>>> On 6/30/25 08:34, Denis wrote:
>>>> Hi Paul,
>>>>
>>>> Three replies are embedded into the text.
>>>>>
>>>>> 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
>>>>>>
>>>> Denis: OK. Let we add the acronym 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.
>>>>>>
>>>> Denis: Instead of:
>>>>
>>>>    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.
>>>>
>>>> I propose:
>>>>
>>>>    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.
>>>>
>>>>    Relying Parties may not know whether an Issuer uses this mechanism
>>>>    to allow the retrieval of either all Token Status Lists that it 
>>>> issues or
>>>>    Token Status Lists specific to some types of Referenced Tokens.
>>>>
>>>> This text does not remove any functionality.
>>>>
>>> I proposed the following changes: 
>>> https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/295/commits/4fb1686ce19ea747a388be6d7433c30f5355bee1 
>>>
>>>>
>>>>>>>
>>>>>>> 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? 
>>>>
>>>> Denis: Fetching does not imply or mandate any validation. If 
>>>> validation were done at caching time, this would slow down the 
>>>> process.
>>>> Validation can be done either asynchronously at any time *after* 
>>>> the caching or at the time of use of a TSL. Options should be left 
>>>> open.
>>>>
>>> I proposed the following changes: 
>>> https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/295/commits/0e99662ec82b2e26001da537ae8ea19505c35198 
>>>
>>>>
>>>>
>>>> End of replies.
>>>>
>>>> PS: Since we will both attend the Global Digital Collaboration 
>>>> Conference in Geneva on July 1 rst and 2 nd,
>>>> there will be an opportunity to meet together there.
>>>>
>>>>
>>>>>>>
>>>>>>> 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]
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list [e-mail]
>>>>> To unsubscribe send an email [e-mail]
>>>>
>>>>