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

# [SECRET](../wg/secret.html)

## Summary

The SECRET BOF convened to discuss the problem of securely transferring digital credentials (e.g., car keys, hotel keys, home access) between individuals across different device platforms and credential verticals. The proponents presented a problem statement, use cases, and proposed requirements for a standardized, asynchronous transfer mechanism that emphasizes security and user privacy, without dictating underlying credential provisioning or usage protocols. There was strong consensus that the problem is well-understood and merits IETF attention. Sufficient interest and willingness to contribute to a working group were demonstrated, leading to a recommendation to the IESG to form a working group to develop a solution.

## Key Discussion Points

*   **BOF Goals**: The chairs, Leif and Sean, outlined the BOF's objectives: to ensure the problem statement and use cases are well-understood, confirm the IETF is the appropriate venue, gauge interest in participation (draft editing and review), and gather initial feedback on proposed charter text. Special emphasis was placed on ensuring sufficient security expertise would be involved.
*   **Problem Statement**: Matthew, a proponent, introduced the core problem: users store digital credentials (payments, transit, access, car keys) on smartphones from various manufacturers and operating systems. A standardized, cross-platform, and cross-vertical method for users to securely share these digital credentials with other individuals is currently lacking.
*   **Credential Types**: Discussion clarified that credentials could be symmetric (e.g., MIFARE DESFire applets for hotel access) or asymmetric (e.g., Car Connectivity Consortium (CCC) digital car keys, ISO 18013 mobile driver's licenses). A key security principle highlighted by Richard was that private keys (for asymmetric) or symmetric secrets should never leave the originating device; instead, the transfer mechanism should authorize the recipient to provision or register a *new* credential on their device.
*   **Assumed Constraints**:
    *   The proposed solution focuses solely on the *transfer* of authorization, not on dictating how credentials are provisioned, managed, or used by the underlying platforms and protocols (e.g., ISO 18013, CCC, MIFARE DESFire).
    *   The transfer mechanism must support *asynchronous* operations, allowing the sender and/or receiver to be offline at various points during the multi-step transaction, completing when devices reconnect.
    *   High priority on security and privacy aspects of the transfer operation.
    *   It's not possible, nor desirable, to simply transfer existing credentials (e.g., private keys) due to hardware-backed security primitives and cryptographic best practices. The sender authorizes the recipient to obtain a *new* credential, potentially with a subset of the sender's privileges (e.g., valet mode for a car key).
    *   The transfer must comply with existing cryptographic requirements of underlying credential standards (e.g., CCC requiring the owner's private key to sign the recipient's public key).
    *   The transfer should be agnostic to the communication channel used to convey the "link" or "voucher" (e.g., SMS, email, proprietary messaging apps).
*   **Use Cases (Casey)**: Specific examples were provided across vehicle, home, and hotel access scenarios, illustrating needs for:
    *   Full/restricted access.
    *   Time-bound or indefinite access.
    *   Asynchronous sending/receiving when one party is offline.
    *   Fine-grained access control (e.g., valet access, garage door restrictions) is assumed to be handled by the underlying credential system, not the transfer protocol itself.
*   **Revocation**: Richard raised the important scoping question of revocation. Proponents (Matthew, Mathias) acknowledged the need for revocation but noted it is often a distinct mechanism, dependent on the credential type and authority (e.g., transit systems updating deny lists, car OEMs managing key deletions with security constraints). This was flagged as a key scoping discussion for a potential WG.
*   **Privacy Requirements (Dimitri)**: The solution must ensure that private user information (who shared, what credential, when, for how long) is not collected or tracked by the transfer solution itself, preventing the building of social graphs. Eric questioned the extent of this concealment (e.g., IP addresses, public keys). Proponents explained their approach: data is encrypted by the sender with a symmetric key, sent to a relay service, and the symmetric key is sent via a URI fragment in the link to the recipient, ensuring the relay server cannot decrypt the content. The first recipient to claim the transfer (e.g., via a unique UUID) typically "wins."
*   **Relay Server Role**: Mathias clarified that the relay server's security properties are minimal; its primary role is to ensure one-time delivery of the encrypted credential data to the first legitimate receiver and potentially offer DDoS protection. The encryption should be strong enough that the relay server cannot decrypt the data.
*   **Credential Discovery/Negotiation**: Matthew stated that the protocol should not act as an "oracle" to query a recipient's device capabilities for privacy reasons. Instead, the receiving device's operating system or application would inform the user if a received credential type is not supported (e.g., due to software, hardware, or OS implementation). Metadata indicating the *type* of credential being shared was suggested and added to the draft.
*   **Community Interest**: Nick (Google) confirmed Google's involvement as a proponent, noting interest from car manufacturers (via CCC). Matthew confirmed Apple's heavy representation in the effort.
*   **Area Placement (ART vs. SEC)**: John asked if the work was primarily security or applications, noting extensive security discussion. Francesca (ART AD) and Ben (SEC AD) confirmed cross-area interest and noted that the work straddles both areas. They committed to joint AD oversight regardless of the final area placement, ensuring adequate expertise. Richard argued for ART due to application transport and design elements, with security being a core protocol element.
*   **Charter Text Discussion**:
    *   Michael suggested changing "share a digital credential" to "delegate a credential" for semantic accuracy, as keys are not literally transferred.
    *   Steven found the "out of scope" language unclear and questioned the required depth of knowledge about underlying credential mechanisms. Proponents clarified that while familiarity is useful, intimate knowledge of specific credential weaknesses might not be a prerequisite for working on the transfer protocol due to its agnostic nature. Eric suggested a non-normative document detailing assumptions about underlying credentials might be useful.
    *   Eric suggested distinguishing the work from a generic data tunneling protocol and further clarifying the asynchronous communication requirements, particularly regarding round trips.
    *   Ben raised standardizing on "person" or "user agent" terminology.
    *   Eric commented on the "privacy goals" section of the charter text, suggesting they be rephrased to be more protocol-oriented (e.g., "deny information" rather than "not collect or track").
    *   Casey inquired about including references to existing open standards (CCC, ISO 18013) in the charter to contextualize the work's constraints. The chairs agreed this would be helpful, perhaps in a separate paragraph about interactions with other SDOs.
    *   Eric also questioned the draft charter text's statement about a specific draft as a "starting point," suggesting "input" might be more appropriate to allow for broader architectural discussion in a WG.

## Decisions and Action Items

*   **Problem Understanding**: A show of hands indicated a strong consensus among participants that the problem is well understood.
*   **IETF Appropriateness**: A subsequent show of hands revealed strong consensus that the problem space is worth solving in the IETF.
*   **Participation**:
    *   Approximately 8 individuals indicated willingness to **edit drafts**.
    *   A larger number of individuals indicated willingness to **review drafts**, with roughly equal distribution when categorized as "Applications" (ART/Apps) or "Security" (SEC) experts.
*   **Recommendation to IESG**: The chairs concluded that there is sufficient consensus and interest to recommend to the IESG that a working group be formed to address this problem space.

## Next Steps

*   **Charter Refinement**: The BOF chairs, proponents, and Area Directors will continue to refine the charter text offline, incorporating feedback from the BOF discussion (e.g., exact wording for "sharing" vs. "delegating," clearer scope boundaries, precise privacy goals, asynchronous communication requirements, inclusion of SDO references, and wording regarding initial draft adoption).
*   **WG Formation**: The BOF chairs will formally recommend to the IESG that a working group be established based on the strong consensus and demonstrated community interest.