Internet-Draft | SpicyVc | December 2023 |
Steele | Expires 23 June 2024 | [Page] |
vCard is a file format for digital business cards.¶
This document enables vCards to be used as a transport for digital credentials.¶
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-vcard-credentials/draft-steele-spice-vcard-credentials.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-steele-spice-vcard-credentials/.¶
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-vcard-credentials.¶
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 23 June 2024.¶
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.¶
Public key based identity systems require users to obtain cryptographic keys, and use them to verify digital signatures produced by a private key, or decrypt data with a private key that was encrypted to a public key.¶
The public key cryptographic operations are a foundational building block for building secure systems capable of providing confidentiality, integrity and authenticity.¶
Applications supporting protocols such as OAUTH, OpenSSH, and OpenPGP rely on different public key formats.¶
To enable interoperability, useful public key formats have media types registered with IANA [IANA.media-types].¶
A common challenge in working with applications that require key management is obtaining cryptographic keys.¶
vCards as decribed in [RFC6350] can address this challenge, for keys that are embedded by value or by reference in digital business cards.¶
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.¶
vCARDs can be transported over various channels, including through NFC and QR Codes, as decribed in [RFC9285].¶
QR Codes are well supported in modern smartphones and frequently displayed on physical products, providing additional information to consumers.¶
Anyone who can see a QR Code can access the data encoded in it.¶
Sensitive plaintext data MUST NOT be encoded in vCARD QR Codes.¶
Encryption formats, such as JSON Web Encryption as decribed in [RFC7516] MAY be used to secure confidential credentials.¶
QR Codes can be removed, altered, or replaced on physical products, and in video streams.¶
Additional security checks MUST be performed before accepting any data transported by QR Codes.¶
For example, confirming serial numbers or other presented identifiers are consistent with the claims in credentials presented through the vCard QR Code.¶
In cases where a key is communicated by reference, and a service is used to dereference the key material, key transparency can mitigate threats related to duplicity, censorship, and consistency.¶
In the context of this document, key references are URIs.¶
Any key transparency system capable of deliverying key material for a URI as described in [RFC3986] MAY be used.¶
Section 6.8.1 of [RFC6350] defines how to embed a key in a vCARD.¶
The following informative example is provided:¶
In this example, the same credentials are encoded by value and by reference, and the fields "CATEGORIES", "UID" and "FN" are not integrity protected, software systems MAY leverage this property to alter these values, will preserving the integrity protected values.¶
The credential encoded by reference is using a URI built from a thumbprint using [RFC9278].¶
A verifiable credential, as defined in [I-D.draft-ietf-oauth-selective-disclosure-jwt] and [I-D.draft-ietf-oauth-sd-jwt-vc], is a special kind of public key, that a holder can prove possession of in order to convince a verifier, that an issuer has asserted attributes about a subject.¶
A verifiable credential, is a special kind of digital credential, defined in [W3C.VC-DATA-MODEL-2.0].¶
The following informative example is provided:¶
In this example, all fields except for "KEY" are not protected.¶
KEY encodes a verifiable credential expressing a hypothetical university degree.¶
Public credentials are often shared on social, or professional networks, however, they may still contain sensitive information which SHOULD NOT be disclosed such as student identification numbers, or other details about the credential subject.¶
This example is for demonstration purposes only.¶
TODO Security¶
Several layers of application processing occure before a integrity protected data can be verified.¶
The QR Code processing layer could have vulnerabilities that are exploitable before the vCard layer is even reached.¶
The vCard processing layer could have vulnerabilities that are exploitable before the credential can be selected.¶
The credential processing layer might require deserialization of parts or all of the encoded credentials before the verification process can occur.¶
After verification has occurred, the credential structure can be validated further, for example checking the lengths of strings, or ranges on integers expressing date times.¶
After all this validation, processing, verification and processing has occurred, the end result is the credential data as the issuer intended for it to be delivered to the verifier.¶
Implementations should avoid exposing unverified, unvalidated fields to users, because they can be altered without detection.¶
In cases were data is repeated without protection outside the credential, the guidance provided regarding unprotected headers in [RFC9052] and [RFC7516] MUST be followed.¶
This document has no IANA actions.¶
TODO acknowledge.¶