Internet-Draft tigress-requirements July 2023
Vinokurov, et al. Expires 11 January 2024 [Page]
Workgroup:
Transfer dIGital cREdentialS Securely
Internet-Draft:
draft-tigress-requirements-10
Published:
Intended Status:
Informational
Expires:
Authors:
D. Vinokurov
Apple Inc
C. Astiz
Apple Inc
A. Pelletier
Apple Inc
Y. Karandikar
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 11 January 2024.

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 one device (e.g. smartphone) to another. 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.

A Digital Credential provides access to a property that is owned or rented by the user or operated by 3-rd party entities. The entity that provides the Digital Credential for consumption by a Digital Wallet is referred to as the Provisioning Entity.

For most credentials, the Provisioning Entity may need to have control over issuance and life time management of the Digital Credential - for example, hotel management allows guests to access rooms and amenities only for the duration of their booked stay.

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. The device that initiates transfer is termed as the Sender and the device that eventually consumes the transfer is termed as the Receiver. Same device can play different roles in 2 different transactions (Sender in one and Receiver in another).

The interface between the device and the Provisioning Entity can be proprietary or a part of published specifications. The Sender obtains Provisioning Information from the Provisioning Entity, then shares it to the Receiver using a solution defined in Tigress WG. The Receiver then takes that Provisioning Information and redeems the credential from the Provisioning Entity.

For some credential types the Provisioning Entity who issues new credential is actually the Sender itself(e.g. Digital Car key). In that scenario, the Receiver will generate new key material based on the Provisioning Information, then get it signed by the Sender. That requires one or more round-trips between Receiver and Sender over Tigress.

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

In all such cases, Sender should be able to transfer the Digital Credential in a seamless manner. Sharing of credential should feel equivalent to regular communication via instant messaging, email etc.

5. Relationships

5.1. Credential transfer with Intermediary server

Sender Sender Intermediary Intermediary Receiver Receiver upload Provisioning Information send invite loop [Provision credential] request Provisioning Information deliver Provisioning Information opt [Additional Data] additional data request Forward request additional data response forward response

5.2. Credential transfer without Intermediary

Sender Sender Receiver Receiver transfer Provisioning Information E2E loop [Provision credential] request Provisioning Information deliver Provisioning Information opt [Additional Data] Additional Data Request Additional Data Response

6. Assumptions

7. Requirements

8. Security and Privacy Considerations

9. General considerations

10. IANA Considerations

This document has no IANA actions.

11. 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>.

Acknowledgments

TODO acknowledge.

Authors' Addresses

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