| Internet-Draft | cryptovolense | January 2024 |
| Steele | Expires 5 July 2024 | [Page] |
Digital presentations enable a holder of digital credentials to present proofs to a verifier. Using QR Codes for digital presentations introduces challenges regarding maximum transmission size, error correction and confidentiality. This document describes a generic optical transmission protocol suitable for digital credential presentations.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://OR13.github.io/draft-steele-spice-cryptovolense/draft-steele-spice-cryptovolense.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-steele-spice-cryptovolense/.¶
Discussion of this document takes place on the Secure Patterns for Internet CrEdentials Working Group mailing list (mailto:spice@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spice/. Subscribe at https://www.ietf.org/mailman/listinfo/spice/.¶
Source for this draft and an issue tracker can be found at https://github.com/OR13/draft-steele-spice-cryptovolense.¶
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 5 July 2024.¶
Copyright (c) 2024 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.¶
The data density limitations of a single QR Code can be overcome through the use of animated QR Codes, where each frame of the animation is a valid QR Code.¶
Because QR Codes were originally developed to support transmission of text, not binary, it is desirable to apply specific base encoding, compression and forward error correction, to provide a generic binary content transmission capability through animated qr codes.¶
[RFC6330] describes a fully specified error correction scheme, [RFC9285] describes an optimal base encoding for QR Codes, and [RFC2397] describes a content identifier scheme suitable for encoding binary data of a known content type.¶
This document describes how to use these ingredients to transmit arbitrary content of a known type from a sender to a receiver through the presentation of an animated QR Code by the sender to the receiver.¶
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.¶
message:The data (bytes / octets) to be transmitted.¶
message data url:The message encoded as a data URL, including its content type.¶
transmission configuration:The raptor q details necessary to recover the message data url from a series of raptor q packets.¶
transmission packets:The raptor q packets produced from the message data url interpretted as bytes.¶
compressed transmission packets:The transmission packets compressed by a protocol parameter "compression algorithm".¶
base encoded transmission configuration:The base45 encoded transmission configuration (without compression).¶
base encoded transmission packets:The base45 encoded compressed transmission packets.¶
qr encoded transmission configuration:The base encoded transmission configuration expressed as an image, for example image/svg+xml or image/jpeg.¶
qr encoded transmission packets:The base encoded transmission packets expressed as images, for example image/svg+xml or image/jpeg.¶
transmission images:The unordered set of images composed of qr encoded transmission configuration and qr encoded transmission packets.¶
animated transmission image:An animated image, constructed from a frame and duration for each of the transmission images, represented for example as image/gif, or image/webp.¶
Although this document describes a generic data transmission capability, the primary motivating use case for developing this approach is transmission of large encrypted credential presentations, post quantum capable public keys, and hybrid public keys.¶
Large binary data can quickly exceed the limitations of single QR Code presentations, motivating a need for animated qr codes and forward error correction capabilities.¶
The sender MUST prepare their message for transmission by first encoding their data as a message data url according to the process described in [RFC2397].¶
Next, the message data url MUST be converted to bytes, and the Raptor Q encoding algorithm described in [RFC6330] must be applied.¶
The result is transmission configuration as bytes, and transmission packets as bytes.¶
Edtiors note: We might need to define a content type for transmission configuration, ending in +json or +cbor.¶
In cases where this protocol is used with static transmission configuration, those details may be hard coded or discovered through some reliable out of band mechansism.¶
Editors note: We may want to define fountain code agility, such that coding schemes other than RaptorQ can be used.¶
Next, the packet bytes produced by [RFC6330] are compressed using gzip as described in [RFC1952] or zstd as described in [RFC8878].¶
Edtior note: Need to decide if compression agility is valuable, how to signal it, or which compression scheme to require.¶
Next, the transmission configuration and compressed transmission packets are encoded using [RFC9285].¶
Finally, the base encoded transmission configuration and base encoded transmission packets are converted to QR Codes, and each of the transmission images is used as a frame in the resulting animated QR Code.¶
The receiver MUST read the frames of the animated transmission image, storing each unique base45 encoded text string.¶
Once the transmission configuration has been recovered, the recovery of the original message data url can be attempted using [RFC6330].¶
The recovery process ends when either:¶
The transmission configuration MAY include additional data elements, for example the compression algorithm, or public key discovery related meta data in the case that authenticated encryption capable content types are transmitted, for example auth mode hpke as described in [I-D.draft-rha-jose-hpke-encrypt] or [I-D.draft-ietf-cose-hpke].¶
In the case the transmission configuration contains parameters beyond what are required by [RFC6330], it should be encoded as a data url, with a content type expressing the serialization of the parameters, for example appliation/json or application/cbor.¶
data:application/cose;base64,SGVsb...xkIQ==
The transmission configuration, and other protocol parameters, such as supported compression or encryption algorithms MAY be discovered out of band.¶
Note to RFC Editor: Please remove this section as well as references to [BCP205] before AUTH48.¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [BCP205]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to [BCP205], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
An open-source implementation was initiated and is maintained by the Transmute Industries Inc. - Transmute, and is available at:¶
An application demonstrating these concepts is available at https://transmute.codes.¶
The code's level of maturity is considered to be "prototype".¶
The current version ('main') implements the transmission and recovery algorithms of this draft.¶
The project and all corresponding code and data maintained on GitHub are provided under the Apache License, version 2.¶
The implementation uses a wasm module, built from this rust implementation of RaptorQ [RFC6330], maintained at: - cberner/raptorq¶
Several other dependencies are used, but the RaptorQ implementation is the most relevant.¶
TODO Security¶
When encrypting data to a public key, it is important that the sender believe the corrosponding private key is under exclusive control of the receiver. There are many different mechanisms for delivering a public key to a sender, such that the sender can be assured of this property. A detailed analysis of identifier to public key binding, and recommendations suitable for use cases is outside the scope of this document.¶
Note that [RFC6330] and [RFC9285] and Base64 as used in [RFC2397] are encoding schemes, NOT encryption schemes, and they provide no confidentiality.¶
Because the data that is encoded within QR Codes is visible to any system that can see the images, any sensitive data should be encrypted before transmission.¶
In the context of this specification, this means the message data url MUST include a content type for an encryption envelope, suitable for the confientiality requirements of the use case.¶
In the case that an encrypted message is transmitted as a Data URL, the content type of the message MUST be registered [IANA.media-types], for example application/jose might be used to transmit a JSON Web Encryption as described in [RFC7516], and application/cose might be used to transmit a cose encrypt envelope as described in [RFC9053].¶
It is recommended that encryption envelopes supporting multiple key agreement and content encryption schemes ensure that ciphertexts commit to the specific keys and algorithms used.¶
Additional context binding such as external aad in HPKE might be useful to achieve this.¶
WICG/identity-credential discusses a similar proposal related to invoking a presentation from a mobile device running a mobile operating system, to a browser requesting a presentation on behalf of a web origin.¶
It is possible that some content types could be shared between this browser API use case, and the QR Code transport use case.¶
It is possible to transmit animated QR Codes from a holder's handheld device to a verifier's camera / scanner, and to transmit animated QR Codes over an established video channel. Additional security guidance is required regarding replay attack and proxy attacks on in person and remote presentations, that is beyond the scope of this document.¶
This document has no IANA actions.¶
TODO acknowledge.¶