Markdown Version | Session Recording

Session Date/Time: 08 May 2023 15:00

SCITT

Summary

The meeting focused on three primary areas: a review of the recent IETF 116 Hackathon, an in-depth discussion on the use of Decentralized Identifiers (DIDs) within SCITT, and planning for upcoming work, specifically the IETF 117 Hackathon and the next working group meeting. Key outcomes included confirmation of successful interoperable COSE receipt implementations at the hackathon, a decision to focus the next hackathon on registration policy, and an action item to draft clarifying text on DID methods for the architecture document.

Key Discussion Points

• IETF 116 Hackathon Review:

  • A successful hackathon demonstrated interoperable implementations of the minimal COSE receipt format, with three independent implementers (Microsoft, Transmute, and a team from John's company) achieving cryptographically verifiable, end-to-end SCITT receipt generation and verification.
  • The test client and server emulator (Microsoft open-source project) were instrumental.
  • The quality of the specification was also tested, with new implementers successfully following the draft architecture.
  • Challenges identified included changes to the Microsoft open-source emulator team and ongoing work on federation and future-proofing.
  • A link to the hackathon readout and the open-source repository was shared in the chat for reference.

• Ledger Auditability:

  • Ray raised the need for deeper auditability of append-only logs.
  • Discussion revolved around the balance between prescribing specific audit mechanisms (e.g., Merkle trees, blockchain-based systems) and stifling innovation.
  • A general sense of those present indicated a preference for not overly prescribing technical details of ledger audits, but rather focusing on high-level operational or key integrity requirements. It was suggested this could be addressed by adding requirements to the SCITT security target.

• Decentralized Identifiers (DIDs):

  • Hannes summarized the previous mailing list discussion, highlighting DID Key and DID Web methods as potential candidates for SCITT, noting both are still working drafts and DID Key is less mature.
  • The DID Web method was described as using a domain name to host a DID document containing public keys, which would be retrieved by a SCITT ledger for signature verification.
  • Ori provided context on DID Resolution, which converts a DID URL into a DID document, noting the W3C standardization process is currently stalled due to political and process issues, with no clear timeline (possibly years) for a stable DID method specification from W3C.
  • A participant (Hank) suggested that SCITT might need to define its own DID flavor or provide clear guidance if W3C progress remains slow, emphasizing the need for flexibility beyond PKIX.
  • The relationship between DIDs and existing PKI/certificates was discussed. It was noted that certificates could be nested within DID documents, but implementers would face complexity in handling both, suggesting a choice between one or the other as the primary identity primitive.
  • The use of OIDC for REST API authentication within the hackathon implementations was briefly explained, differentiating it from core identity primitives.
  • The challenge of defining how SCITT specifically uses DID methods, elaborating on security properties, and detailing the interaction with PKI was identified.

• Registration Policy:

  • Roy emphasized the importance of a "gatekeeper" function – a registration policy – to ensure that only valid or sensible signed statements are accepted into the transparency server.
  • This policy must be auditable, meaning the policy in place at the time of acceptance should be indicated in the receipt for future verification (deep audit).
  • The need to explore existing, prominent JSON-based policy languages was highlighted, avoiding the creation of a new one.

Decisions and Action Items

• Hackathon (IETF 117) Focus: The primary focus for the next hackathon will be the Registration Policy.
  • Specific Use Case Proposal: A participant (Dick) proposed demonstrating how SCITT can be used to supply consumers with software trust scores as a simple use case for the hackathon.
• Next Weekly Call Topic: The next meeting will focus on the Registration Policy.
• DID Methods Clarification: A small group of interested and knowledgeable participants will draft text for the existing SCITT architecture document to clarify how SCITT plans to use DID methods, their security properties, and their relation to existing PKI. This will also be a potential activity for the hackathon.
  • Volunteers/Interested: Dick expressed interest, and will discuss with his team.
• Hackathon Participation: An appeal was made for more participants to join the hackathon planning and development, with existing interest from Dick, John, Ori, Ray, Hank, and Roy.
• Implementation Links: John to ensure links to existing SCITT implementations and tooling (e.g., client code, emulator) are available on the working group's related implementations section or a testbed page.
• OIDC Documentation: John and Dick will discuss documenting the use of OIDC for REST API authentication in SCITT, potentially adding it to the architecture document or README files of open-source projects.

Next Steps

• The chairs will send out an email to the mailing list seeking further volunteers and planning for the IETF 117 Hackathon.
• Interested participants in drafting the DID methods clarification text for the architecture document should coordinate.
• The chairs will update the meeting invite and agenda for the next call to focus on the Registration Policy.