-
Notifications
You must be signed in to change notification settings - Fork 6
/
draft-looker-jwm.txt
1176 lines (795 loc) · 43.8 KB
/
draft-looker-jwm.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group T. Looker, Ed.
Internet-Draft Mattr
Intended status: Standards Track June 6, 2021
Expires: December 8, 2021
JSON Web Message
draft-looker-jwm-02
Abstract
JSON Web Message (JWM) is a flexible way to encode application-level
messages in JSON for transfer over a variety of transport protocols.
JWMs use JSON Web Encryption (JWE) to protect integrity, achieve
confidentiality, and achieve repudiable authentication; alternatively
or in addition, they use JSON Web Signatures (JWS) to associate
messages with a non-repudiable digital signature.
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 http://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 December 8, 2021.
Copyright Notice
Copyright (c) 2021 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
(http://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 Simplified BSD License text as described in Section 4.e of
Looker Expires December 8, 2021 [Page 1]
Internet-Draft jwm June 2021
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. JSON Web Message (JWM) Overview . . . . . . . . . . . . . . . 4
2.1. Relationship to JWT . . . . . . . . . . . . . . . . . . . 4
2.2. Example Signed JWM . . . . . . . . . . . . . . . . . . . 5
2.3. Example Encrypted JWM . . . . . . . . . . . . . . . . . . 7
3. JWM Attributes . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Registered Attribute Names . . . . . . . . . . . . . . . 10
3.1.1. "id" Attribute . . . . . . . . . . . . . . . . . . . 10
3.1.2. "type" Attribute . . . . . . . . . . . . . . . . . . 10
3.1.3. "body" Attribute . . . . . . . . . . . . . . . . . . 10
3.1.4. "to" Attribute . . . . . . . . . . . . . . . . . . . 11
3.1.5. "from" Attribute . . . . . . . . . . . . . . . . . . 11
3.1.6. "created_time" Attribute . . . . . . . . . . . . . . 11
3.1.7. "expires_time" Attribute . . . . . . . . . . . . . . 11
3.1.8. "reply_url" Attribute . . . . . . . . . . . . . . . . 11
3.1.9. "reply_to" Attribute . . . . . . . . . . . . . . . . 11
3.2. Public Attribute Names . . . . . . . . . . . . . . . . . 12
3.3. Private Attribute Names . . . . . . . . . . . . . . . . . 12
4. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 12
4.2. "cty" (Content Type) Header Parameter . . . . . . . . . . 13
4.3. Replicating Attributes as Header Parameters . . . . . . . 13
5. Creating and Validating JWMs . . . . . . . . . . . . . . . . 13
5.1. Creating a JWM . . . . . . . . . . . . . . . . . . . . . 13
5.2. Validating a JWM . . . . . . . . . . . . . . . . . . . . 14
5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 16
6. Implementation Requirements . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. Registration Template . . . . . . . . . . . . . . . . . . 17
7.1.1. Attribute Name: . . . . . . . . . . . . . . . . . . . 17
7.1.2. Attribute Description . . . . . . . . . . . . . . . . 17
7.1.3. Change Controller . . . . . . . . . . . . . . . . . . 17
7.1.4. Specification Document(s) . . . . . . . . . . . . . . 17
7.1.5. Initial Registry Contents . . . . . . . . . . . . . . 17
8. Media Type Registration . . . . . . . . . . . . . . . . . . . 18
8.1. Registry Contents . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Trust Decisions . . . . . . . . . . . . . . . . . . . . . 19
9.2. Signing and Encryption Order . . . . . . . . . . . . . . 19
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
Looker Expires December 8, 2021 [Page 2]
Internet-Draft jwm June 2021
12. Normative References . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
JSON Web Message (JWM) is a flexible way to encode application-level
messages in JSON for transfer over a variety of transport protocols.
JWMs use JSON Web Encryption (JWE) to protect integrity, achieve
confidentiality, and achieve repudiable authentication; alternatively
or in addition, they use JSON Web Signatures (JWS) to associate
messages with a non-repudiable digital signature. JWMs are inspired
by JWTs [RFC7519]; more details about this relationship are
documented in Section 2.1.
1.1. Notational Conventions
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 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
appear in all capitals, as shown here.
1.2. Terminology
The terms "JSON Web Signature (JWS)", "Base64url Encoding", "Header
Parameter", "JOSE Header", "JWS Payload", "JWS Signature", "JWS
Compact Serialization" and "JWS JSON Serialization" are defined by
the JWS specification [RFC7515].
The terms "JSON Web Encryption (JWE)", "JWE Compact Serialization"
and "JWE JSON Serialization" are defined by the JWE specification
[RFC7516].
The terms "StringOrURI", "NumericDate" are defined by the JWT
specification [RFC7519].
The following terms are defined by this specification:
JSON Web Message A JWM Attribute Set, encoded in a JWS and/or JWE,
enabling it to be digitally signed and/or encrypted.
JWM Attribute Set A JSON object of attributes conveyed by the JWM.
Attribute A piece of information conveyed in a message, sent from a
sender intended for processing by one or more recipients. An
attribute is represented in a JWM Attribute Set as a name/value
pair consisting of an Attribute Name and an Attribute Value.
Looker Expires December 8, 2021 [Page 3]
Internet-Draft jwm June 2021
Attribute Name The name portion of an attribute representation. An
attribute name is always a string.
Attribute Value The value portion of an attribute representation.
An attribute value can be any JSON value.
Nested JWM A JWM in which nested signing and/or encryption is
employed. In Nested JWMs, a JWM is used as the payload or
plaintext value of an enclosing JWS or JWE structure,
respectively.
2. JSON Web Message (JWM) Overview
2.1. Relationship to JWT
JWMs conceptually share parallels to JWTs:
o A JWM contains a JSON object comprised of attributes known as a
JWM Attribute Set, where the attributes featured in the set can be
public, private or registered in an IANA registry. This is
conceptually parallel to claims in JWTs, the JWT Claim Set, and
the JWT claims IANA registry.
o A JWM leverages JSON Web Signature (JWS) and or JSON Web
Encryption (JWE) to achieve digital signing, integrity protection
and or confidentiality via encryption for the JWM attribute set in
similar ways to JWT for the JWT claim set.
JWMs also deviate from JWTs in important ways that prevent a
converged specification.
o JWM and JWT have different intents. A JWM is about a sender
creating a message composed of attributes, where the message is
destined for a recipient or recipients. Whereas a JWT is about an
issuer expressing claims about a subject to an audience.
o The primary usage of JWTs centers around creating tokens that are
digitally signed or integrity protected through a Message
Authentication Code (MAC) by leveraging JWS. Encrypted JWTs via
JWE are less common and as defined in Section 8 of [RFC7519] they
are optional to implement. Whereas JWMs require both JWS and JWE
implementations.
o Because JWTs must be compact and URL-safe, they require compact
serialization for both JWS and JWE representations. This means
JWTs can feature only a single digital signature, and/or encrypt
for only a single recipient. In contrast, JWMs support multiple
digital signatures, and encryption for multiple recipients. They
Looker Expires December 8, 2021 [Page 4]
Internet-Draft jwm June 2021
achieve this using the JSON-based serialization of JWS and the
General JSON serialization of JWE. The Flattened JSON
serialization of JWE is not used in JWM.
o JWTs support an insecure format as defined in Section 6 of
[RFC7519], JWMs do not allow this format due to the
vulnerabilities it introduces.
In the spirit of specification re-use and promoting ease of
understanding, this specification's structure is inspired by
[RFC7519].
2.2. Example Signed JWM
The following example JOSE Header declares that the object is a JWM,
and the JWM is a JWS that has been digitally signed using ECDSA with
the curve p-256 and SHA-256 as the hashing algorithm ("ES256"). The
signer of the JWM has indicated that the key used to sign the JWM is
identified by "Ef1sFuyOozYm3CEY4iCdwqxiSyXZ5Br-eUDdQXk6jaQ" (with
line breaks for display purposes only):
{"typ":"JWM",
"kid":"Ef1sFuyOozYm3CEY4iCdwqxiSyXZ5Br-eUDdQXk6jaQ",
"alg":"ES256"}
Base64url encoding the octets of the UTF-8 representation of the JOSE
Header yields this encoded JOSE Header value (with line breaks for
display purposes only):
eyJ0eXAiOiJKV00iLCJraWQiOiJFZjFzRnV5T296WW0zQ0VZNGlDZHdxeGlTeVhaNUJyL
WVVRGRRWGs2amFRIiwiYWxnIjoiRVMyNTYifQ
The following is an example of a JWM Attributes Set (with line breaks
for display purposes only):
{"id":"urn:uuid:ef5a7369-f0b9-4143-a49d-2b9c7ee51117",
"type":"hello-world-message-type",
"from":"urn:uuid:8abdf5fb-621e-4cf5-a595-071bc2c91d82",
"expires_time":1516239022,
"created_time":1516269022,
"body":{"message": "Hello world!"}}
Base64url encoding the octets of the UTF-8 the JWS Payload yields
this encoded JWS Payload (with line breaks for display purposes
only):
eyJpZCI6InVybjp1dWlkOmVmNWE3MzY5LWYwYjktNDE0My1hNDlkLTJiOWM3ZWU1MTExN
yIsInR5cGUiOiJoZWxsby13b3JsZC1tZXNzYWdlLXR5cGUiLCJmcm9tIjoidXJuOnV1aW
Looker Expires December 8, 2021 [Page 5]
Internet-Draft jwm June 2021
Q6OGFiZGY1ZmItNjIxZS00Y2Y1LWE1OTUtMDcxYmMyYzkxZDgyIiwiZXhwaXJ5IjoxNTE
2MjM5MDIyLCJ0aW1lX3N0YW1wIjoxNTE2MjY5MDIyLCJib2R5Ijp7Im1lc3NhZ2UiOiJI
ZWxsbyB3b3JsZCEifX0
Computing the signature of the encoded JOSE Header and encoded JWS
Payload with the ECDSA with the curve p-256 and SHA-256 as the
hashing algorithm and base64url encoding the value in the manner
specified in [RFC7515] yields this encoded JWS Signature:
UDE7NsEJyhiewrX2_Z9OdIdB2ZREauoPoUAKdEmW72d8H_ivkjC1p7G16WHunBMq1zFka
nINTil3-H1FlhbzsQ
Compact Serialization (with line breaks for display purposes only):
eyJ0eXAiOiJKV00iLCJraWQiOiJFZjFzRnV5T296WW0zQ0VZNGlDZHdxeGlTeVhaNUJyL
WVVRGRRWGs2amFRIiwiYWxnIjoiRVMyNTYifQ
.
eyJpZCI6InVybjp1dWlkOmVmNWE3MzY5LWYwYjktNDE0My1hNDlkLTJiOWM3ZWU1MTExN
yIsInR5cGUiOiJoZWxsby13b3JsZC1tZXNzYWdlLXR5cGUiLCJmcm9tIjoidXJuOnV1aW
Q6OGFiZGY1ZmItNjIxZS00Y2Y1LWE1OTUtMDcxYmMyYzkxZDgyIiwiZXhwaXJ5IjoxNTE
2MjM5MDIyLCJ0aW1lX3N0YW1wIjoxNTE2MjY5MDIyLCJib2R5Ijp7Im1lc3NhZ2UiOiJI
ZWxsbyB3b3JsZCEifX0
.
UDE7NsEJyhiewrX2_Z9OdIdB2ZREauoPoUAKdEmW72d8H_ivkjC1p7G16WHunBMq1zFka
nINTil3-H1FlhbzsQ
JSON Serialization: (with line breaks for display purposes only):
{
"payload": "eyJpZCI6InVybjp1dWlkOmVmNWE3MzY5LWYwYjktNDE0My1hNDl
kLTJiOWM3ZWU1MTExNyIsInR5cGUiOiJoZWxsby13b3JsZC1tZXNzYWdlLXR5cG
UiLCJmcm9tIjoidXJuOnV1aWQ6OGFiZGY1ZmItNjIxZS00Y2Y1LWE1OTUtMDcxY
mMyYzkxZDgyIiwiZXhwaXJ5IjoxNTE2MjM5MDIyLCJ0aW1lX3N0YW1wIjoxNTE2
MjY5MDIyLCJib2R5Ijp7Im1lc3NhZ2UiOiJIZWxsbyB3b3JsZCEifX0",
"signatures": [
{
"protected": "eyJ0eXAiOiJKV00iLCJraWQiOiJFZjFzRnV5T296WW0zQ
0VZNGlDZHdxeGlTeVhaNUJyLWVVRGRRWGs2amFRIiwiYWxnIjoiRVMyNTYi
fQ",
"signature": "rwhHoGJZRyLliF2jPqGXMddBLWlJls4XqSO21GH2itlwh
3d3Zb2jAtqA93s9Lb6ktXoxqHxNy4Lbirtr3pCHQA"
}
]
}
Looker Expires December 8, 2021 [Page 6]
Internet-Draft jwm June 2021
2.3. Example Encrypted JWM
The following example JOSE Header declares that the object is a JWM,
and the JWM is a JWE that has been encrypted using AES in Galois/
Counter Mode (GCM) with 256-bit for content encryption (with line
breaks for display purposes only):
{
"typ":"JWM",
"enc":"A256GCM"
}
The following JOSE Header declares that the sender has used Elliptic
Curve Diffie-Hellman Ephemeral Static (ECDH-ES+A256KW) for key
agreement with AES based key wrapping to encrypt the content
encryption key (CEK). The keys required to perform the opposite
Diffie-Helman are identified by the key id of
"PGoXzs0NWaR_meKgTZLbEuDoSVTaFuyrbWI7V9dpjCg" along with the
ephemeral public key declared by the JSON object "epk". The
encrypted CEK is represented by the "encrypted_key" field (with line
breaks for display purposes only):
{
"kid": "PGoXzs0NWaR_meKgTZLbEuDoSVTaFuyrbWI7V9dpjCg",
"alg": "ECDH-ES+A256KW",
"epk": {
"kty": "EC",
"crv": "P-256",
"x": "-Nh7ShRB_xaCBZRdIiVCul3SoR0Yw4TGEQqqGij1vJs",
"y": "9tLx81PMfQkrOw8yuI2YwI0o7MtNzaCGfCBbZBW5YrM"
}
}
Because the JWE features a single recipient, the two JOSE headers are
combined into a single JOSE header, that can be represented as the
following.
Looker Expires December 8, 2021 [Page 7]
Internet-Draft jwm June 2021
{
"typ": "JWM",
"enc": "A256GCM",
"kid": "PGoXzs0NWaR_meKgTZLbEuDoSVTaFuyrbWI7V9dpjCg",
"alg": "ECDH-ES+A256KW",
"epk": {
"kty": "EC",
"crv": "P-256",
"x": "-Nh7ShRB_xaCBZRdIiVCul3SoR0Yw4TGEQqqGij1vJs",
"y": "9tLx81PMfQkrOw8yuI2YwI0o7MtNzaCGfCBbZBW5YrM"
}
}
The following is an example of a JWM Attributes Set (with line breaks
for display purposes only):
{"id":"urn:uuid:ef5a7369-f0b9-4143-a49d-2b9c7ee51117",
"type":"hello-world-message-type",
"from":"urn:uuid:8abdf5fb-621e-4cf5-a595-071bc2c91d82",
"expires_time":1516239022,
"created_time":1516269022,
"body":{"message": "Hello world!"}}
Encrypting the above plaintext for the recipient yields the following
ciphertext in base64url form.
awEW6ssGMbQxmvv4FPf0smom4QvPNrgLaxFiMMRXmUTgcs6mLcSJDbUhwLfGfnEeu2a0b
cGLRt7tTuQij5RBIe6sflhIgOjpr3VAHdZBYJbF Jg9dCMW_hVk0iLytmFV5BhvqXUXDA
ckwwTU41PcS2_qO5uqdIe24teP8Bd_IbVeVnaUwrEEBGJvxYDTefdZ4gryrzKFsLLBD5F
r9TsCFEddg0RL xaXFGX1YT8Jm6Ahm-jd6Ol9qIpWx-
8PMaFcZl7h4sPiAGVPiaaCyzTsMy8KW0Nmz3cEFqjEm4Ipc
Composing this information into a valid JWE leads to the following
possible expressions
Compact Serialization (with line breaks for display purposes only):
eyJ0eXAiOiJKV00iLCJlbmMiOiJBMjU2R0NNIiwia2lkIjoiUEdvWHpzME5XYVJfbWVLZ
1RaTGJFdURvU1ZUYUZ1eXJiV0k3VjlkcGpDZyIsImFsZyI6I kVDREgtRVMrQTI1NktXI
iwiZXBrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiZGdMdy1wOG5kZ0xRSm
hZeWhUaGhpVDRhbmJlRjhaak1MYXRxR 2dXVGxHSSIsInkiOiJ3MkNfcjUzekdUdVZscD
hQVndFZjViWWI0TWo4bXVjNTVtMHh6VkVMN1o0In19
.
rAiydPRY_cciOmaQ-tnNiacHWn2Z2GqDgf0FcG4nK2L_KsPd1V1OSA
.
EIY6u2ahL0MI28ah
.
Looker Expires December 8, 2021 [Page 8]
Internet-Draft jwm June 2021
awEW6ssGMbQxmvv4FPf0smom4QvPNrgLaxFiMMRXmUTgcs6mLcSJDbUhwLfGfnEeu2a0b
cGLRt7tTuQij5RBIe6sflhIgOjpr3VAHdZBYJbF Jg9dCMW_hVk0iLytmFV5BhvqXUXDA
ckwwTU41PcS2_qO5uqdIe24teP8Bd_IbVeVnaUwrEEBGJvxYDTefdZ4gryrzKFsLLBD5F
r9TsCFEddg0RL xaXFGX1YT8Jm6Ahm-jd6Ol9qIpWx-
8PMaFcZl7h4sPiAGVPiaaCyzTsMy8KW0Nmz3cEFqjEm4Ipc
.
fp_tT_6qsQK2d9szRAwWgA
JSON Serialization (with line breaks for display purposes only):
{
"protected": "eyJ0eXAiOiJKV00iLCJlbmMiOiJBMjU2R0NNIiwi
a2lkIjoiUEdvWHpzME5XYVJfbWVLZ1RaTGJFdURvU1ZUYUZ1eXJiV0
k3VjlkcGpDZyIsImFsZyI6IkVDREgtRVMrQTI1NktXIiwiZXBrIjp7
Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiLU5oN1NoUkJfeG
FDQlpSZElpVkN1bDNTb1IwWXc0VEdFUXFxR2lqMXZKcyIsInkiOiI5
dEx4ODFQTWZRa3JPdzh5dUkyWXdJMG83TXROemFDR2ZDQmJaQlc1WX
JNIn19",
"recipients": [
{
"encrypted_key": "J1Fs9JaDjOT_5481ORQWfEZmHy7OjE3p
TNKccnK7hlqjxbPalQWWLg"
}
],
"iv": "u5kIzo0m_d2PjI4m",
"ciphertext": "qGuFFoHy7HBmkf2BaY6eREwzEjn6O_FnRoXj2H-
DAXo1PgQdfON-_1QbxtnT8e8z_M6Gown7s8fLtYNmIHAuixqFQnSA4
fdMcMSi02z1MYEn2JC-1EkVbWr4TqQgFP1EyymB6XjCWDiwTYd2xpK
oUshu8WW601HLSgFIRUG3-cK_ZSdFaoWosIgAH5EQ2ayJkRB_7dXuo
6_AYdIzMahvPz0n1yHHBlYBuYeR58V-x85ACeCGtzL2OptPa2TmWdA
9Bi1MK6TYGZKezc6rpCK_VRSnLXhFwa1C3T0QBes",
"tag": "doeAoagwJe9BwKayfcduiw"
}
3. JWM Attributes
The JWM Attributes Set represents a JSON object whose members are the
attributes conveyed by the JWM. The Attribute Names within a JWM
Attributes Set MUST be unique; JWM parsers MUST either reject JWMs
with duplicate Attribute Names or use a JSON parser that returns only
the lexically last duplicate member name, as specified in
Section 15.12 ("The JSON Object") of ECMAScript 5.1 [ECMAScript].
The set of attributes that a JWM must contain to be considered valid
is context dependent and is outside the scope of this specification.
Specific applications of JWMs will require implementations to
understand and process some attributes in particular ways. However,
Looker Expires December 8, 2021 [Page 9]
Internet-Draft jwm June 2021
in the absence of such requirements, all attributes that are not
understood by implementations MUST be ignored.
There are three classes of JWM Attribute Names: Registered Attribute
Names, Public Attribute Names and Private Attribute Names.
3.1. Registered Attribute Names
The following Attribute Names are registered in the IANA "JSON Web
Message Attributes" registry established by Section 7. None of the
attributes defined below are intended to be mandatory to use or
implement in all cases, but rather they provide a starting point for
a set of useful, interoperable attributes. Applications using JWMs
should define which specific Attributes they use and when they are
required or optional.
3.1.1. "id" Attribute
The "id" attribute is used to define a unique identifier for a JWM.
The "id" attribute value MUST be assigned in a manner that ensures
that there is a negligible probability that the same value will be
accidentally assigned to another JWM. The processing of this
attribute is generally application specific. The "id" attribute
value is a case-sensitive string containing a StringOrURI value. Use
of this attribute is OPTIONAL.
3.1.2. "type" Attribute
The "type" attribute is used to define the type of the message. The
processing of this attribute is generally application specific. The
"type" attribute value is a case-sensitive string containing a
StringOrURI value. The "type" attribute value can be used by
applications to inform the structure and content of the "message
body" and indicate the presence of other JWM attributes. Use of this
attribute is OPTIONAL.
3.1.3. "body" Attribute
The "body" attribute is used to define a location for application
level message content. The "body" attribute value is a JSON object
conforming to RFC 7159 [RFC7159]. The processing of this attribute
is generally application specific. Use of this attribute is
OPTIONAL.
Looker Expires December 8, 2021 [Page 10]
Internet-Draft jwm June 2021
3.1.4. "to" Attribute
The "to" attribute is used to define the intended recipients of the
JWM. The "to" attribute value is an array of case-sensitive strings
each containing a StringOrURI value. The processing of this
attribute is generally application specific. Use of this attribute
is OPTIONAL.
3.1.5. "from" Attribute
The "from" attribute is used to define the sender of the JWM. The
"from" attribute value is a case-sensitive string containing a
StringOrURI value. The processing of this attribute is generally
application specific. Use of this attribute is OPTIONAL.
3.1.6. "created_time" Attribute
The "created_time" attribute is used to define the time in which the
message was created. The "created_time" attributes value MUST be a
number containing a NumericDate value. The processing of this
attribute is generally application specific. Use of this attribute
is OPTIONAL.
3.1.7. "expires_time" Attribute
The "expires_time" attribute is used to define the lifespan or
lifetime of the JWM. The "expires_time" attributes value MUST be a
number containing a NumericDate value. The processing of this
attribute is generally application specific. Use of this attribute
is OPTIONAL.
3.1.8. "reply_url" Attribute
The "reply_url" attribute is used to define a url to which a response
to the message can be sent. The "reply_url" attribute value is a
case-sensitive string containing a StringOrURI value. The processing
of this attribute is generally application specific. Use of this
attribute is OPTIONAL.
3.1.9. "reply_to" Attribute
The "reply_to" attribute is used to define who a response to the
message should be sent to. The "reply_to" attribute value is an
array of case-sensitive strings each containing a StringOrURI value.
The processing of this attribute is generally application specific.
Use of this attribute is OPTIONAL.
Looker Expires December 8, 2021 [Page 11]
Internet-Draft jwm June 2021
3.2. Public Attribute Names
Attribute Names can be defined at will by those using JWMs. However,
in order to prevent collisions, any new Attribute Name should either
be registered in the IANA "JSON Web Message Attributes" registry
established by Section 7 or be a Public Name: a value that contains a
Collision-Resistant Name. In each case, the definer of the name or
value needs to take reasonable precautions to make sure they are in
control of the part of the namespace they use to define the Attribute
Name.
3.3. Private Attribute Names
A producer and consumer of a JWM MAY agree to use Attribute Names
that are Private Names: names that are not Registered Attribute Names
Section 3.1 or Public Attribute Names Section 3.2. Unlike Public
Attribute Names, Private Attribute Names are subject to collision and
should be used with caution.
4. JOSE Header
For a JWM object, the members of the JSON object represented by the
JOSE Header describe the cryptographic operations applied to the JWM
and optionally, additional properties of the JWM. Depending upon
whether the JWM is a JWS or JWE, the corresponding rules for the JOSE
Header values apply.
This specification further specifies the use of the following header
parameters in both the cases where the JWM is a JWS and where it is a
JWE.
4.1. "typ" (Type) Header Parameter
The "typ" (type) Header Parameter defined by [RFC7515] and [RFC7516]
is used by JWM applications to declare the media type
[IANA.MediaTypes] of this complete JWM. This is intended for use by
the JWM application when values that are not JWMs could also be
present in an application data structure that can contain a JWM
object; the application can use this value to disambiguate among the
different kinds of objects that might be present. It will typically
not be used by applications when it is already known that the object
is a JWM. This parameter is ignored by JWM implementations; any
processing of this parameter is performed by the JWM application. If
present, it is RECOMMENDED that its value be "JWM" to indicate that
this object is a JWM. While media type names are not case sensitive,
it is RECOMMENDED that "JWM" always be spelled using uppercase
characters for compatibility with legacy implementations. Use of
this Header Parameter is OPTIONAL.
Looker Expires December 8, 2021 [Page 12]
Internet-Draft jwm June 2021
4.2. "cty" (Content Type) Header Parameter
The "cty" (content type) Header Parameter defined by [RFC7515] and
[RFC7516] is used by this specification to convey structural
information about the JWM.
In the normal case in which nested signing or encryption operations
are not employed, the use of this Header Parameter is NOT
RECOMMENDED. In the case that nested signing or encryption is
employed, this Header Parameter MUST be present; in this case, the
value MUST be "JWM", to indicate that a Nested JWM is carried in this
JWM. While media type names are not case sensitive, it is
RECOMMENDED that "JWM" always be spelled using uppercase characters
for compatibility with legacy implementations.
4.3. Replicating Attributes as Header Parameters
In some applications using encrypted JWMs, it is useful to have an
unencrypted representation of some attributes. This might be used,
for instance, in application processing rules to determine whether
and how to process the JWM before it is decrypted.
This specification allows Attributes present in the JWM Attributes
Set to be replicated as JOSE Header Parameters in a JWM that is a
JWE, as needed by the application. If such replicated attributes are
present, the application receiving them SHOULD verify that their
values are identical, unless the application defines other specific
processing rules for these attributes. It is the responsibility of
the application to ensure that only attributes that are safe to be
transmitted in an unencrypted manner are replicated as JOSE Header
Parameter values in the JWM.
5. Creating and Validating JWMs
5.1. Creating a JWM
To create a JWM, the following steps are performed. The order of the
steps is not significant in cases where there are no dependencies
between the inputs and outputs of the steps.
1. Create a JWM Attribute Set containing the desired attributes.
Note that whitespace is explicitly allowed in the representation
and no canonicalization need be performed before encoding.
2. Let the Message be the octets of the UTF-8 representation of the
JWM Attributes Set.
Looker Expires December 8, 2021 [Page 13]
Internet-Draft jwm June 2021
3. Create a JOSE Header containing the desired set of Header
Parameters. The JWM MUST conform to either the JWS [RFC7515] or
JWE [RFC7516] specification. Note that whitespace is explicitly
allowed in the representation and no canonicalization need be
performed before encoding.
4. Depending upon whether the JWM is a JWS or JWE, there are two
cases:
o If the JWM is a JWS, create a JWS using the JWM Attribute Set as
the JWS Payload; all steps specified in JWS [RFC7515] for creating
a JWS MUST be followed. If the resulting JWS features only a
single signature, it can optionally be formated into JWS compact
serialization format allowing the message to be URL safe. If
however, the resulting JWS features multiple signatures and URL
safety for the message is still required, the entire JWS in JSON
serialization format MUST be encoded to base64url format.
Otherwise the output format for the JWS MUST be JWS JSON
serialization format.
o Else, if the JWM is a JWE, create a JWE using the JWM Attribute
Set as the plaintext for the JWE; all steps specified in JWE
[RFC7516] for creating a JWE MUST be followed. If the resulting
JWE features only a single recipient, it can optionally be
formated into JWE compact serialization format allowing the
message to be URL safe. If however, the resulting JWE features
multiple recipients and URL safety for the message is still
required, the entire JWE in JSON serialization format MUST be
encoded to base64url format. Otherwise the output format for the
JWE MUST be General JWE JSON serialization format. The Flattened
JWE JSON serialization format is not supported.
1. If a Nested JWM is desired, let the Message be the JWS or JWE,
and return to Step 3, using a "cty" (content type) value of "JWM"
in the new JOSE Header created in that step.
2. Otherwise, let the resulting JWM be the JWS or JWE.
5.2. Validating a JWM
When validating a JWM, the following steps are performed. The order
of the steps is not significant in cases where there are no
dependencies between the inputs and outputs of the steps. If any of
the listed steps fail, then the JWM MUST be rejected; that is,
treated by the application as an invalid input.
1. If the JWM is a valid base64url string containing at least one
period ('.') character.
Looker Expires December 8, 2021 [Page 14]
Internet-Draft jwm June 2021
1. Let the Encoded JOSE Header be the portion of the JWM before
the first period ('.') character.
2. Base64url decode the Encoded JOSE Header following the
restriction that no line breaks, whitespace, or other
additional characters have been used.
3. Verify that the resulting octet sequence is a UTF-8-encoded
representation of a completely valid JSON object conforming
to RFC 7159 [RFC7159]; let the JOSE Header be this JSON
object.
2. Else, if the JWM is a valid base64url string containing no period
('.') characters.
1. Let the Encoded JWS or JWE be the entire base64url string.
2. Base64url decode the Encoded JWS or JWE following the
restriction that no line breaks, whitespace, or other
additional characters have been used.
3. Verify that the resulting octet sequence is a UTF-8-encoded
representation of a completely valid JSON object conforming
to RFC 7159 [RFC7159]; let the JWS or JWE be this JSON
object.
3. Else, if the JWM is a UTF-8-encoded representation of a
completely valid JSON object conforming to RFC 7159 [RFC7159];
let the JWS or JWE be this JSON object.
4. Verify that the resulting JOSE Header includes only parameters
and values whose syntax and semantics are both understood and
supported or that are specified as being ignored when not
understood.
5. Determine whether the JWM is a JWS or a JWE using any of the
methods described in Section 9 of [RFC7516].
6. Depending upon whether the JWM is a JWS or JWE, there are two
cases:
* If the JWM is a JWS, follow the steps specified in [RFC7515]
for validating a JWS. Let the Message be the result of
base64url decoding the JWS Payload.
* Else, if the JWM is a JWE, follow the steps specified in
[RFC7516] for validating a JWE. Let the Message be the
resulting plaintext.
Looker Expires December 8, 2021 [Page 15]
Internet-Draft jwm June 2021
7. If the JOSE Header contains a "cty" (content type) value of
"JWM", then the Message is a JWM that was the subject of nested
signing or encryption operations. In this case, return to Step
1, using the Message as the JWM.
8. Otherwise, base64url decode the Message following the restriction
that no line breaks, whitespace, or other additional characters
have been used.
9. Verify that the resulting octet sequence is a UTF-8-encoded
representation of a completely valid JSON object conforming to
RFC 7159 [RFC7159]; let the JWM Attributes Set be this JSON
object.
Finally, note that it is an application decision which algorithms may
be used in a given context. Even if a JWM can be successfully
validated, unless the algorithms used in the JWM are acceptable to
the application, it SHOULD reject the JWM.
5.3. String Comparison Rules
These rules are identical to those applied to JWTs outlined in
Section 7.3 of [RFC7519].
6. Implementation Requirements
This section defines which algorithms and features of this
specification are mandatory to implement. Applications using this
specification can impose additional requirements upon implementations
that they use.
Support for digitally signed JWMs using JWS is REQUIRED. Of the
signature and MAC algorithms specified in JSON Web Algorithms
[RFC7518], only ECDSA using the P-256 curve and SHA-256 hash
algorithm ("ES256") MUST be implemented by conforming JWM
implementations. It is RECOMMENDED that implementations also support
ECDSA using the P-521 curve and the SHA-512 hash algorithm ("ES512")
and EdDSA using the Ed25519 curve and SHA-512 hash algorithm.
Support for other algorithms and key sizes is OPTIONAL.
Support for encrypted JWMs using JWE is also REQUIRED. Of the
encryption algorithms specified in [RFC7518], using Elliptic Curve
Diffie-Hellman Ephemeral Static (ECDH-ES) with the P-256 curve to
agree upon a key and using this key to to perform key wrapping of a
Content Encryption Key ("ECDH-ES+A128KW" and "ECDH-ES+A256KW") MUST
be supported. With regards to content encryption, AES in Galois/
Counter Mode (GCM) with 128-bit and 256-bit keys ("A128GCM" and
"A256GCM") MUST also be supported. It is RECOMMENDED that
Looker Expires December 8, 2021 [Page 16]
Internet-Draft jwm June 2021
implementations also support ECDH-ES and key wrapping variants using
the X25519 curve also.
Usage of the "none" algorithm identifier in a JWM as defined in the
JOSE Web Algorithms section 3.6 [RFC7518] MUST be considered invalid.
Support for Nested JWMs is also REQUIRED.
7. IANA Considerations
7.1. Registration Template
7.1.1. Attribute Name:
The name requested (e.g., "type"). Because a core goal of this
specification is for the resulting representations to be compact, it
is RECOMMENDED that the name be short - that is, not to exceed 15
characters without a compelling reason to do so. This name is case
sensitive. Names may not match other registered names in a case-
insensitive manner unless the Designated Experts state that there is
a compelling reason to allow an exception.
7.1.2. Attribute Description
Brief description of the attribute (e.g., "Message Type").
7.1.3. Change Controller
For Standards Track RFCs, list the "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address, email
address, home page URI) may also be included.
7.1.4. Specification Document(s)
Reference to the document or documents that specify the parameter,
preferably including URIs that can be used to retrieve copies of the
documents. An indication of the relevant sections may also be
included but is not required.
7.1.5. Initial Registry Contents
o Attribute Name: "id"
o Attribute Description: Message ID
o Change Controller:
o Specification Document(s):
o Attribute Name: "type"
o Attribute Description: Message Type
Looker Expires December 8, 2021 [Page 17]
Internet-Draft jwm June 2021
o Change Controller:
o Specification Document(s):
o Attribute Name: "body"
o Attribute Description: Message Body
o Change Controller:
o Specification Document(s):
o Attribute Name: "to"
o Attribute Description: Message Recipients
o Change Controller:
o Specification Document(s):
o Attribute Name: "from"
o Attribute Description: Message From
o Change Controller:
o Specification Document(s):
o Attribute Name: "created_time"
o Attribute Description: Message Created Time
o Change Controller:
o Specification Document(s):
o Attribute Name: "expires_time"
o Attribute Description: Message Expiry Time
o Change Controller:
o Specification Document(s):
o Attribute Name: "reply_url"
o Attribute Description: Message Reply URL
o Change Controller:
o Specification Document(s):
o Attribute Name: "reply_to"
o Attribute Description: Message Reply To
o Change Controller:
o Specification Document(s):
8. Media Type Registration
8.1. Registry Contents
9. Security Considerations