JSContact Cryptographic Key Extensions

This document defines extensions to the JSContact data model for contact card data 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 . 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. Enable automated updates to the contact card data with cryptographic authentication. In addition, specific guidance is provided on specifying credentials for use with S/MIME, OpenPGP, SSH and Code Signing.

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. { "@type":"Card", ... "emails" : { "EmailAddress":{ "@type":"EmailAddress", "address":"alice@example.com", "label":"Main email", "cryptoKeyIds":{ "MCWL-4PH7-BGOQ-272F-AI65-2RZ6-MUUD":"smime", "MDHC-JQF4-UF3X-3I2U-BCA2-QXXX-O3EP":"smime", "MBXP-3A5S-QK6E-IPKV-XEPB-MLGP-GXZT":"openpgp", "MDIQ-XEE6-MXPY-SBUV-ALFD-235X-EIHD":"openpgp"}}}, ... }

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: [NB: This example is showing presentation as a JWK raw key alone, we would probably want to present the certificate as well, this has been left open so we can have a full discussion before fixing a scheme.] { "@type":"Card", ... "cryptoKeys" : {"MCWL-4PH7-BGOQ-272F-AI65-2RZ6-MUUD" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"RSA", "use":"any", "n":"zSnY_U9jRHjAHrPz1xNdzrOY6JiZzrX2YXCVGPuOgeh83ZgqivxmVf6G G6ffYELwGS1YpbXLVeWZ61OIIImeH_i5vQ-XEsqZ1AwoF2FjanYACNT4qsRjXMAvei r0I9YUeRBS79neGsvT1XQnYoM4X0i2ScK6i9y9g-mWRSAP51u6yfsy_a08c2sTDdZk hs2p0xzBkw466IApBM-5wjoYfhppq_W2tZP4axd4HCXWiklgGRJ54WoApdTbZC-kLG 57fHg15iIS1CIhcvHCwgDjIqCH1nx5v8Dz3VFPG_-6wET6cmPUUhAOWi7uCcNOfocr wS5vMS6P44bYKPwkrdd4TQ", "e":"AQAB"} ]}, "MDHC-JQF4-UF3X-3I2U-BCA2-QXXX-O3EP" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"RSA", "use":"any", "n":"0lxQNj6ne6tVKYeklt0-47cryXj55Ji1NEPodNiqaENoqCDfdv_5O_iw zWobGepq9PVWVB0ANyFHFbwGs37A5Sc-NszKxTlCjvQVDLHnqIaS98Wu0xmGAPEnmA j88X2TNjK_7LsByIKAARZOJD4sUGrSWP5ldOX1HiSFV1i01GdAgJYXHHoxSHNzOSBI I6ms4-T_6PlCiN0WXKo9oHSzdciHPXAcgO_Zbe9HyZqvqfizGF9C5g6aksVV77cCwu r4GSnpVyB6d1LhTu7XbPn5NJM8QW45pYiajz_dT5jZN-Jy6EtLkYzH3sWgkaAt3FdN eZTPp69auAP0Ha1czqB6-Q", "e":"AQAB"} ]} ... }

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: { "@type":"Card", ... "groups" : { "ServiceGroup":{ "@type":"ServiceGroup", "label":"Developer Key Set", "members":{ "MCQY-DKEM-YV5C-XGLM-WN5C-HJ42-2OEF":true, "MDZ5-LPWS-UGBU-DFWG-XUXS-L2LS-HWSR":true, "MBG2-I4PN-UFUO-UO2Y-UVXN-Q5UA-Z2NY":true, "MDCN-RB23-Q6JN-DAIV-6YH3-XKEZ-S56M":true, "MAWF-SPC4-DBIF-KUYD-IIWA-DMSS-64Q3":true, "MCNT-J6ED-7CYL-KJW7-6WZZ-SS4G-3GTO":true, "MAVJ-MGEC-HV6G-A5EQ-2QXG-EXQZ-QFDX":true}}}, ... } Each group identifier is specified as an online service: { "@type":"Card", ... "onlineServices" : {"MCQY-DKEM-YV5C-XGLM-WN5C-HJ42-2OEF" : { "@type":"OnlineService", "service":"ssh", "cryptoKeyIds":{ "MBSI-3DUN-N53C-AH3Z-COWI-FMZW-A66I":"ssh"}}, "MDZ5-LPWS-UGBU-DFWG-XUXS-L2LS-HWSR" : { "@type":"OnlineService", "service":"commit", "label":"commit", "cryptoKeyIds":{ "MDXR-NQMN-NCDP-6BPA-XB3L-3ZAX-QMVD":"credential"}}, "MBG2-I4PN-UFUO-UO2Y-UVXN-Q5UA-Z2NY" : { "@type":"OnlineService", "service":"code", "contexts":{ "Pkix":true}, "label":"code Pkix", "cryptoKeyIds":{ "MD3P-VLPM-MK4T-MSJM-WMK5-6DOQ-UUZU":"credential"}} ... }

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) . 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/ej4a-o4bp-oeel-5r5m-nb3l-bsae-zevq 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/e j4a-o4bp-oeel-5r5m-nb3l-bsae-zevq"

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 SHOULD be used to obtain and authenticate future updates. Contact cards that support updates MUST include a UID property. Updates to contact cards MUST specify the same UID value. The updates property provides an open framework for describing the update mechanisms supported. The mechanisms provided to update the contact MAY be different from the mechanism originally used to distribute it. For example, Alice publishes her current contact card by means of a DNS TXT record containing an EARL and a QR code encoding the same EARL on the business card she presents when meeting people in person. Applications MAY update the card by polling the URI specified in the updates entry and verifying the signature on the plaintext enveloped data returned. { "@type":"Card", ... "updates" : { "update1" : { "@type":"Update", "uri":"https://contacts.example.com/NAUF-OHSV-6TL7-F2V5-3GAB-L47X -CJIY", "keys":{ "MB22-MB6Y-EKOI-BPWH-FSXA-XZI2-KXV6":"sign"}}} ... "cryptoKeys" : { "MB22-MB6Y-EKOI-BPWH-FSXA-XZI2-KXV6" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"OKP", "kid":"MB22-MB6Y-EKOI-BPWH-FSXA-XZI2-KXV6", "crv":"Ed448", "x":"b97f03ci3xmr_qvaK_yiLdAAXSxMSK8lkSqeWP_iAqElh-_mb-qjAiWl yYJPxH9GWE81zy_AtbAA"} ]}} ... } Since it is easier to update information on a Web site than in DNS or on a business card, it is likely that some users will prefer to use these mechanisms to distribute pro-forma contact information consisting of basic contact information and update information alone. Therefore, contact applications SHOULD attempt to update contact cards providing update information on receipt. Retrieving a plaintext signed contact assertion via HTTPS provides a simple but limited update mechanism providing end-to-end integrity but not confidentiality. While the contact information is delivered over an encrypted transport, the contact card is stored unencrypted on the server which may not be acceptable in certain applications. Another limitation is that the relying party is required to poll the contact service for updates. A more sophisticated updates protocol might provide update notifications. Such considerations are outside the scope of this document and left for future work. [Remark: Addition of a JOSE based encryption scheme would be straightforward. This would require extension of the envelope specification and to pass a decryption key to the parties the contact is passed to.] A contact card MAY specify multiple update mechanisms providing a degree of resilience in the case that a publication service stops providing service. For example, Alice might choose three independent contact directory services publishing her contact information on all three ensuring that the people she has shared her contact information with can remain in contact years or even decades after the initial contact exchange.

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.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .

