**Session Date/Time:** 11 Dec 2023 16:00

# [SCITT](../wg/scitt.html)

## Summary

The SCITT Working Group completed its Working Group Last Call (WGLC) for the use cases document, with an understanding that minor edits may still be incorporated. Core documents are progressing rapidly towards adoption at IETF 119, with a focus on simplification and issue triage. Key discussions included streamlining the architecture document by moving API specifics to the Scrappy repository, integrating key binding mechanisms to support three-party delegation models, and determining the optimal API payload encoding (CBOR vs. JSON wrapper) to balance interoperability, tooling support, and design principles.

## Key Discussion Points

*   **Use Cases Document WGLC**: The WGLC has concluded, and while the document is considered complete for review, it will not be permanently frozen, allowing for future updates.
*   **Core Documents Status**: Editors reported significant progress, including merging numerous Pull Requests (PRs) and cleaning up remnants from IETF 118. Issues have been triaged from approximately 40 down to 18. The goal is to achieve a stable state for adoption at IETF 119. Efforts are focused on simplification, such as consolidating on a single claims header and clarifying non-mandatory registration information.
*   **Architecture Document Simplification (PR 139)**: There was a discussion regarding PR 139, which proposes removing extensive API-related text from the architecture document. The intent is to allow the architecture document to progress more quickly by shifting detailed API descriptions to the Scrappy repository, where they can iterate faster.
*   **Scrappy API Development and Key Binding (PR 9)**:
    *   The Working Group agreed to accelerate iteration on the Scrappy API within its dedicated repository.
    *   Arie highlighted the importance of accommodating a "three-party model" for credential verification, where the party registering an attestation (e.g., an integrator) is a *holder* of a credential issued by an original party, rather than the original issuer itself. This contrasts with a "two-party model" where the issuer knows the verifier.
    *   This model utilizes "confirmation claims" (`cnf`) to allow the holder to cryptographically prove possession of a key bound to their credential.
    *   This capability is crucial for use cases involving delegated authority in both software and physical supply chains, preventing the transparency service from needing to manage identity policies directly. It was affirmed that this proposal does not overlap with Role-Based Access Control (RBAC), which is an orthogonal concern.
*   **API Payload Encoding (CBOR vs. JSON Wrapper)**:
    *   A significant discussion focused on the Scrappy REST API's payload encoding. While COSE/CBOR is preferred for its compactness and adherence to standards for the core signed statements and receipts, implementers have found challenges with standard tooling and network traversal when dealing with raw binary application types in REST APIs.
    *   The practice of Base64URL encoding COSE/CBOR into a JSON wrapper for API requests/responses has proven more convenient for tooling and robust against network intermediaries.
    *   Arie suggested defining acceptable media types for the API, with a preference (potentially controversial) for making JSON the mandatory default, allowing raw CBOR as an optional alternative, to boost API adoption due to better off-the-shelf tooling support for JSON.
    *   Conversely, some participants argued that CBOR should remain the mandatory fundamental encoding, with JSON as an optional wrapper, and that tooling should be developed to support raw CBOR.
    *   Ray suggested that any wrapper, especially for CBOR, should be minimal (e.g., indicating version and content type) to aid development and allow future flexibility without introducing too many options.

## Decisions and Action Items

*   **Decision**: The Working Group Last Call for the Use Cases document is considered complete for its current state, acknowledging that minor edits may still be incorporated, and the document is not permanently frozen.
*   **Decision**: PR 139 (Architecture Document Simplification) will be merged to streamline the architecture document by moving detailed API descriptions to the Scrappy repository, enabling faster iteration on API specifics.
*   **Decision**: The Scrappy repository will serve as the primary location for rapid iteration and detailed development of the SCITT API, including the proposed key binding mechanisms.
*   **Action Item**: Editors and contributors are to continue triaging open issues and merging Pull Requests in the core documents to prepare them for adoption at IETF 119.
*   **Action Item**: Further discussion and refinement of the API payload encoding strategy (defaults, mandatory vs. optional CBOR/JSON) will continue within the Scrappy repository, aiming to balance interoperability, tooling support, and core design principles.

## Next Steps

*   Continue active development and refinement of the Scrappy API within its dedicated GitHub repository, particularly addressing the API payload encoding strategy and the integration of key binding mechanisms.
*   Progress the core SCITT documents towards a state ready for adoption at IETF 119.
*   Maintain engagement on open issues and PRs on GitHub.