**Session Date/Time:** 27 Jul 2022 19:00

# tigress

## Summary

This session introduced the Tigress working group's problem statement and a proposed solution for standardizing digital credential sharing across various platforms and verticals. The core problem identified is the lack of a standardized cross-platform, cross-vertical method for users to share digital credentials (e.g., car, home, hotel keys). The proposed solution centers around a "relay server" that facilitates short-lived, encrypted communication channels between sender and receiver devices, decoupling the transfer mechanism from credential provisioning logic. Discussion revolved around the scope, security, privacy, and general applicability of the proposed transfer protocol, leading to a decision *not* to adopt the initial draft as a working group document, pending further refinement and a clear requirements/problem statement document.

## Key Discussion Points

*   **Problem Statement**: Today, no standardized cross-platform, cross-vertical method exists to enable users to share digital credentials stored in wallets (e.g., hotel keys, car keys, home keys).
*   **Working Group Goals**:
    *   Minimize friction for cross-platform and cross-vertical sharing by defining simple APIs on top of existing protocols (e.g., HTTP), not creating new communication protocols.
    *   Maintain access control, ensuring senders approve recipients for a *subset* of their own access to facilitate minting a *new* credential, rather than sharing the exact same key.
    *   Meet security and privacy goals throughout the sharing process.
*   **Key Vocabulary Defined**:
    *   **Credential Authority (CA)**: Entity facilitating credential information lifecycle (provisioning, termination, update).
    *   **Credential Information**: Data used to transact with an access point (e.g., open a lock).
    *   **Provisioning Information**: Data structure transferred from sender to recipient, necessary and sufficient to provision a credential on the receiving device.
    *   **Sender Device**: Initiates transfer of provisioning information.
    *   **Receiver Device**: Receives provisioning information to provision with the CA.
    *   **Relay Server**: Intermediary server for transfer.
*   **Use Cases**: Car key sharing (e.g., loaning car, valet), home/residential key sharing (e.g., visitors, housekeepers), hotel key sharing (e.g., partner access, multiple guests).
*   **Requirements and Constraints for the Solution**:
    *   Sender initiates share over any communication channel (email, SMS, WhatsApp).
    *   Recipient views preview before accepting.
    *   Multiple round-trip communications within a limited time.
    *   Receiver requests additional provisioning information if needed.
    *   Does not require sender and receiver to be online simultaneously.
    *   Supports opaque message content (arbitrary formats, public standards like CCC, proprietary formats).
    *   Sender/receiver manage and interrupt transfer process.
    *   **Security**: Prevent bad actors from obtaining credentials during transfer; ensure only intended recipient provisions; anti-replay (provisioned once); sender intent/attribution.
    *   **Privacy**: Relay server should not learn sender/receiver information (aside from network metadata), create associations between shares, build a social graph, see sensitive details, or provision the credential itself.
*   **Out of Scope**: Defining the mechanism for receiver to provision with CA; mechanism for sender to get provisioning information from CA; user interface (UI) on sender/receiver devices; format for fields within encrypted data.
*   **Proposed Solution Overview**:
    *   **Core**: A "relay server" facilitates a short-lived, encrypted communication channel. All messages are encrypted (asymmetric) and opaque to the relay server.
    *   **Data Flows**:
        *   **Stateless**: Single unidirectional transfer (sender -> relay -> receiver). New credential generated by CA.
        *   **Stateful**: Multiple data transfers (ping-pong) for registration/provisioning (e.g., new key material generated by receiver, authorized by sender, as per CCC spec).
    *   **API**: `create mailbox` (sender uploads encrypted info, gets share URL), `read display information` (messaging app previews), `read secure information` (receiver downloads, decrypts), `update mailbox` (for stateful flow), `delete mailbox` (cleanup/cancel).
*   **Discussion during Q&A (Problem Statement & Solution)**:
    *   **Authorization vs. Transfer**: Clarified focus is on *transfer* of provisioning info, not authorization itself. Acknowledged different key types (symmetric/asymmetric) and granular control.
    *   **Credential Authority Control**: CA defines sharing policies (e.g., Hilton vs. car owner). This WG focuses on the *transfer* mechanism, not CA actions.
    *   **"Permissionless" Sharing / FIDO**: Protocol does not support permissionless sharing (e.g., giving website access without service provider permission); designed to prevent creation of share networks.
    *   **Relay Server Necessity**: Required for asynchronous communication channels (SMS, email) and user experience (avoiding exposing complex data directly).
    *   **Replay Attacks**: Aimed at preventing multiple recipients from claiming the same credential from a single share link without sender intent. Discussion on the role of trusted hardware/client-side logic and whether the relay or CA is ultimately responsible.
    *   **Generic Secret Message Transfer**: Distinguishes from generic file transfer by separating encrypted content from the link, avoiding pre-shared secrets, focusing on short-lived one-to-one exchanges, and supporting mobile offline scenarios.
    *   **Trust and Attestation**: Sender-relay trust can be established via device attestation (anonymous, generalized, implementation-dependent). Recipient trust relies on knowing the sender and using separate channels for verification. Relay servers might be "allow-listed" by verticals (e.g., CCC for car keys).
    *   **Channel Constraints**: Assumes limited capacity for out-of-band channels (e.g., ~100-240 characters for SMS), driven by user experience.
    *   **Abuse/Phishing**: Relies on sender's existing trust in the communication channel and the relay server's ability to provide a trusted preview. Delete mailbox API provides cancellation. Identity of sender/receiver is out of scope for the relay server.
    *   **Document Structure**: Significant feedback suggested a dedicated requirements document, including a clear threat model, constraints, and comparison to existing solutions to clarify the problem space.
    *   **"Mailbox" Terminology**: Participants questioned "mailbox" as it implies arbitrary mail and multi-message storage, suggesting it's more like a single-exchange point.
    *   **Relay Server Choice**: The choice of relay server is typically determined by the credential authority/application (e.g., Hilton uses Hilton's relay). A common URL scheme/prefix could allow recipient apps to handle shares from any relay server. Relay server can require attestation from senders but doesn't track identity.
    *   **Credential Recognition**: Devices recognize a share as a credential via URL query parameters (e.g., "vertical" type) and metadata within the encrypted provisioning information, or through universal link registration by an app.
    *   **Deployment Example**: A request was made for a full deployment example for a specific use case (e.g., car unlock) to illustrate how all pieces fit together.

## Decisions and Action Items

*   **Decision**: The working group did **not** reach rough consensus to adopt the current draft (`draft-ieft-tigress-secret-transfer`) as a working group document. The vote was approximately 50/50.
*   **Action Item**: The authors are requested to re-spin the draft document, incorporating feedback from this session.
*   **Action Item**: The authors are strongly encouraged to work on a separate **requirements document** that clarifies:
    *   The detailed problem statement.
    *   A clear threat model.
    *   Explicit constraints (e.g., on out-of-band channel capacity).
    *   Comparison to existing solutions (e.g., generic secure messaging).
    *   Specific use case deployment examples.
*   **Action Item**: Chairs and the responsible AD will discuss the document strategy for incorporating requirements and problem statements.
*   **Suggested Action Item**: Consider renaming the "mailbox" concept to better reflect its function (e.g., "exchange point").
*   **Suggested Action Item**: Explore standardization of a URL scheme/prefix to allow recipient apps to handle share links independently of the relay server's hostname.

## Next Steps

*   The authors will re-spin the draft and begin work on a separate requirements document, incorporating the feedback from this session.
*   The working group will hold another meeting in London to discuss the updated documents and progress.