Internet-Draft JSContact Extensions April 2025
Hallam-Baker Expires 19 October 2025 [Page]
Workgroup:
Network Working Group
draft-hallambaker-jscontact-01:
draft-hallambaker-jscontact
Published:
Intended Status:
Informational
Expires:
Author:
P. M. Hallam-Baker
ThresholdSecrets.com

JSContact Extensions

Abstract

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.

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 19 October 2025.

▲

Table of Contents

1. Introduction

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.

1.1. Linking Keys to Services

JSContact allows a card to specify online services and cryptographic keys but does not provide a means of specifying which key is to be used for which purpose. This is a particular problem with key formats used to support a wide range of applications, an OpenPGP key may be used to sign email or sign a repository commit.

The EmailAddress object and OnlineService object are extended to add a keys property which MAY be used to specify the key identifiers of the related keys.

For example, Alice has an email address entry that has keys for signing and encrypting emails using S/MIME and OpenPGP.

{
  "EmailAddress":{
    "@type":"EmailAddress",
    "address":"alice@example.com",
    "label":"Main email",
    "keys":{
      "MASH-6WZG-PNOY-CONC-RE2Q-LHVC-XR76":"smime",
      "MAEJ-6YNA-5D5N-DFMA-VK75-OJ6U-XEZR":"smime",
      "MBM7-2Y26-TNN3-QIEN-VMAT-BXD6-HQVV":"openpgp",
      "MAD7-Z5KI-4FLF-AMUP-U3NF-4477-JHXH":"openpgp"}}}

1.2. Enhanced specification of cryptographic credentials

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 keys but only one is an encryption key with the JWK use parameter enc:

["MASH-6WZG-PNOY-CONC-RE2Q-LHVC-XR76" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"RSA",
      "use":"any",
      "n":"pY6mQa29SqyOfxGSdfrKQ1NwmrhKedYjEJj7ml5z0bBSg3y-wkztP_to
Qp6hnleSJcMNOL6njEo3JmCIWpX5g4uqRg0y9wCdNUeLheUlQAQS0Dw25qglIYvKfW
-boJzoZwQuHSjP8-EZVE-dzmsUhSziVEJBrz2MACnuvXT0pX1dLQfHY0pjUTdtJMbh
NNl16GtRkrb5zBmyLpwkuSvw7jSOdPR6h1SrFh31bfJejCVkniIbwQSgAqaw7w4qnS
xZov8RkrmYfMxuUMAHX54x8REGa6ORxsBSiQAOoWoBcNENvDMFrcLM_5iGw6T1dXIQ
yaxDRPrjcUBUrw4SuM3_gQ",
      "e":"AQAB"}
    ]},
"MAEJ-6YNA-5D5N-DFMA-VK75-OJ6U-XEZR" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"RSA",
      "use":"any",
      "n":"qyEsIBvp1K2yj-Ak84DdYMsaMztB-FpkveWeIzvi_GpKw6O8pY562uLw
Jx7z5AE2pKTs83RecXmi0gb-kAMWYdttQotgURqYBgtvUs6UuphCD_1gKH_aoo9x6Y
ljip3ANz9rHFAbTcB17PK6FDr1CLn8aEWFLXn9KYnFPvGHob4apK507MDBijUfFiBw
J4RMkYLeX_WBxT1sx9NQWRlyZvmhXy5ojZJOQoRcIR97F8LkE_vhQN4fNq3RafYvLr
4MwgWiWoTtj773NVx09Oc_DU95QP5oWJLhWVAt87yZv5FdVEloyZY_NaFgT3UjzJ3n
YbQt289z4jG-fc17yFqvnQ",
      "e":"AQAB"}
    ]}
...
]

1.3. Groups

It is often convenient to organize related email addresses and online services used for a common purpose into groups.

For example, Alice might create separate sets of SSH, repository commit signing and code signing keys for code development:

{
  "Group":{
    "@type":"Group",
    "label":"Developer Key Set",
    "members":{
      "MA2N-CF6Q-NGXX-V7KI-4A3S-OKT2-5FGD":true,
      "MD3Z-4VVE-MOJK-IVFL-EDXG-KPMC-4FY2":true,
      "MCJ2-LKQA-V544-UHVL-IGMU-2E2L-XXK4":true,
      "MAGM-M32C-XQ6Y-F5OL-ZC3F-PHHJ-3VVZ":true,
      "MD3G-35L6-YZBT-QZTV-7CON-UMR6-F4PC":true,
      "MBRP-JDCO-ROD5-OOYP-U3CJ-SDB6-IHFH":true,
      "MBLU-QI2Y-ISIA-P5YI-UXQ2-DNI4-5BJR":true}}}

