**Session Date/Time:** 08 Nov 2023 12:00

# tigress

## Summary

The Tigris working group meeting at IETF 118 focused on the security properties of the invitation channel in credential transfer protocols. The discussion centered around whether to assume the introduction channel is secure, or to develop a more robust second-factor authentication mechanism. There was also considerable discussion on the applicability of OOMA and whether the core problem was delegation or copying keys. The group took polls to gauge support for various approaches, finding support for revisiting the fundamental assumptions.

## Key Discussion Points

*   **Security of the Invitation Channel:** Is it reasonable to assume the introduction channel (email, SMS, etc.) is secure enough for credential transfer, or should a stronger second factor be required?
*   **One-Time Use Semantics:** Discussion of ensuring that a credential can only be claimed once, even if the invitation is compromised.
*   **Second Factor Implementation:** Clarification needed on how the second factor should work (prevent credential issuance vs. making the credential unusable).
*   **Vertical-Specific Considerations:** Different verticals (e.g., car keys, hotel keys) have varying security and usability requirements, which may influence protocol design.
*   **OOMA Relevance:** Examination of whether delegated authorization patterns like OOMA could be applied.
* **Copying vs Delegation**: The core problem is it copying credentials of delegation of rights.
*   **Channel Binding:** Concerns over the potential for the protocol to need to build a new binding solution when OIDC and other well known protocols already have solutions.
*   **Credential Provisioning vs. Transfer:** Distinction between transferring a credential and activating/provisioning it for use.
*   **Is the whole effort an effort to re-invent existing message protocols** and there's nothing to be gained.

## Decisions and Action Items

*   **Continue Discussion on the Mailing List:** Further discussion is required, especially around defining the security requirements and assumptions related to the introduction channel and the second factor.
*   **Schedule Interim Meetings:** More than one interim meeting will be scheduled before IETF 119 to delve deeper into these issues.

## Next Steps

*   The working group chairs will post a summary of the discussion and the questions raised during the meeting to the mailing list.
*   The working group will consider documenting the existing work, and show how it relates to this problem and show how it either does or does not solve certain aspects of what's being requested here to make sure that everyone's starts with the same baseline of knowledge.
*   Interim meetings will be announced to facilitate further discussion and exploration of potential solutions.