Markdown Version | Session Recording

Session Date/Time: 25 Jul 2024 20:00

scitt

Summary

This meeting focused on the progress of the SCITT architecture and API (Scrappy). Discussions centered on finalizing the architecture document, addressing open issues with Scrappy, and the need for clear guidance on profiling and protocol implementation beyond the core architecture. The group discussed various use cases, security considerations, and the role of SCITT in broader software supply chain security.

Key Discussion Points

• Architecture Document Finalization: Concerns were raised about relocating use cases into the architecture and whether the document sufficiently covers profiling and protocol concerns. The current state is near completion, but some open issues and Michael Richardson's feedback need addressing.
• Scrappy API Implementation: Scrappy is progressing, but the relying party workflow needs more attention. The current resolver based on hash is insufficient for scenarios involving multiple subjects or duplicate statements. It was proposed to focus on locating by issuer and subject, returning transparent statements.
• Opaque vs. Non-Opaque Payloads (Hash Envelopes): Discussion centered on the "opaqueness" of payloads when using hash envelopes, where the URI is in an unprotected header. Concerns were raised about the threat model and the need for consumers to validate the hash.
• Use Cases & Scope: The group reiterated that SCITT aims to provide generic building blocks for integrity, transparency, and trust and it is up to specific industries to define formats for subjects and content. Should there be a document covering how it all works for various industries.
• Security Considerations: Reviewing of the security implementation of hash envelopes. The consumer at the end has to validate the hash anyway.
• Profiling and Protocol Implementation: AJ raised concerns about profiling and protocol concerns are sufficiently covered by the architecture. There are concerns on how implementors will handle use cases around different identity and signing methods.
• Guidance Document: It was suggested a guidance document be written with examples for implementers to follow.

Decisions and Action Items

• Architecture Document:
  • Address open issues, including Michael Richardson's feedback on protocol and architecture separation.
  • Evaluate the inclusion of use case abstracts within the architecture document.
• Scrappy API:
  • Focus on improving the relying party workflow.
  • Investigate locator implementation using issuer and subject.

Next Steps

• Architecture Document: Aim for a working group last call for the architecture document (draft-ietf-scitt-architecture-08).
• Scrappy API: Continue development of Scrappy focusing on the Relying Party implementation.
• Mailing List Discussions: Discuss charter extensions and the possibility of an interim meeting to address open issues. Discussions about profiling and protocol interoperability should be held on the mailing list.
• Guidance Document: Investigate the creation of a guidance document outlining scenarios and implementations with SCITT.