| Internet-Draft | JSContact Extensions | April 2025 |
| Hallam-Baker | Expires 13 October 2025 | [Page] |
Extensions to the JSContact data model for contact card data are defined to provide improved support for describing cryptographic credentials to be used with applications and services and to provide support for authenticated updates to a contact card.¶
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 13 October 2025.¶
Copyright (c) 2025 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.¶
This document defines extensions to the JSContact data model for contact card data [RFC7553] to provide improved support for describing cryptographic credentials to be used with applications and services and to provide support for authenticated updates to a contact card.¶
The key design considerations for these extensions are as follows:¶
Maintain compatibility with the approach in the base specification. Avoiding unexpected behavior from legacy applications.¶
Allow cryptographic credentials to be specified as JSON Web Key Sets [RFC7517].¶
Provide more descriptive information for use of cryptographic credentials, in particular specifying which key is to be used with which information service.¶
Allow specification of groups of related email addresses and information services.¶
In addition, specific guidance is provided on specifying credentials for use with S/MIME, OpenPGP, SSH and Code Signing.¶
The JSContact cryptokeys property allows a card to specify cryptographic credentials as URIs but not their intended uses. A data URI containing an X.509v3 certificate might be intended for use with S/MIME, for code signing or some entirely unrelated purpose. Best design practice encourages the use of common cryptographic infrastructures to support a wide range of applications but best use practices encourage limiting the use of particular cryptographic keys to a single application.¶
The use of the JSON Web Key (JWK) format provides a much richer format for describing cryptographic keys and their properties than a URI and a media type.¶
For example, Bob is trying to send an encrypted email to Alice, her contact card lists two X.509v3 certificates but only one is an encryption certificate with the JWK use parameter:¶
The keys property which MAY be specified in either an EmailAddress object or an OnlineService object allows the key identifies of the keys related to the application to be specified.¶
For example, Alice has multiple OpenPGP keys in her contact card but she only uses one for signing her repository comits:¶
It is often convenient to group related email addresses and online services used for a common purpose. For example, Alice might create separate sets of SSH, repository commit signing and code signing keys for her work and personal projects and assign these to separate groups:¶
The features described in this document are designed to support but not require the exchange of JSContact data by means of an Encrypted Authenticated Resource Locator (EARL) [draft-hallambaker-earl]. An EARL is a URI form that contains a multi-purpose key that MAY be used to locate, decrypt and authenticate an associated ciphertext package.¶
For example, Alice's JSContact information might be retrievable from the EARL:¶
jscontact://example.com/eluv-woab-g7ih-onix-ybns-qdxk-rzqs¶
Alice might publish her EARL on her business card either as text or as a machine readable code such as a QR code. Alternatively, Alice might publish the information as a prefixed DNS TXT record in the domain she uses as her DNS handle:¶
_jscontact.alice.example.com TXT "jscontact=jscontact://example.com/eluv-woab-g7ih-onix-ybns-qdxk-rzqs"¶
The authenticated locator mechanisms described above are intended to be used to establish a 'first contact' between the parties preserving the maximum possible degree of trust from the context.¶
Once the initial contact exchange has been achieved, the credentials exchanged in that first contact MAY be used to obtain and authenticate future updates.¶
The updates property provides an open framework for describing the update mechanisms supported.¶
For example, Alice publishes her current contact card by means of a DNS TXT record containing an EARL locating a ciphertext package whose plaintext payload and metadata are signed under the specified key:¶
This section presents the related specifications and standards, the terms that are used as terms of art within the documents and the terms used as requirements language.¶
This is an informational document and does not contain any normative language.¶
Reference code under the MIT Open Source license has been developed to demonstrate all the features described in this document.¶
updates: Id[Update] (optional).¶
The update mechanisms that MAY be used to provide Card updates.¶
An Update object has all properties of the Resource (Section 1.4.4) data type, with the following additional definitions:¶
The @type property value MUST be "Calendar", if set¶
keys: Id[Boolean] (optional).¶
The identifiers used within this contact card to identify keys to be used with this update mechanism.¶
This section defines a means of grouping contact properties and extends the contact properties specified in [RFC9553].¶
groups: Id[OnlineService] (optional).¶
The online services that are associated with the entity represented by the Card. This can be messaging services, social media profiles, and other¶
@type: String.¶
The JSContact type of the object. The value MUST be "Group", if set.¶
contexts: String[Boolean] (optional).¶
The contexts in which to use the service¶
Members Id[Boolean] (required)¶
The identifiers used within this contact card to identify email addresses or online services belonging to this group.¶
label: String (optional).¶
A custom label for the value.¶
The EmailAddress object is extended to add the following property:¶
keys: Id[Boolean] (optional).¶
The identifiers used within this contact card to identify keys to be used with this email address.¶
The OnlineService object is extended to add the following property:¶
keys: Id[Boolean] (optional).¶
The identifiers used within this contact card to identify keys to be used with this email address.¶
This section defines additional properties for digital resources associated with the entity represented by the Card.¶
jwkss: Id[Jwks] (optional).¶
The cryptographic resources such as public keys and certificates associated with the entity represented by the Card.¶
A Jwks object has all properties of the Resource (Section 1.4.4) data type, with the following additional definitions:¶
The @type property value MUST be " Jwks ", if set.¶
data:JWK[]¶
This section provides guidance on how to encode cryptographic keys for specific applications.¶
[TBS]¶
TBS¶
This document does not specify any actions for IANA yet but it will...[TBS]¶