**Session Date/Time:** 13 Feb 2023 16:00

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

## Summary

The meeting focused on two main topics: finalizing the use case document and discussing identity management. Significant progress was reported on the use case document, with a plan to publish a first version soon, pending the integration of a specific firmware verification use case and the resolution of minor editorial items. The discussion on identity management explored the role of OpenID Connect (OIDC) for authentication, the challenges of diverse identity types (from individual open-source contributors to large corporations), and the fundamental question of how identity and trust relate to claims made within the SCITT ledger.

## Key Discussion Points

### Use Case Document Progress

*   Most open issues have been addressed, and harmonization efforts have been made to ensure consistent language throughout the document.
*   A "firmware verification" use case proposed by Monty sparked a detailed discussion regarding its unique aspects. The core of this use case involves "after-the-fact" verification of firmware, as opposed to pre-execution checks, especially in hybrid air-gapped environments (connected -> isolated update -> reconnected).
*   Participants discussed whether this use case was sufficiently covered by existing "multi-stakeholder" or "constrained device" use cases. The consensus leaned towards including it explicitly or ensuring clear references to make it obvious that such scenarios are accommodated by SCITT, preventing future re-debates.
*   Suggestions from another contributor (Ori) were pending due to their unavailability.

### Identity Management

*   The discussion on identity management was introduced by Johannes and Rifat from the OAuth Working Group. Rifat explained OpenID Connect (OIDC) mechanisms such as `acr` (authentication class reference) and `amr` (authentication methods references) which convey authentication strength and assurance levels in the ID token. He also mentioned ongoing work in OAuth on Step-Up authentication.
*   Participants highlighted the need for SCITT to accommodate a wide range of identity types, from potentially "weak" identities (e.g., individual open-source contributors identified via a Gmail address in Sigstore) to "strong" identities (e.g., large corporations or government entities).
*   The group discussed the challenge of linking an identity to the *semantic meaning* of an artifact, particularly in open-source contexts where multiple contributors might be involved and no single entity takes liability. For corporations (like Microsoft), linking identity to artifacts is conceptually simpler.
*   The concept of "Trust Declaration Types" was mentioned, implying SCITT might need to recognize different types of statements, each with specific validation criteria for an authorized party.
*   The fundamental question of "who runs SCITT" and how trustworthiness is established for the notary and transparency services was raised. It was noted that the authority of a claim derives from the identity of the issuer.
*   It was emphasized that SCITT's core mission is to assert, verify, and authenticate *who* made a statement, rather than intruding on the semantics of *what* is being said. The identity of the statement maker is paramount.
*   Hank clarified that SCITT's trustworthiness would be fueled by authenticity proofs provided by the nodes running SCITT (e.g., remote attestation via RATS) and other mechanisms like consensus protocols, which were initially kept out of scope to focus on transparency.

## Decisions and Action Items

*   **Use Case Document**:
    *   Monty will review his firmware use case pull request further, potentially integrating aspects or cross-referencing existing multi-stakeholder/constrained device use cases (e.g., sections 3.2 and 3.7).
    *   The existing "to-do" list in the document will be moved to the GitHub issue tracker.
    *   The missing architectural figure will be added to the document.
    *   The document will be submitted for adoption as a snapshot, with further iterations to follow.
*   **Identity Management**:
    *   The discussion on identity management, its challenges, and potential solutions will continue on the mailing list.
    *   Rifat will be provided with relevant SCITT architecture and use case documents to inform further discussion.

## Next Steps

*   The SCITT Working Group will publish a working copy of the architecture and use cases document this week.
*   These documents will be central to discussions at IETF 116.
*   Continue the technical discussion on identity management on the mailing list.