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=40free...@dmarc.ietf.org> 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=40free...@dmarc.ietf.org> > <denis.ietf=40free...@dmarc.ietf.org> 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 <internet-dra...@ietf.org> 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 -- oauth@ietf.org >> To unsubscribe send an email to oauth-le...@ietf.org >> > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