Each group identifier is specified as an online service:

["MA2N-CF6Q-NGXX-V7KI-4A3S-OKT2-5FGD" : {
  "@type":"OnlineService",
  "service":"ssh",
  "keys":{
    "MCQ2-27OY-R5PX-TDG2-BFLA-P7BF-UGFS":"ssh"}},
"MD3Z-4VVE-MOJK-IVFL-EDXG-KPMC-4FY2" : {
  "@type":"OnlineService",
  "service":"commit",
  "label":"commit",
  "keys":{
    "MB3Q-TJXP-FU4P-VOJZ-MXOR-CZ6O-QIJW":"credential"}},
"MCJ2-LKQA-V544-UHVL-IGMU-2E2L-XXK4" : {
  "@type":"OnlineService",
  "service":"code",
  "contexts":{
    "Pkix":true},
  "label":"code Pkix",
  "keys":{
    "MCDH-RZQ7-HMZY-HNOF-QO4J-BAEZ-MHSN":"credential"}}
...
]

1.4. Authenticated Locators

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:

earl:eim5-nbf4-vfbj-wh3u-bg37-jiqf-shis

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=earl:eim5-nbf4-vfbj-wh3u-
    bg37-jiqf-shis"

1.5. Authenticated Updates

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:

{
  "Update":{
    "@type":"Update",
    "keys":{
      "MAW4-H6XX-QWQH-M4HC-NTXC-DEMB-BVWI":"sign"}}}

["MAW4-H6XX-QWQH-M4HC-NTXC-DEMB-BVWI" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"OKP",
      "kid":"MAW4-H6XX-QWQH-M4HC-NTXC-DEMB-BVWI",
      "crv":"Ed448",
      "x":"httHKAp2_6W2DJVfKjzaKvFdnDG1oe41UVfRdjWinY1CE7IWEio_Ra7g
GqxRtKmO4PyI_vLS4RuA"}
    ]}]

2. Definitions

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.

2.1. Requirements Language

This is an informational document and does not contain any normative language.

2.4. Implementation Status

Reference code under the MIT Open Source license has been developed to demonstrate all the features described in this document.

3. Card Extensions

3.1. Metadata Properties

3.1.1. update

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.

3.2. Contact Properties

This section defines a means of grouping contact properties and extends the contact properties specified in [RFC9553].

3.2.1. groups

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.

3.2.2. EmailAddress object

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.

3.2.3. OnlineService object

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.

3.3. Resource Properties

This section defines additional properties for digital resources associated with the entity represented by the Card.

3.3.1. Jwks

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[]

Where JWK is a JSON Web Key as specified in [RFC7517].

4. Application Profiles

This section provides guidance on how to encode cryptographic keys for specific applications.

This section is intentionally left unfinished to solicit input from the relevant expert groups.

4.1. S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data over SMTP and other messaging transports.

Certificates issued for use with S/MIME are commonly used for other purposes, for example TLS client authentication. For the purposes of this discussion, our focus is strictly limited to the use of the certificate for messaging.

If the messaging protocol is SMTP, the service is specified as an EmailAddress, otherwise the OnlineService structure is used with the appropriate service specifier.

Strawman proposal:

  • Use a single JWK entry with an x5c to specify the encryption key cert, signature key cert and cert path.
  • Specify the JWK in the keys section of the corresponding EmailAddress or OnlineService with the key identifier of the corresponding JWK and the 'smime' use. 
["MASH-6WZG-PNOY-CONC-RE2Q-LHVC-XR76" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"RSA",
      "use":"any",
      "n":"pY6mQa29SqyOfxGSdfrKQ1NwmrhKedYjEJj7ml5z0bBSg3y-wkztP_to
Qp6hnleSJcMNOL6njEo3JmCIWpX5g4uqRg0y9wCdNUeLheUlQAQS0Dw25qglIYvKfW
-boJzoZwQuHSjP8-EZVE-dzmsUhSziVEJBrz2MACnuvXT0pX1dLQfHY0pjUTdtJMbh
NNl16GtRkrb5zBmyLpwkuSvw7jSOdPR6h1SrFh31bfJejCVkniIbwQSgAqaw7w4qnS
xZov8RkrmYfMxuUMAHX54x8REGa6ORxsBSiQAOoWoBcNENvDMFrcLM_5iGw6T1dXIQ
yaxDRPrjcUBUrw4SuM3_gQ",
      "e":"AQAB"}
    ]},