TBS

JSContact: A JSON Representation of Contact Data .: Describes the format used for contact data interchange.
Encrypted Authenticated Resource Locator .: Describes a URI form that provides means of retrieving, decrypting and authenticating an associated ciphertext.

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

The JSContact objects specified in is extended as described in the following sections.

The following properties are added to the Card object specified in [RFC9553].

"updates": String[Update] (optional) Specifies mechanisms for obtaining updates to the card. An Update object has all the properties of the Resource data type, with the following additional definitions: "protocol": String (optional) The IANA update protocol identifier "keys": String[String] (optional) The identifiers of the set of cryptographic keys to be used to authenticate the updated contact information and their use. "updates": { "update1": { "@type": "Update", "uri": "https://contacts.example.com/NAUF-OHSV-6TL7-F2V5-3GAB-L47 X-CJIY", "keys": { "MB22-MB6Y-EKOI-BPWH-FSXA-XZI2-KXV6": "sign"}}}

"serviceGroups": String[ServiceGroup] (optional) Specifies groups of related email addresses and online services. A ServiceGroup object has all the properties of the Resource data type, with the following additional definition: "members": String[Boolean] (optional) The identifiers of the service group members. The boolean value corresponding to each MUST be true. "serviceGroups": { "NBIE-FAR2-RHSO-LZH4-DJ5G-PWN3-RL6C": { "@type": "ServiceGroup", "label": "Developer Key Set", "members": { "MCQY-DKEM-YV5C-XGLM-WN5C-HJ42-2OEF": true, "MDZ5-LPWS-UGBU-DFWG-XUXS-L2LS-HWSR": true, "MBG2-I4PN-UFUO-UO2Y-UVXN-Q5UA-Z2NY": true, "MDCN-RB23-Q6JN-DAIV-6YH3-XKEZ-S56M": true, "MAWF-SPC4-DBIF-KUYD-IIWA-DMSS-64Q3": true, "MCNT-J6ED-7CYL-KJW7-6WZZ-SS4G-3GTO": true, "MAVJ-MGEC-HV6G-A5EQ-2QXG-EXQZ-QFDX": true}}}

