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

[Warren Parad <[e-mail]>]

What's confusing regarding Paul's suggestion. I feel like this says the
same thing in a more convoluted way. Would you be able to share, what you
believe the replacement suggestion implies that would be problematic?

On Mon, Jul 7, 2025, 13:24 Denis <denis.ietf=[e-mail]>
wrote:

> Hi Christian,
>
> IMO, the sentence proposed by Paul is confusing.
>
> I still do not think that such a sentence is needed, but if you *really*
> want to add some guidance, I would propose the following:
>
> If a Relying Party chooses to validate a bunch of cached Status List
> Tokens returned from the Status List Aggregation endpoint and encounters an
> invalid SLT,
> then it SHOULD skip that one and continue with the remaining cached Status
> List Tokens. For every skipped SLT, if the Relying Party is online, it
> SHOULD
> attempt to fetch the relevant SLT online.
>
> Denis
>
> Hi Denis,
>
> The current text does not imply that you should validate after fetching,
> it simply states that whenever you are validating a bunch of cached SLTs
> and encounter an invalid SLT, then you should skip that one and continue
> with the rest.
> I don’t think we should say anything other than that and the current
> sentence does not hinder implementations to validate SLTs on demand / when
> needed.
>
> Best regards,
> Christian
>
> On 7. Jul 2025, at 11:57, Denis <denis.ietf=[e-mail]>
> <denis.ietf=[e-mail]> wrote:
>
> 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
>       - 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 to [e-mail]
>
>
>
> _______________________________________________
> 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]
>
>
> _______________________________________________
> 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]
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>