"MAEJ-6YNA-5D5N-DFMA-VK75-OJ6U-XEZR" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"RSA",
      "use":"any",
      "n":"qyEsIBvp1K2yj-Ak84DdYMsaMztB-FpkveWeIzvi_GpKw6O8pY562uLw
Jx7z5AE2pKTs83RecXmi0gb-kAMWYdttQotgURqYBgtvUs6UuphCD_1gKH_aoo9x6Y
ljip3ANz9rHFAbTcB17PK6FDr1CLn8aEWFLXn9KYnFPvGHob4apK507MDBijUfFiBw
J4RMkYLeX_WBxT1sx9NQWRlyZvmhXy5ojZJOQoRcIR97F8LkE_vhQN4fNq3RafYvLr
4MwgWiWoTtj773NVx09Oc_DU95QP5oWJLhWVAt87yZv5FdVEloyZY_NaFgT3UjzJ3n
YbQt289z4jG-fc17yFqvnQ",
      "e":"AQAB"}
    ]}
...
]

4.2. OpenPGP

OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management.

OpenPGP key management is commonly used for many purposes including signing repository commits. For the purposes of this section, our focus is strictly limited to the use of keys for messaging.

If the messaging protocol is SMTP, the service is specified as an EmailAddress, otherwise the OnlineService structure is used with the appropriate service specifier.

Strawman proposal:

  • User specifies their OpenPGP primary key as an OnlineService with service type 'openpgp'. This is also the place any key server information would be placed.
  • The first key in the keys entry of the service is the key identifier of the primary key
  • The sub keys are the following keys
  • The corresponding key entries are of type JsonWebKey
  • The key data is specified as a binary data property
  • Other services specify the subkeys that they use. 
["MBM7-2Y26-TNN3-QIEN-VMAT-BXD6-HQVV" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"RSA",
      "use":"any",
      "n":"yr160KgItur5f0Hyr6eLP9LlHxakZjPEgYOcm6t9K7DytMdhH0T-S4z4
dAqQkbzFaK1Z-iykx3Z8cdE0fIMZHDfyXiobRKUmUV8scSaTAfeoNcCMbsp10Faet7
-eMsui8dgBgJmG9IxXdHJKj_U-mL8BrIMuxlLfXkzNR0kT6Th2jGkMIhc5fKoyJeNS
6Y1Wx9XS-t40OLuxlScco04bdJ4DUnBahQayQA-IIitYeT9NZkUGM-HjsbtDWlc0yE
EXc-GU-Yd3rA2d6z7-RBLWNf0gvLk8DGbKon-8_oe2fi2D6I9m_tAX_segjYjQUi4h
zYj9cujJr1vUhj94A_8HEQ",
      "e":"AQAB"}
    ]},
"MAD7-Z5KI-4FLF-AMUP-U3NF-4477-JHXH" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"RSA",
      "use":"any",
      "n":"2prtjfVR8DOBcbgVTSmagJgdyVVRu_VDM8nnh_OO4_d2Qm7Hd0ZQHolG
xVeSNjl4KLoasC9sqAlUtQMBIY90__PfJnENBk5cn5u1GLyM6oSbbHH6Ig6KhPWDUl
eMsJglWZELwETM0ioGVoinGy0NOPxlcqIYK3-PGhlO6Rayo4q1kEUwTc92FD3y95Ys
Q7yx0hUd5vMbLMWgs0iTT__Kounqpa7kQKJGN23D7cr2vTdMACupVjzYDbvw7WPP4l
ZumgaCaikILYX-QNvLk1kIWMddxsygzBskaIDePJKRqSgOj5ee4CmHzZUHahKlz_vS
JtpR_cXUMNEcCwG-ENU56Q",
      "e":"AQAB"}
    ]}
...
]

4.3. SSH

Although the SSH protocol does support certificates these are not currently widely used on the client side and it is not clear that the use case of a single user specifying multiple SSH client keys for use on multiple devices has been fully distinguished from the use case of a corporation certifying keys for multiple employees.

If the user only has a client single key for a given use, this can be specified as JWK public key parameters.

If the user is making use of client side SSH certificates to provision each device with separate SSH credentials, the contact card should specify the SSH certificate.

["MCS2-NMUZ-XH2M-SACB-HKME-QA5Q-UEE2" : {
  "@type":"OnlineService",
  "service":"ssh",
  "label":"Main SSH key",
  "keys":{
    "MAXR-52BP-BW6H-RMXJ-KLLT-IMEZ-H47N":"ssh"}},
"MA2N-CF6Q-NGXX-V7KI-4A3S-OKT2-5FGD" : {
  "@type":"OnlineService",
  "service":"ssh",
  "keys":{
    "MCQ2-27OY-R5PX-TDG2-BFLA-P7BF-UGFS":"ssh"}}]

