Hi Rifaat, Thanks a lot for the Review! My comments are in-line. Are you fine with me creating a PR along the lines of my comments?
Best Regards, Christian > On 13. May 2025, at 20:31, Rifaat Shekh-Yusef <[email protected]> wrote: > > Authors, > > As the document shepherd, I have reviewed the Token Status List v10 and I > have the following comments: > > > Comments/Questions > ================== > > 1.1. Example Use Cases > > > Token Introspection [RFC7662] defines another way to determine the status > of an issued access token, but it requires the party trying to > validate the state of access tokens to directly contact the token > issuer, whereas the mechanism defined in this specification does not > have this limitation. > > This mechanism still requires the relying party to interact with the Issuer > or an entity that hosts the status of these tokens on behalf of the Issuer. > How is this interaction different from Introspection interaction? For token introspection, every verification requires communication, whereas a status list token can be used many times within its validity period (different trade-offs of network calls and freshness). Additionally, the Issuer/IdP would learn about every client in the case of token introspection, whereas they don’t with status list (herd anonymity). There is also the option for a client to provide the status list token with the referenced token eliminating the need for the RP to contact the Issuer at all. > 4.1. Compressed Byte Array > > 1. The Status Issuer MUST define a number of bits (bits) of either > > What is the purpose of the “(bits)” that follows the “number of bits”? > > > status[0] = 1 > status[1] = 0 > : > > You might want to explicitly state what the values of 0 and 1 mean, or at > least reference section 7.1 that defines these values. Agreed, we should probably link to the status value definition from here > 8.1. Status List Request > > The HTTP endpoint SHOULD support the use of Cross-Origin Resource Sharing > (CORS) [CORS] and/or other methods as appropriate to enable Browser-based > clients to access it. > > Maybe explicitly state that it is the Status Provider endpoint: > “The Status Provider HTTP endpoint SHOULD…” > > I am assuming the above use of SHOULD is to address a use case where a > browser-based clients are not supported? If this is the case, then I think it > would be clearer if you explicitly state that. I would say that was part of the motivation - not every ecosystem will have browser-based clients and it can be conscious choice to not CORS. Another reason was that we looked at other specifications with similar properties and the ones I found all seem to use SHOULD as well (e.g., userinfo for odic). Mainly trying to stay consistent with other specs in the space. > The Relying Party SHOULD send the following Accept-Header to indicate the > requested response type: > • "application/statuslist+jwt" for Status List Token in JWT format > • "application/statuslist+cwt" for Status List Token in CWT format > > What is the implicit type? > Why not a MUST to guarantee interop between the RP and the Status Provider? I would expect most ecosystems to choose a default format (and not offer both), so enforcing this felt not necessary if within an ecosystem that choice is known to the client. I do agree though, that it might be cleaner to switch into a MUST since there seems to be very little cost to enforcing this? > 8.2. Status List Response > > If caching-related HTTP headers are present in the HTTP response, Relying > Parties SHOULD prioritize the exp and ttl claims within the Status List Token > over the HTTP headers for determining caching behavior. > > The above implies that there are cases where the RP can prioritize the TTL > values in the HTTP headers. When can the RP do that? This should probably become a MUST. > 9. Status List Aggregation > > 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. > > Are there cases where the RP will not continue the processing of the rest of > the lists when it encounters an invalid list? An implementation might choose to stop and retry later - continuing to process the other entries seems like the most reasonable behaviour here, but I don’t see a reason for a MUST since it doesn’t affect interop. > VICAL extension for ISO mDoc / mDL. > > Add a reference to this extension. We can reference VICAL (18013-5), a specific extension does not exist currently as far as I know - mdl currently embed aggregation_uri into the status object itself (in the issuer signed token). > This aggregation in JSON and the media type return SHOULD be > application/json. > > Why is this a “SHOULD”? We had returning media types as a SHOULD initially (since several people brought up concerns that hosting with CDNs might be problematic otherwise) and switched to a MUST after more discussions after one of the previous IETFs. I think this is a residue and should be changed to a MUST. > 10. X.509 Certificate Extensions > > Since you have only one subsection, 10.1 Extended Key Usage Extension, you > might want to drop the subsection? Agreed > 11. Security Considerations > > 11.1 Correct decoding and parsing of the encoded Status List > > This section discusses implementation issues. > Should this be moved to section 13. Implementation Considerations? We wanted to make sure people understand that simple parsing errors can have serious consequences from a security perspective, but I agree that could as well be in the implementation considerations section. > 13.2. Default Values and Double Allocation > > Implementations producing Status Lists are RECOMMENDED to initialize > the Status List byte array with a default value and provide this as > an initialization parameter to the Issuer. The Issuer is RECOMMENDED > to use a default value that represents the most common value for its > Referenced Tokens to avoid an update during issuance. > > I am not sure that I understand what the above text is trying to say. > Why is initialization needed? Why is it RECOMMENDED? What does “most common > value” mean? We have seen implementations that initialized status lists with random values, which negates almost all benefits from compression. The default value for most use-cases should be 0x00 (VALID) and should be used to initialize the status list (but there might be other cases where another status value is the default/starting point). I agree that we should improve the text to make it more clear though. > Implementations producing Status Lists are RECOMMENDED to prevent > double allocation, i.e. re-using the same uri and index for multiple > Referenced Tokens. The Issuer MUST prevent any unintended double > allocation by using the Status List. > > Why does the first part use RECOMMENDED, while the second part uses MUST? There might be cases where an Issuer wants to re-use an index/status entry (the same status shared by different tokens), which is dangerous and people should know exactly when they are doing that —> recommendation to not do it, but this would still be a conscious choice by the IdP/Issuer (and there are cases where this makes sense). The Status List Issuer (the system creating the status list token and entries within it) MUST make sure that it does not unintentionally assign the same index several times (without the intent to do so by the Issuer). We probably need to improve the wording here as well > 13.6. Status List Update Interval and Caching > > “Both ttl and exp are RECOMMENDED to be used by the Status Issuer.” > > This implies that a Status Issuer might not include any of these claims. If > this is the case, then what is the expected behaviour of the RP? `iat` is required and can always be used to check freshness (with a custom time policy by the RP). This is also described in 8.3 Validation rules: "If the Relying Party has custom policies regarding the freshness of the Status List Token, it SHOULD check the issued at claim (iat or 6)" > Nits > ==== > > 6.1. Status Claim > > The claim contains members used to reference to a > Status List Token as defined in this specification. > > Drop the “to” after “reference” > > > 8. Verification and Processing > > “In the following section is described from…” > > Drop the “In” at the beginning of the sentence. > > > 11.3 Key Resolution and Trust Management > > or ecosystems that are planning ot make use of the Status List… > > “ot” -> “to” Agreed on all of them, should be fixed. > Regards, > Rifaat > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
