| Internet-Draft | tigress-requirements | February 2023 |
| Vinokurov, et al. | Expires 21 August 2023 | [Page] |
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.¶
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/.¶
Source for this draft and an issue tracker can be found at https://github.com/dimmyvi/tigress-requirements.¶
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 21 August 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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
¶
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:¶
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
¶
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
¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