["MAXR-52BP-BW6H-RMXJ-KLLT-IMEZ-H47N" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"RSA",
      "use":"any",
      "n":"sL_W4OkxDuAnhEcJkav_7YlKVousIg0VgUEMgvnpbmKQzUPKwSAha1qH
rFTSTljbIeDqdsM-LQJxb1kWByEKp1uCAKERHXJqnozWFDQr_GLH3a-Yvq0XqYUJt-
JC67gZY400SdohG1xLwpEuFy3_P0e8ZA1UM2oaNfeJbD6EL3KbrifOukzvxJT6o2cp
aSCiM9mS6WmOlkx2sKuCPnPgR6N_kmACE3IhDQxbTmeX1zCrTs4pYJBtwV1SslD251
C9eoX-UMHYCsrC9dBPYXjTUn8bF0swn2fQuJmPwC76XDx-5bj-ncW0pRfjBCvbWvZu
usmSiuBnbIM2pyHt6u_xKQ",
      "e":"AQAB"}
    ]},
"MCQ2-27OY-R5PX-TDG2-BFLA-P7BF-UGFS" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"RSA",
      "use":"any",
      "n":"0BK_C5iBEEPEZCNYLqyabefDQsffP4X58aChbs9eW9cqBNpOVvtBuGDb
3moYn4CA3RsHPXBK4Wcoa8Al58bFHosuzROAVKp2lGyOZIv025oyRHT0GSWnAy5aQ8
K34KOKutpCVIJSrGUZ5Rb8XJZ9Os9OlBq6Gp-a9jg-vR9VjjTTctXxluEcHwGZyXWV
r2-JE3gngcB6vdoPrdk5_TbR_5tQz9RI-iXNG07mu6QCbEgxpmP9RP0_ebyJ6NKkNi
E1Nzjm_ex1T2begW1CCWc8tng-uJn8Gnvk3TO1bL-nKZCveZidEtTd0gsV7undAGx4
MeiKtVH9wLh2ExJfiE2bCQ",
      "e":"AQAB"}
    ]}]

4.4. Code Signing

Code signing typically makes use of PKIX certificates. While a single certificate could in practice be used for multiple platforms, each code signing program tends to have their own requirements and set of recognized CAs.

It is however useful for a user to specify their own personal hierarchy with a personal root for testing and development purposes.

A developer may have multiple code signing keys for the same platform. For example, separate signing keys for each development machine.

Some mechanism is required to allow development and production keys to be distinguished.

["MCJ2-LKQA-V544-UHVL-IGMU-2E2L-XXK4" : {
  "@type":"OnlineService",
  "service":"code",
  "contexts":{
    "Pkix":true},
  "label":"code Pkix",
  "keys":{
    "MCDH-RZQ7-HMZY-HNOF-QO4J-BAEZ-MHSN":"credential"}},
"MAGM-M32C-XQ6Y-F5OL-ZC3F-PHHJ-3VVZ" : {
  "@type":"OnlineService",
  "service":"code",
  "contexts":{
    "Windows":true},
  "label":"code Windows",
  "keys":{
    "MBZC-4EHN-KAJI-XSKB-W45A-WV23-LHOJ":"credential"}},
"MD3G-35L6-YZBT-QZTV-7CON-UMR6-F4PC" : {
  "@type":"OnlineService",
  "service":"code",
  "contexts":{
    "Apple":true},
  "label":"code Apple",
  "keys":{
    "MB4Z-2UCQ-JUIG-G5Z4-Y76M-FHI5-E5MX":"credential"}},
"MBRP-JDCO-ROD5-OOYP-U3CJ-SDB6-IHFH" : {
  "@type":"OnlineService",
  "service":"code",
  "contexts":{
    "Android":true},
  "label":"code Android",
  "keys":{
    "MAO6-6LOK-EW7D-MJZ6-2RO5-35UV-RLBQ":"credential"}},
"MBLU-QI2Y-ISIA-P5YI-UXQ2-DNI4-5BJR" : {
  "@type":"OnlineService",
  "service":"code",
  "contexts":{
    "Linux":true},
  "label":"code Linux",
  "keys":{
    "MDUR-5BHM-ST7L-WTBC-R752-FFS2-K3YO":"credential"}}]