The following objects specified in [RFC9553] are extended to add the specified properties.

An EmailAddress object has the following properties.

"cryptoKeyIds": String[String] (optional) The identifiers of the set of cryptographic keys to be used to authenticate the updated contact information and their use. "cryptoKeyIds": { "MCWL-4PH7-BGOQ-272F-AI65-2RZ6-MUUD": "smime", "MDHC-JQF4-UF3X-3I2U-BCA2-QXXX-O3EP": "smime", "MBXP-3A5S-QK6E-IPKV-XEPB-MLGP-GXZT": "openpgp", "MDIQ-XEE6-MXPY-SBUV-ALFD-235X-EIHD": "openpgp"}

An OnlineService object has the following properties.

The following object is defined:

A JsonWebKeySet object has all the properties of the CryptoKey data type, with the following additional definition:

"jsonWebKeys": JWK[] (optional) A Json Web Key Set. The JWK object is defined in [TBS]. "jsonWebKeys": [{ "kty": "RSA", "use": "any", "n": "weK4hQaQYa_tARUb_Lp2__SO485HnULlbRdiwnGCu_SjpcnDkgahEj3I7_t 9zL4YBTPbnV7a3oCnWGOgDSbv7QsXQzeNBopBytHAjk_l2QyZ9nMCSTT_VCkk t_ePXQyYZCdV93alkkuqhqHAJThh9inZ7z0heIBqF7mv8mLheP_r8Yj4vslOT ROc5KoP5i5EYamYKhQvcKUUuSEeR_fsPyNbEM-R0lMdagOncdikGsEpmAl9ox _t9ReJv9CPHRfJgF32BuDsiQvPtWnF8ej_AMtkhgz47ICUpFRgK64YH6IwMW2 9GOxIbp7stGK-jVXBPSbmjJyZCXyOUMClamIfmQ", "e": "AQAB"}]

This section will provide guidance on how to encode cryptographic keys for specific applications. It is currently a placeholder so the relevant expert groups have an opportunity to advise the precise means by which the relevant information is presented.

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.

