**Session Date/Time:** 10 Nov 2022 17:00

# tigress

## Summary
The tigress working group met to discuss the latest updates to the draft specification for transferring digital credentials securely. The main focus was on the requirements document, incorporating feedback received from IETF 114 and the mailing list. The group discussed assumptions, requirements grouped by connectivity, transfer data, security & privacy and the role of the intermediary server.  There was discussion around privacy, attestation and trusting intermediaries, as well as strategies for versioning.

## Key Discussion Points

*   **Assumptions:** The group discussed the assumptions underlying the proposed solution, including the credential provider's control over credentials, user revocation rights, and the need for secure communication channels.
*   **Requirements:**  A detailed review of the defined requirements, covering connectivity (online/offline operation), transfer mechanisms (any messaging channel), transfer data (arbitrary format, round trips, preview), and security/privacy (confidentiality, integrity, availability, revocation).
*   **Intermediary Server:** Discussion on the privacy implications of using an intermediary server, specifically the need to prevent correlation of users and the use of attestation for trust.
*   **Privacy vs. Use Case:**  The discussion highlighted the difference in privacy requirements between use cases (e.g., car sharing vs. hotel room access), and the impact of existing standards (like CCC for car keys) on privacy. Alex clarified the intended privacy scope to just the intermediary. There were concerns about this scope which may need to be clarified in the requirements document.
*   **Trust Lists:**  Concerns were raised about the control of trust lists for intermediary servers, with some advocating for user control over these lists.
*   **Requirement of Intermediary:** Clarification was provided that the protocol wouldn't always require an intermediary, it could be extended to direct device to device communication.
*   **Versioning:** Discussion around versioning and compatibility with early implementations, with the current design relying on URLs to indicate the version.

## Decisions and Action Items

*   **Action Item:** Authors to incorporate feedback on the requirements draft, including comments from Ecker, Yaron and Alex, and update the draft. This includes clarifying the scope of the privacy requirements.
*   **Action Item:** Authors to open a GitHub issue regarding the privacy scope.
*   **Decision:** After incorporating feedback, the working group will consider an adoption call for the requirements draft.
*   **Action Item:** Consider a hackathon session in Yokohama to further test and refine the specification.

## Next Steps

*   Authors will update the requirements draft based on feedback.
*   The working group will continue the discussion on the mailing list.
*   The group will consider adoption of the requirements draft.
*   The possibility of a hackathon in Yokohama will be explored.