**Session Date/Time:** 13 Jan 2025 17:00

# [OAUTH](../wg/oauth.html)

## Summary

The OAUTH Working Group met for a virtual interim to discuss the "Token Status List" draft. Paul and Christian presented a refresher on the draft's architecture and mechanism, followed by a detailed review of feedback received during the ongoing Working Group Last Call. Key discussions revolved around the clarity of roles, the need for comprehensive test vectors, strategies for partitioning status lists, and an extensive debate on the inclusion and implications of a "suspended" status value. The WG Last Call is expected to conclude this week, with further discussion on outstanding issues to continue on the mailing list.

## Key Discussion Points

*   **Token Status List (TSL) Refresher**: Paul and Christian presented the problem statement (conveying status of JWTs/CWTs), key features (scalable, privacy-aware revocation, simple implementation), and architectural overview. The TSL introduces a `status` claim in reference tokens, pointing to a Status List Token via a URI and an `idx` for a specific token's status. The Status List Token contains a `status_list` claim with `bits` (status granularity) and `lst` (encoded status array).
*   **External References**: The draft is referenced by SD-JWT, ISO 18035 MDOC amendment, and the eIDAS Architecture Reference Framework (ARF), indicating significant external interest and adoption.
*   **Separation of Roles**: Discussion on the explicit separation of Issuer, Status Issuer, and Status Provider roles. While seemingly complex, the authors justified this for specific use cases like mobile driving licenses (different entities for issuance vs. revocation) and scalability/privacy benefits (e.g., using CDNs for status list hosting). It was noted that the document could benefit from illustrating these motivational examples more clearly.
*   **Clarity of "Issuer" Terminology**: A concern was raised regarding ambiguity in the document's use of "issuer," which sometimes refers generally to all three roles, leading to confusion between the reference token issuer and the status list token issuer. A correction for consistent differentiation was requested.
*   **Test Vectors**: A poll of those present indicated a preference for including more extensive test vectors, covering various bit encodings, potentially moving current examples to an appendix. It was also suggested to consider external resources for complex examples beyond the RFC itself.
*   **Partitioning Status Lists**: Feedback suggested recommending partitioning status lists by token expiry to simplify their retirement. The authors acknowledged the benefit but raised concerns about potential privacy implications if partitioning leads to correlation. They plan to refine implementation considerations to advise on grouping tokens with similar expiration times when partitioning.
*   **Implementation Considerations for One-Time Use Tokens**: A proposal for a complete rewrite of the "Implementation Considerations" section was presented, focusing on strategies for one-time use tokens, including issuing status list tokens in advance, random index selection, using short-lived reference tokens, and automatic holder renewal. The authors noted that some of these concepts (pre-filling with noise, pre-creating lists) are already implicitly covered but recognized the need for clearer guidance.
*   **Short-Lived Credentials**: It was suggested to explicitly encourage the use of short-lived tokens in conjunction with the status list mechanism, similar to lessons learned from x509 CRLs. The authors agreed to add text to the rational section regarding this.
*   **Status Type Values and "Suspended" Status**: An extensive discussion revolved around the predefined status values (valid, invalid, suspended) and the `bits` mechanism.
    *   **Arguments for Predefined Values**: Authors stressed that predefined values (e.g., 0 as valid, 1 as invalid) are crucial for interoperability and to prevent "fuckups" where different ecosystems might interpret values differently, leading to security risks.
    *   **Debate on "Suspended" Status**:
        *   **Arguments for Inclusion**: Several participants advocated for a "suspended" status, citing use cases such as a user temporarily losing a smartphone (preferring suspension over immediate, irreversible revocation) or mobile driving licenses (allowing proof of identity/age but not driving). PKI history also showed a need for more than two states.
        *   **Arguments Against / Concerns**: Others expressed concerns about the "suspended" status due to practical difficulties (management, propagation across distributed systems, eventual removal from lists) and potential information leakage (e.g., revealing a temporary status). It was suggested that if "suspended" is kept, the document should clearly outline its implications and complexities.
    *   **Conclusion on "Suspended"**: A sense of those present indicated that the discussion on whether to keep "suspended," remove it, or extensively document its implications should continue on the mailing list.
*   **Well-Known URL**: Unclear feedback regarding a "well-known URL" to avoid tracking vectors was received. The authors suggested continuing this discussion on the mailing list.

## Decisions and Action Items

*   **Action Item**: Authors to clarify the distinction between "reference token issuer" and "status list token issuer" throughout the document.
*   **Action Item**: Authors to consider adding more comprehensive test vectors, potentially in an appendix, and explore the use of external resources for complex examples.
*   **Action Item**: Authors to refine "Implementation Considerations" regarding partitioning and explicit guidance for one-time use reference tokens.
*   **Action Item**: Authors to add a statement encouraging the use of short-lived credentials in the document's rational section.
*   **Decision**: The discussion regarding the inclusion, definition, and implications of the "suspended" status value will continue on the OAUTH mailing list.
*   **Action Item**: Authors to address all outstanding issues identified during the Working Group Last Call.

## Next Steps

The Working Group Last Call for the Token Status List document is ongoing and expected to conclude this week. Further technical discussions and resolution of outstanding issues, particularly concerning the "suspended" status and implementation considerations, will take place on the OAUTH mailing list. The authors will continue to update the document based on the feedback received.