{ "@type":"Card", ... "cryptoKeys" : {"MCWL-4PH7-BGOQ-272F-AI65-2RZ6-MUUD" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"RSA", "use":"any", "n":"zSnY_U9jRHjAHrPz1xNdzrOY6JiZzrX2YXCVGPuOgeh83ZgqivxmVf6G G6ffYELwGS1YpbXLVeWZ61OIIImeH_i5vQ-XEsqZ1AwoF2FjanYACNT4qsRjXMAvei r0I9YUeRBS79neGsvT1XQnYoM4X0i2ScK6i9y9g-mWRSAP51u6yfsy_a08c2sTDdZk hs2p0xzBkw466IApBM-5wjoYfhppq_W2tZP4axd4HCXWiklgGRJ54WoApdTbZC-kLG 57fHg15iIS1CIhcvHCwgDjIqCH1nx5v8Dz3VFPG_-6wET6cmPUUhAOWi7uCcNOfocr wS5vMS6P44bYKPwkrdd4TQ", "e":"AQAB"} ]}, "MDHC-JQF4-UF3X-3I2U-BCA2-QXXX-O3EP" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"RSA", "use":"any", "n":"0lxQNj6ne6tVKYeklt0-47cryXj55Ji1NEPodNiqaENoqCDfdv_5O_iw zWobGepq9PVWVB0ANyFHFbwGs37A5Sc-NszKxTlCjvQVDLHnqIaS98Wu0xmGAPEnmA j88X2TNjK_7LsByIKAARZOJD4sUGrSWP5ldOX1HiSFV1i01GdAgJYXHHoxSHNzOSBI I6ms4-T_6PlCiN0WXKo9oHSzdciHPXAcgO_Zbe9HyZqvqfizGF9C5g6aksVV77cCwu r4GSnpVyB6d1LhTu7XbPn5NJM8QW45pYiajz_dT5jZN-Jy6EtLkYzH3sWgkaAt3FdN eZTPp69auAP0Ha1czqB6-Q", "e":"AQAB"} ]} ... }

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.