["MCDH-RZQ7-HMZY-HNOF-QO4J-BAEZ-MHSN" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"EC",
      "use":"any",
      "kid":"MCDH-RZQ7-HMZY-HNOF-QO4J-BAEZ-MHSN",
      "crv":"P-256",
      "x":"J-in_jqB3bvINnAMuNkbhtcoD8OKNG6BQJo-z78hAx0",
      "y":"yhIZTBog1ZB2ohMoS8s-FBb4sm6dXoLRTi7LtgVbc3o"}
    ]},
"MBZC-4EHN-KAJI-XSKB-W45A-WV23-LHOJ" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"EC",
      "use":"any",
      "kid":"MBZC-4EHN-KAJI-XSKB-W45A-WV23-LHOJ",
      "crv":"P-256",
      "x":"MxKF1zEd3q661EldvCSPkDLS8mXxrJ0GSeogWOE9TFY",
      "y":"lwsCJkqw6Rl8xbuoepOXkEVPzn0Pb6QAeqseQCCTckQ"}
    ]},
"MB4Z-2UCQ-JUIG-G5Z4-Y76M-FHI5-E5MX" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"EC",
      "use":"any",
      "kid":"MB4Z-2UCQ-JUIG-G5Z4-Y76M-FHI5-E5MX",
      "crv":"P-256",
      "x":"RUELs9U6NJCbEGscOX6n076BJV2yVCZ8PK4ijrC57HY",
      "y":"Sksb4NPdPLiIwcOBHLTkOax0a_X7LGSjVS9VXVfeanQ"}
    ]},
"MAO6-6LOK-EW7D-MJZ6-2RO5-35UV-RLBQ" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"EC",
      "use":"any",
      "kid":"MAO6-6LOK-EW7D-MJZ6-2RO5-35UV-RLBQ",
      "crv":"P-256",
      "x":"phZovN7fg2pfZ-I4bpBMRmIrXxSoa9_YwcPEMzPttik",
      "y":"L5FRLNfCvO5lpryi9R4QagxRtwp-dbWYRRqGLWu_Fvk"}
    ]},
"MDUR-5BHM-ST7L-WTBC-R752-FFS2-K3YO" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"EC",
      "use":"any",
      "kid":"MDUR-5BHM-ST7L-WTBC-R752-FFS2-K3YO",
      "crv":"P-256",
      "x":"A_OBrK6WH7t6y2uTFBPVa4pcOC_aih1wP3DEzmV-mFw",
      "y":"_ObizRbCZh07p72Rw5zXQr-M87YMUtUzMhJM-22u3e0"}
    ]}]

4.5. Commit Signing

OpenPGP key management is commonly used for signing repository commits.

This use is specified by means of an OnlineService with the service type 'commit' with key entries for the set of authorized signing keys.

["MD3Z-4VVE-MOJK-IVFL-EDXG-KPMC-4FY2" : {
  "@type":"OnlineService",
  "service":"commit",
  "label":"commit",
  "keys":{
    "MB3Q-TJXP-FU4P-VOJZ-MXOR-CZ6O-QIJW":"credential"}}]

["MB3Q-TJXP-FU4P-VOJZ-MXOR-CZ6O-QIJW" : {
  "@type":"Jwks",
  "jwk":[{
      "kty":"EC",
      "use":"any",
      "kid":"MB3Q-TJXP-FU4P-VOJZ-MXOR-CZ6O-QIJW",
      "crv":"P-256",
      "x":"KZoTxEUsWaR8nD9yjEoWEzS4p-8OHEp92mEmWUmm_m8",
      "y":"MdafEZXaESYzW1MqdMwwWrzdHYQYOERc_pjcBG83jPg"}
    ]}]

5. IANA Considerations

This document does not specify any actions for IANA yet but it will...[TBS]

6. Acknowledgements

7. Normative References

[draft-hallambaker-earl]
Hallam-Baker, P., "Encrypted Authenticated Resource Locator", Work in Progress, Internet-Draft, draft-hallambaker-earl-00, , <https://datatracker.ietf.org/doc/html/draft-hallambaker-earl-00>.
[RFC7517]
Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, , <https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7553]
Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", RFC 7553, DOI 10.17487/RFC7553, , <https://www.rfc-editor.org/rfc/rfc7553>.
[RFC9553]
Stepanek, R. and M. Loffredo, "JSContact: A JSON Representation of Contact Data", RFC 9553, DOI 10.17487/RFC9553, , <https://www.rfc-editor.org/rfc/rfc9553>.

Author's Address

Phillip Hallam-Baker
ThresholdSecrets.com