| Internet-Draft | JSContact Extensions | May 2025 |
| Hallam-Baker | Expires 3 November 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 3 November 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 [RFC9553] 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.¶
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",
"keys":{
"MCBG-ZSI4-XSWX-UNEE-GU6X-YTBZ-XPH5":"smime",
"MBZ7-F2MR-7M6K-XFN3-K7MM-SZAD-WSVH":"smime",
"MDLO-2KK6-HUHT-ZX4Q-4PMO-QL7Y-FCUS":"openpgp",
"MDKY-BZJ4-HOGY-UC4K-F7PO-7M3J-I5TW":"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]¶
{
"@type":"Card",
...
"cryptoKeys" : {"MCBG-ZSI4-XSWX-UNEE-GU6X-YTBZ-XPH5" : {
"@type":"JWK",
"jwk":{
"kty":"RSA",
"use":"any",
"n":"wQ_sVNL3ovdrIvbWIpxy-ln3QFDSE9RhEFD5hHTzbvk8eXXjZnE0rl_Z2I
an6_2Wdl9Z3COsmuZImFCl-ndcc4EwYuHhjplxx-eH9A-DBhOPxuJ_OXAXrEauVhwv
4VjC5sw1GHJGFkZ8G3SzCL94tMmcmh-QuMUDbq7y7ie9tuxiTWLPWTWO0O4muoh9Zz
w8fdQ3hbkP8-hY_3SjCiBuVDRDWT-6qpQgnJSC1bRCJpJN4UtTBzAHb93N0JuJzKyg
F3ztc4Si0NXXbWhdDweqWfVylCWQww0F3_GCUk5dwR1l8JgFxyeorP6Jbd0cBIzZte
Op1RBvvWzIuQyVLBgCIQ",
"e":"AQAB"}},
"MBZ7-F2MR-7M6K-XFN3-K7MM-SZAD-WSVH" : {
"@type":"JWK",
"jwk":{
"kty":"RSA",
"use":"any",
"n":"v9fXZRamyNnGWIf-fszlW5PDA0CgUH0467u3iAO8pK4LRCPTnof3XWoNx4
bpypC7w6lgFXDThvnEUCgWcMyrmTRnNrLiLyZSXQTIXJJSG_o4V-Js1nC4dMvai47H
umQkFk1vHh_YgOIjETlkdrSXyN35fvfj4Wo7TvU1Sp4SsZdknju9AfFKQjZ1KHJN5c
_ynS2Tm6txRjMLBzRNgQ617zKC_gB9x8KD8jhJJlMBHG6nse-65GH_zsNXWm2Dbkb4
dPYN91P7ZqU5Ce9TYN52518SSsgfJH0UHdm-Dzg5uJZSEEASamLlhf-6f6dLL3r8ch
Q0x7lNRHoDA7BdJ9CioQ",
"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" : {
"Group":{
"@type":"Group",
"label":"Developer Key Set",
"members":{
"MANE-YN3A-RSJ2-YCTB-6TN3-VHPT-CNU6":true,
"MA5Z-KE6T-43JR-MNIV-FNZO-VQWC-SQJW":true,
"MBYV-APCA-NCFR-E2XD-CJD2-Y72C-6QNU":true,
"MBLT-BPEH-4ROU-SAYA-F5ET-CJ4R-NVMO":true,
"MC4D-JUY4-RJLA-RO7I-VB2O-5ZDL-O3V3":true,
"MD2G-TVLC-OIOG-HC2Q-36SZ-7JWZ-BIMG":true,
"MCAL-WYVC-DYDY-4B2G-SM4A-AIYY-ESOB":true}}},
...
}¶
Each group identifier is specified as an online service:¶
{
"@type":"Card",
...
"onlineServices" : {"MANE-YN3A-RSJ2-YCTB-6TN3-VHPT-CNU6" : {
"@type":"OnlineService",
"service":"ssh",
"keys":{
"MCZW-XTEJ-W6XG-GLXN-X454-UBNP-E7Y2":"ssh"}},
"MA5Z-KE6T-43JR-MNIV-FNZO-VQWC-SQJW" : {
"@type":"OnlineService",
"service":"commit",
"label":"commit",
"keys":{
"MADC-JRWU-N2LX-MH5C-3VLC-C2VW-SFM2":"credential"}},
"MBYV-APCA-NCFR-E2XD-CJD2-Y72C-6QNU" : {
"@type":"OnlineService",
"service":"code",
"contexts":{
"Pkix":true},
"label":"code Pkix",
"keys":{
"MB5J-ETWT-HP52-PKN3-YLYT-UBPR-6VY5":"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) [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/ekf7-qfax-noh4-sxn4-ycdf-k7x4-obml¶
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
kf7-qfax-noh4-sxn4-ycdf-k7x4-obml"¶
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/NDHF-6WRH-SAV3-AS3Z-6ATJ-K6RW
-Y6ZL",
"keys":{
"MAJ5-DV7W-NCIM-3HRT-LQZI-6MM6-YZAO":"sign"}}}
...
"cryptoKeys" : {
"MAJ5-DV7W-NCIM-3HRT-LQZI-6MM6-YZAO" : {
"@type":"JWK",
"jwk":{
"kty":"OKP",
"kid":"MAJ5-DV7W-NCIM-3HRT-LQZI-6MM6-YZAO",
"crv":"Ed448",
"x":"jDnvvAHZyXEHnEI_rRcIgenvvSMc_lOSByLInr-vHF7hwZuYe6f4Do-4La
GMgVeZ8iSr4eAVYlMA"}}}
...
}¶
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: It would be really easy to add a JOSE based encryption scheme and pass a decryption key in the initial contact.]¶
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 with her 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 [RFC2119].¶
TBS¶
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.¶
This section is intentionally left unfinished to solicit input from the relevant expert groups.¶
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:¶
{
"@type":"Card",
...
"cryptoKeys" : {"MCBG-ZSI4-XSWX-UNEE-GU6X-YTBZ-XPH5" : {
"@type":"JWK",
"jwk":{
"kty":"RSA",
"use":"any",
"n":"wQ_sVNL3ovdrIvbWIpxy-ln3QFDSE9RhEFD5hHTzbvk8eXXjZnE0rl_Z2I
an6_2Wdl9Z3COsmuZImFCl-ndcc4EwYuHhjplxx-eH9A-DBhOPxuJ_OXAXrEauVhwv
4VjC5sw1GHJGFkZ8G3SzCL94tMmcmh-QuMUDbq7y7ie9tuxiTWLPWTWO0O4muoh9Zz
w8fdQ3hbkP8-hY_3SjCiBuVDRDWT-6qpQgnJSC1bRCJpJN4UtTBzAHb93N0JuJzKyg
F3ztc4Si0NXXbWhdDweqWfVylCWQww0F3_GCUk5dwR1l8JgFxyeorP6Jbd0cBIzZte
Op1RBvvWzIuQyVLBgCIQ",
"e":"AQAB"}},
"MBZ7-F2MR-7M6K-XFN3-K7MM-SZAD-WSVH" : {
"@type":"JWK",
"jwk":{
"kty":"RSA",
"use":"any",
"n":"v9fXZRamyNnGWIf-fszlW5PDA0CgUH0467u3iAO8pK4LRCPTnof3XWoNx4
bpypC7w6lgFXDThvnEUCgWcMyrmTRnNrLiLyZSXQTIXJJSG_o4V-Js1nC4dMvai47H
umQkFk1vHh_YgOIjETlkdrSXyN35fvfj4Wo7TvU1Sp4SsZdknju9AfFKQjZ1KHJN5c
_ynS2Tm6txRjMLBzRNgQ617zKC_gB9x8KD8jhJJlMBHG6nse-65GH_zsNXWm2Dbkb4
dPYN91P7ZqU5Ce9TYN52518SSsgfJH0UHdm-Dzg5uJZSEEASamLlhf-6f6dLL3r8ch
Q0x7lNRHoDA7BdJ9CioQ",
"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:¶
{
"@type":"Card",
...
"cryptoKeys" : {"MDLO-2KK6-HUHT-ZX4Q-4PMO-QL7Y-FCUS" : {
"@type":"JWK",
"jwk":{
"kty":"RSA",
"use":"any",
"n":"yrgyxhrOO02riEZNfQx6AFGuiM4qBakQDVHZa_TmQc_POENfR9xQaSbmAf
cprEkBPhItmlRL9I-2AjhIl21n3rybi4s0LVlwFIwJtiZo0TXRvti4AgSi7yQZnI67
jgrBHpZBv4KP2B9QMKJgqGtIMoTshEvuEQDZ2V53xxdxW4VKOLnH5XElxLA1j1aPef
ztFS8MarInkDcPOGrBDRerGaUO8d32V3VXo-8yv7sZJHIjJng3LTu3XP2Fye6aEGUH
6WB-TrChA8FdOFfT5lz0w4bN_uc1Kg_TA7YuioH1txSrVUtTVwVoGZZrMaFnq6ac6p
BfCjWkAuq8eL1v3TYTzQ",
"e":"AQAB"}},
"MDKY-BZJ4-HOGY-UC4K-F7PO-7M3J-I5TW" : {
"@type":"JWK",
"jwk":{
"kty":"RSA",
"use":"any",
"n":"tCvIREuhrjlHH7E5RkKOIPweeuR-hJK9X5HXzBn6ytucfCceJ7pfbFroWV
BQa9NgahF5GaRI4g-FT6nmm5xaYxDqt2SxOfaK62oFOwEk7077GsKyfWOxvfbmLCx8
G260P8wtJAR18z4ZsxEMUlKAKuglpcAjS1YVovJmgvqOCpLurBsDTFFh3m3-Y1shvz
67aSgu_p-Do3642sOQjzjVzpSlkuNfPpq8U6kEqflXKN-_bYHdyyjrK_GpONKyUSx5
RUV338DQqq3OC-ceEcsXRadH46l8Gtp9xCB1M1iwByR2pEtQ2GI4TYMWH7IFXPHz84
cRyaKg1RGvpRU6g1GGZQ",
"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" : {"MALY-CBST-ZST3-KC24-7MJO-COMV-2YHD" : {
"@type":"OnlineService",
"service":"ssh",
"label":"Main SSH key",
"keys":{
"MCWA-K3WT-H334-236P-OL4I-FEPY-NFYU":"ssh"}},
"MANE-YN3A-RSJ2-YCTB-6TN3-VHPT-CNU6" : {
"@type":"OnlineService",
"service":"ssh",
"keys":{
"MCZW-XTEJ-W6XG-GLXN-X454-UBNP-E7Y2":"ssh"}}}
{
"@type":"Card",
...
"cryptoKeys" : {"MCWA-K3WT-H334-236P-OL4I-FEPY-NFYU" : {
"@type":"JWK",
"jwk":{
"kty":"RSA",
"use":"any",
"n":"zH9C7jhIbv7vEewyxMWPqF7xsfPSkkC8CFKzVHoiNODPwiHT8hEJY616h2
KaIJMHYIKesFbfHoiK_N79zpQ3Hggk7z_yBCoJcaths37EO0QrZtgOlSNmXgZfhxdJ
kn3gAEh3H2J2kNAhQ8zhZzNa72pU74MsUkw3gBjMR_eEV71QcgVA4xBdNS_-842VF4
R8wH9xHtBSjLw0WkkJfy1aFo-sibAREvOI-vyJbwc9DJ5r0MOm3zudth4QiBLn7ZR2
qcUmMEWsqPibzGtGSeZ09t4-GpZETBm5t0eXzXNOENZ2aVQYxsmATNUiIO027GqxML
FrsDJ4L2Z2QLN6wbvePQ",
"e":"AQAB"}},
"MCZW-XTEJ-W6XG-GLXN-X454-UBNP-E7Y2" : {
"@type":"JWK",
"jwk":{
"kty":"RSA",
"use":"any",
"n":"tlLMk1YZTUPQmtw9aIo_bPAz5A9JMdQFEYeODrAfSDNdNiKHUnH1YZ-Z0p
F9ujj5qLP8NwvYMpgpZQ4bNj1n7rxUjElLJ9bCkmtRBdj-WxHz6uQLg1pczYswGGlp
bFqBjj0Vs8DMLPb3yFp09DbkrKkYX0AA5LYTQJbeVIudxvNk0skbBRmX0nTfWlUqHD
a8YwvNIcbOCZw_MXaSP5ccKnjnQ-dBsXshDgFEbtv6eunEggTz7K298NQ-qZJezbg2
XeCRaJC0Z3i6PcGSlXWBMBSsdI79uHv0sik1vXCncoB7EybuiTc-kujAkGS-ubsIB5
heHnuYyIbV7THVz8r-rQ",
"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" : {"MBYV-APCA-NCFR-E2XD-CJD2-Y72C-6QNU" : {
"@type":"OnlineService",
"service":"code",
"contexts":{
"Pkix":true},
"label":"code Pkix",
"keys":{
"MB5J-ETWT-HP52-PKN3-YLYT-UBPR-6VY5":"credential"}},
"MBLT-BPEH-4ROU-SAYA-F5ET-CJ4R-NVMO" : {
"@type":"OnlineService",
"service":"code",
"contexts":{
"Windows":true},
"label":"code Windows",
"keys":{
"MBTU-3MDN-JDDN-SCSF-BVAW-HI6N-Y723":"credential"}},
"MC4D-JUY4-RJLA-RO7I-VB2O-5ZDL-O3V3" : {
"@type":"OnlineService",
"service":"code",
"contexts":{
"Apple":true},
"label":"code Apple",
"keys":{
"MBRV-LFME-QG6X-KSQ4-MCFJ-3V3A-IDNI":"credential"}},
"MD2G-TVLC-OIOG-HC2Q-36SZ-7JWZ-BIMG" : {
"@type":"OnlineService",
"service":"code",
"contexts":{
"Android":true},
"label":"code Android",
"keys":{
"MAK3-DRVN-EKIG-YRPG-RL5S-OX4C-7YOV":"credential"}},
"MCAL-WYVC-DYDY-4B2G-SM4A-AIYY-ESOB" : {
"@type":"OnlineService",
"service":"code",
"contexts":{
"Linux":true},
"label":"code Linux",
"keys":{
"MCDD-EMLX-TIBF-KD35-5DA4-HFU3-667H":"credential"}}}
{
"@type":"Card",
...
"cryptoKeys" : {"MB5J-ETWT-HP52-PKN3-YLYT-UBPR-6VY5" : {
"@type":"JWK",
"jwk":{
"kty":"EC",
"use":"any",
"kid":"MB5J-ETWT-HP52-PKN3-YLYT-UBPR-6VY5",
"crv":"P-256",
"x":"qcZuFrfYZjG_vXg-iV8maHo5j9Fhu9SQdKfN9Evyeu4",
"y":"dWF_CnowfoduCwKGdQ8_2gwanwWWfOeg-B0zocVobIg"}},
"MBTU-3MDN-JDDN-SCSF-BVAW-HI6N-Y723" : {
"@type":"JWK",
"jwk":{
"kty":"EC",
"use":"any",
"kid":"MBTU-3MDN-JDDN-SCSF-BVAW-HI6N-Y723",
"crv":"P-256",
"x":"20Ltae6RgfsqbMg4ML_aMls6NCqyY3RLqNHVeCAXCJA",
"y":"yYHjpKAlGv81RuANkGyvneyf5LNBIa1JHIazTjwzrKc"}},
"MBRV-LFME-QG6X-KSQ4-MCFJ-3V3A-IDNI" : {
"@type":"JWK",
"jwk":{
"kty":"EC",
"use":"any",
"kid":"MBRV-LFME-QG6X-KSQ4-MCFJ-3V3A-IDNI",
"crv":"P-256",
"x":"MElPU3-Stkaq0wJk-XNBr43dAc2w2iO8TbxQsDNGb6g",
"y":"NHexXrZKG0jotHQIweVMMAyfrhkBPWbsox0DlYWWsV4"}},
"MAK3-DRVN-EKIG-YRPG-RL5S-OX4C-7YOV" : {
"@type":"JWK",
"jwk":{
"kty":"EC",
"use":"any",
"kid":"MAK3-DRVN-EKIG-YRPG-RL5S-OX4C-7YOV",
"crv":"P-256",
"x":"SfC_qp8WlQDRZqr2J98kyEa7y61RzgwG3aURBXohK-o",
"y":"5CNsK4vHTG5KU-Ldt6DrSCNxjphkWE0f0NCaa-TEG9g"}},
"MCDD-EMLX-TIBF-KD35-5DA4-HFU3-667H" : {
"@type":"JWK",
"jwk":{
"kty":"EC",
"use":"any",
"kid":"MCDD-EMLX-TIBF-KD35-5DA4-HFU3-667H",
"crv":"P-256",
"x":"GLCaAwsFNQDYem3XzjJGG8a4F-N-anrdsnwiMbQlZJ0",
"y":"CR_ruRnWcdE_lGCFkdhGaVmLeNXjjJOeeJvLWGlBI5c"}}}¶
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" : {"MA5Z-KE6T-43JR-MNIV-FNZO-VQWC-SQJW" : {
"@type":"OnlineService",
"service":"commit",
"label":"commit",
"keys":{
"MADC-JRWU-N2LX-MH5C-3VLC-C2VW-SFM2":"credential"}}}
{
"@type":"Card",
...
"cryptoKeys" : {"MADC-JRWU-N2LX-MH5C-3VLC-C2VW-SFM2" : {
"@type":"JWK",
"jwk":{
"kty":"EC",
"use":"any",
"kid":"MADC-JRWU-N2LX-MH5C-3VLC-C2VW-SFM2",
"crv":"P-256",
"x":"iouxGIUfn9II9JttLu4rB9UKPSDeUJ5yD4nG7300bfo",
"y":"hDWZwXZOCb4XycubBpxvv7Usfc0Hj6A3AgMupygdJ20"}}}¶
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.¶