{ "@type":"Card", ... "cryptoKeys" : {"MBXP-3A5S-QK6E-IPKV-XEPB-MLGP-GXZT" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"RSA", "use":"any", "n":"sFr32DBI46QPVpRxcgB_c-5BoCUmj3wBlIhUvzuDQteTTHvYndNckeXB h9Yd5jGF_fUUuDpa8LfxpRafjqp7lMeKPtifaK_pT-TxsLkYzLisjNv-AEiIMiM-ve IOLbqkIJvqEUimniCHWv4DUBQ1r-QSlGyE-LjKphoLhhTpumTaCI4m7uXY9hPsIwjB VBZw_r8CrMHojIJLnlpXHjg6v4V_rwl9giTz3fXP-lAX4H6rSObxX6vf7dhkTAisbh qvu638JsoAmLHAi2QUCrvbhH9VXEQgQjB_MJdte_Yq94jIc6ZaKtDNI2O0RacC55Nl MCVgLtDvXsAtXRku9RjzdQ", "e":"AQAB"} ]}, "MDIQ-XEE6-MXPY-SBUV-ALFD-235X-EIHD" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"RSA", "use":"any", "n":"vKVmyf93yfwf874x0uHIZt9t9UZaEf7k7tMHR_-r1RQ9shSmBdLTKlBt cLF3taH1UbRivpN-wv-FOXPLbCT9fPL9XQeD0u-GNJMdFNvq2UFatWElLTYWjYznkU wLke6XWX5jo400YUhzfukMAg5EpteMbrL3mp1p6JGemBguQb-sqQRXCLNK0_Hv91We Y929ePcsCM_NSpweSTrpHExKQUh8kyE8LUi71cV9O7TwLAIKj-WgefAIgWYXw8l3pj 1-wB8ECWhiYxUNKQNjZDuVWJ5fGyDNFQUZtcdMlIKtYh1q441SjZtXzsfAcAjZs8Mj o0UKOsaQyDSpwNdLFJueLQ", "e":"AQAB"} ]} ... }

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. { "@type":"Card", ... "onlineServices" : {"MC7H-2PVP-FOJS-YMCT-7EK7-XKCK-C5LL" : { "@type":"OnlineService", "service":"ssh", "label":"Main SSH key", "cryptoKeyIds":{ "MAVY-4VWK-BSK5-SNEB-HXTP-BRPD-O27R":"ssh"}}, "MCQY-DKEM-YV5C-XGLM-WN5C-HJ42-2OEF" : { "@type":"OnlineService", "service":"ssh", "cryptoKeyIds":{ "MBSI-3DUN-N53C-AH3Z-COWI-FMZW-A66I":"ssh"}}} { "@type":"Card", ... "cryptoKeys" : {"MAVY-4VWK-BSK5-SNEB-HXTP-BRPD-O27R" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"RSA", "use":"any", "n":"weK4hQaQYa_tARUb_Lp2__SO485HnULlbRdiwnGCu_SjpcnDkgahEj3I 7_t9zL4YBTPbnV7a3oCnWGOgDSbv7QsXQzeNBopBytHAjk_l2QyZ9nMCSTT_VCkkt_ ePXQyYZCdV93alkkuqhqHAJThh9inZ7z0heIBqF7mv8mLheP_r8Yj4vslOTROc5KoP 5i5EYamYKhQvcKUUuSEeR_fsPyNbEM-R0lMdagOncdikGsEpmAl9ox_t9ReJv9CPHR fJgF32BuDsiQvPtWnF8ej_AMtkhgz47ICUpFRgK64YH6IwMW29GOxIbp7stGK-jVXB PSbmjJyZCXyOUMClamIfmQ", "e":"AQAB"} ]}, "MBSI-3DUN-N53C-AH3Z-COWI-FMZW-A66I" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"RSA", "use":"any", "n":"0KRTXPI_tUMNSrN3Y58WVBjz6FTmVfylJlOepO4C1CIpHmxzVVZ6RSeX 3kVBcfiPZ3ILhvKd897qfSVo7V9uouzoAMG3379SYp1t574StlpyCq2-q90IsagCkq j0jtPRylk0VuWSZ79qz00CDPPcuamt1a0AuylVrbZQZFc0ItACGSeJ6socc6omo02f -rpeALIIIxm-mKaYFVxfewHB15nbmKHp98b_r1Kls9P50Z7dsJI-LzJSTxRjR5VUAS KKri0ha4DWPjPP3xsefibOGUb38bVpHQU88Ym03_SEA57kYyulL49ukXQtAp-jPG7h nYkZuLIUNrAjJoMy3z3bYQ", "e":"AQAB"} ]}}

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. { "@type":"Card", ... "onlineServices" : {"MBG2-I4PN-UFUO-UO2Y-UVXN-Q5UA-Z2NY" : { "@type":"OnlineService", "service":"code", "contexts":{ "Pkix":true}, "label":"code Pkix", "cryptoKeyIds":{ "MD3P-VLPM-MK4T-MSJM-WMK5-6DOQ-UUZU":"credential"}}, "MDCN-RB23-Q6JN-DAIV-6YH3-XKEZ-S56M" : { "@type":"OnlineService", "service":"code", "contexts":{ "Windows":true}, "label":"code Windows", "cryptoKeyIds":{ "MAIA-AJVM-UMBK-34RE-BBI4-NAAC-6ERI":"credential"}}, "MAWF-SPC4-DBIF-KUYD-IIWA-DMSS-64Q3" : { "@type":"OnlineService", "service":"code", "contexts":{ "Apple":true}, "label":"code Apple", "cryptoKeyIds":{ "MA7Q-YSLZ-G236-MWWY-DTDB-IOKP-QLS7":"credential"}}, "MCNT-J6ED-7CYL-KJW7-6WZZ-SS4G-3GTO" : { "@type":"OnlineService", "service":"code", "contexts":{ "Android":true}, "label":"code Android", "cryptoKeyIds":{ "MBTU-PAS7-CFVO-AQBY-I3IF-4J4L-757W":"credential"}}, "MAVJ-MGEC-HV6G-A5EQ-2QXG-EXQZ-QFDX" : { "@type":"OnlineService", "service":"code", "contexts":{ "Linux":true}, "label":"code Linux", "cryptoKeyIds":{ "MCMU-6SPM-V2N4-LCFP-7SVQ-BAPR-B357":"credential"}}} { "@type":"Card", ... "cryptoKeys" : {"MD3P-VLPM-MK4T-MSJM-WMK5-6DOQ-UUZU" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"EC", "use":"any", "kid":"MD3P-VLPM-MK4T-MSJM-WMK5-6DOQ-UUZU", "crv":"P-256", "x":"o0AjiMSJuFNVGq8QumW6MWBblNICsb7ppICOnZ387Os", "y":"pRYp-wzKx9GS8DtH76QYR6WX5NZFLwjav4HBsqt70Ys"} ]}, "MAIA-AJVM-UMBK-34RE-BBI4-NAAC-6ERI" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"EC", "use":"any", "kid":"MAIA-AJVM-UMBK-34RE-BBI4-NAAC-6ERI", "crv":"P-256", "x":"BprBWL3n56BTacpgv_P_qOtf5NfX_NDtDUYUaSM0PIU", "y":"Gpm3Dup-pRDI5tzm9ckJ81oB9LzVpHBBtQUdAJfcvIs"} ]}, "MA7Q-YSLZ-G236-MWWY-DTDB-IOKP-QLS7" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"EC", "use":"any", "kid":"MA7Q-YSLZ-G236-MWWY-DTDB-IOKP-QLS7", "crv":"P-256", "x":"aA9nGoeaHSHVUGBgH-PRS0KRH5Aet3H6XrpC1T_AgG8", "y":"LRwy5PjFC2Qt9zG7m9Pn-9r2cQ_10oyK9lAEsnCHX84"} ]}, "MBTU-PAS7-CFVO-AQBY-I3IF-4J4L-757W" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"EC", "use":"any", "kid":"MBTU-PAS7-CFVO-AQBY-I3IF-4J4L-757W", "crv":"P-256", "x":"8ZM20mgQHouTdcwAlKjWaah1Li1zDxSXsTkX40bC-zc", "y":"6bYnENrAoaMHf4TE_F83K5d1CplXVq5HOwrQDZqY3XI"} ]}, "MCMU-6SPM-V2N4-LCFP-7SVQ-BAPR-B357" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"EC", "use":"any", "kid":"MCMU-6SPM-V2N4-LCFP-7SVQ-BAPR-B357", "crv":"P-256", "x":"mpXXFCQPAn1cI9wQ3f5BkNroTV-MDeuDcK0tTE5U7yg", "y":"CG_4Wq3v_mOcdfuaQhKCDs6cBENWWSVOlGu4BkFQwLc"} ]}}

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. { "@type":"Card", ... "onlineServices" : {"MDZ5-LPWS-UGBU-DFWG-XUXS-L2LS-HWSR" : { "@type":"OnlineService", "service":"commit", "label":"commit", "cryptoKeyIds":{ "MDXR-NQMN-NCDP-6BPA-XB3L-3ZAX-QMVD":"credential"}}} { "@type":"Card", ... "cryptoKeys" : {"MDXR-NQMN-NCDP-6BPA-XB3L-3ZAX-QMVD" : { "@type":"JsonWebKeySet", "jsonWebKeys":[{ "kty":"EC", "use":"any", "kid":"MDXR-NQMN-NCDP-6BPA-XB3L-3ZAX-QMVD", "crv":"P-256", "x":"flp1GWuHWTjieipqxI0aKaQipinBwYT-fzfSFfaKVzo", "y":"3ObVWnF-dduUBCFx9REZGkDFj0_lYvgOU0Hu_aYqzv4"} ]}}

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

Many thanks to Robert Stepanek who helped refine the approach to extending the schema.