Internet-Draft tigress-requirements February 2023
Vinokurov, et al. Expires 26 August 2023 [Page]
Workgroup:
Transfer dIGital cREdentialS Securely
Internet-Draft:
draft-tigress-requirements-latest
Published:
Intended Status:
Informational
Expires:
Authors:
D. Vinokurov
Apple Inc
C. Astiz
Apple Inc
A. Pelletier
Apple Inc
B. Lassey
Alphabet Inc

Transfer Digital Credentials Securely - Requirements

Abstract

This document describes the use cases necessitating the secure transfer of digital credentials, residing in a digital wallet, between two devices and defines general assumptions, requirements and the scope for possible solutions to this problem.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://datatracker.ietf.org/doc/draft-tigress-requirements/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tigress-requirements/.

Discussion of this document takes place on the Transfer dIGital cREdentialS Securely Working Group mailing list (mailto:tigress@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tigress/. Subscribe at https://www.ietf.org/mailman/listinfo/tigress/.

Source for this draft and an issue tracker can be found at https://github.com/dimmyvi/tigress-requirements.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 26 August 2023.

Table of Contents

1. Introduction

In this document we are identifying a problem of transferring digital credentials (e.g. a digital car key, a digital key to a hotel room or a digital key to a private house) from a wallet on one device (smartphone) to another, particularly, if these devices belong to two different platforms (e.g. one is iOS, another - Android). Today, there is no widely accepted way of transferring digital credentials securely between two digital wallets independent of hardware and software manufacturer. This document describes the problem space and the requirements for the solution the working group creates.

A Working Group, called Tigress has been established to find a solution to the problem described above. Within the WG an initial solution was presented (https://datatracker.ietf.org/doc/draft-art-tigress). The community decided to generalize the requirements to the solution and consider alternative solutions within the WG.

This document presents the general requirements to possible solutions and specifies certain privacy requirements in order to maintain a high level of user privacy.

2. General Setting

When sharing digital secure credentials, there are several actors involved. This document will focus on sharing information between two digital wallets, directly or through an intermediary server.

Digital credentials provide access to property owned and / or operated by 3-rd party entities, such as hotel or residential building owners. The entity that is providing the digital credential for consumption by a digital wallet is referred to as the Provisioning Entity. For some kind of credentials, the Provisioning Entity may need to have control over digital credential issuance and life time management - for example, hotel is the owner of the rooms and allow guests to access them for the time of thier stay only.

A digital wallet is a combination of software and hardware in a smartphone device, there are two devices involved in credential transfer process - Sender and Receiver. They are defined in terms of which one is a transfer initiator (Sender) and which device is eventually consuming transferred credentials (Receiver). Device roles can change based on the transfer direction - in some transfers a device can act as a Sender, in other - as a Receiver.

The interface between the device and the Provisioning Entity can be proprietary or a part of published specifications. The sender wallet obtains provisioning information from the Provisioning Entity, then shares it to the recipient using a solution defined in Tigress WG. The recipient then takes that provisioning information and sends it to the Provisioning Entity to redeem for credential for consumption in a digital wallet.

For some credential types the Provisioning Entity who issues new credentials is actually the sender wallet. In that scenario the receiver will generate new key material at the request of the sender, and then communicate with the sender over Tigress to have its key material signed by the sender. The new credential, with the key material generated by receiver device and signed by sender device, will finally be added (provisioned) into a digital wallet on sender device.

2.1. Credential transfer without Provisioning Entity

mermaid sequenceDiagram actor S as Sender participant I as Intermediary actor R as Receiver S ->> I : upload Sharing Invititation ({{CCC-Digital-Key-30}}) break Generic messaging channel S ->> R : send invite end break Credential Provisioning flow {{CCC-Digital-Key-30}} R ->> I : upload Key Signing Request ({{CCC-Digital-Key-30}}) S ->> I : read Key Signing Request, generate and upload Key Import Request ({{CCC-Digital-Key-30}}) R ->> I : read Key Import Request and Import Key Data ({{CCC-Digital-Key-30}}) end

3. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

General terms:

4. Use Cases

5. Relationships

5.1. Credential transfer with intermediary server

mermaid sequenceDiagram actor S as Sender participant I as Intermediary actor R as Receiver S ->> I : upload provisioning information break Generic messaging channel S ->> R : send invite end loop Provision credential R ->> I : request additional provisioning information I ->> R : deliver additional provisioning information end

5.2. Credential transfer without intermediary

mermaid sequenceDiagram actor S as Sender actor R as Receiver break secure messaging channel S ->> R : transfer provisioning information E2E end loop Provision credential R ->> S : request additional provisioning information S ->> R : deliver additional provisioning information end

6. Assumptions

7. Requirements

8. Security Considerations

TODO Security

9. IANA Considerations

This document has no IANA actions.

10. References

10.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

10.2. Informative References

[CCC-Digital-Key-30]
Car Connectivity Consortium, "Digital Key Release 3", , <https://carconnectivity.org/download-digital-key-3-specification/>.

Acknowledgments

TODO acknowledge.

Authors' Addresses

Dmitry Vinokurov
Apple Inc
Casey Astiz
Apple Inc
Alex Pelletier
Apple Inc
Brad Lassey
Alphabet Inc