-
Notifications
You must be signed in to change notification settings - Fork 0
/
indieauth-ticketing.txt
1904 lines (1196 loc) · 72.9 KB
/
indieauth-ticketing.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
indieweb.org D. Somers
3 April 2022
IndieAuth Ticketing DRAFT 0.1
Abstract
This document defines new protocols for use with IndieAuth(an
extension to OAuth 2.0) by defining how to request ("please push"),
deposit ("push"), and grant ("exchange for a bearer token") tickets
between two parties. It further defines an new protocol to
orchestrate the aforementioned to allow a third-party to act on-
behalf-of the first party at the second-party. Use cases are
provided.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. There is a feed that you can subscribe to . . . . . . 3
1.1.2. Reading private content on-behalf-of . . . . . . . . 5
1.1.3. Reading private feeds . . . . . . . . . . . . . . . . 8
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
1.4. Example Formatting . . . . . . . . . . . . . . . . . . . 9
2. Ticketing . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Who implements what . . . . . . . . . . . . . . . . . . . 10
2.2. An archetypal implementation . . . . . . . . . . . . . . 10
2.3. Target endpoint discovery . . . . . . . . . . . . . . . . 11
2.3.1. Discover Subject AS Metadata . . . . . . . . . . . . 11
2.3.2. Discover Audience AS Metadata . . . . . . . . . . . . 12
2.4. Request . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Processing . . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Successful Response . . . . . . . . . . . . . . . . . . . 13
2.7. Error Response . . . . . . . . . . . . . . . . . . . . . 13
2.8. The Ticket . . . . . . . . . . . . . . . . . . . . . . . 13
2.9. Authorization Server Metadata . . . . . . . . . . . . . . 14
2.10. Ticket Introspection . . . . . . . . . . . . . . . . . . 14
3. Ticket Wanted Flow . . . . . . . . . . . . . . . . . . . . . 15
3.1. Target Endpoint Discovery . . . . . . . . . . . . . . . . 16
3.2. Request . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Successful Response . . . . . . . . . . . . . . . . . . . 17
3.5. Error Response . . . . . . . . . . . . . . . . . . . . . 18
4. Ticket Deposit Flow . . . . . . . . . . . . . . . . . . . . . 18
4.1. Target Discovery . . . . . . . . . . . . . . . . . . . . 19
4.2. Request . . . . . . . . . . . . . . . . . . . . . . . . . 19
Somers Experimental [Page 1]
Ticketing April 2022
4.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 20
4.4. Successful Response . . . . . . . . . . . . . . . . . . . 21
4.5. Error Response . . . . . . . . . . . . . . . . . . . . . 21
5. Ticket Grant Flow . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Request . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 23
5.4. Successful Response . . . . . . . . . . . . . . . . . . . 23
5.5. Error Response . . . . . . . . . . . . . . . . . . . . . 23
6. Authorization Code On-Behalf-Of Grant Flow . . . . . . . . . 23
6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Request . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 26
6.4. Successful Response . . . . . . . . . . . . . . . . . . . 27
6.5. Error Response . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
9. IndieWeb Considerations . . . . . . . . . . . . . . . . . . . 29
9.1. "OAuth Parameters" Registry . . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Why use a Code Verifier? . . . . . . . . . . . . . . 33
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 33
Appendix C. Document History . . . . . . . . . . . . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
This document defines new protocols for use with [IndieAuth] (an
extension to OAuth 2.0 [RFC6749]) by defining flows between
participants that directly or indirectly use tickets as an instrument
to facilitate the following activities:
want ticket
Requesting that ticket to be sent to somebody's (the requestor's)
authorization server.
deposit ticket
Depositing (pushing) a ticket to an authorization server.
exchange ticket for authorization code
Taking a deposited ticket and exchanging it with its issuer for an
access code (Bearer token).
Somers Experimental [Page 2]
Ticketing April 2022
third-party wants an authorization code
Choreography across three parties to provide an authorization code
(Bearer token) to a third-party to use at a second-party by
impersonating the first-party.
These activities are implemented respectively by the following flows:
* Ticket Wanted flow as specified in Section 3.
* Ticket Deposit flow as specified in Section 4.
* Ticket Grant flow as specified in Section 5.
* Authorization Code On-Behalf-Of grant flow as specified in
Section 6.
1.1. Use Cases
The participants are:
* The first-party, formally the subject, also known as Alice, who
authenticates herself to services using an IndieAuth authorization
server as specified in Section 5.3.2 of [IndieAuth].
* The second-party, formally the resource server, also known as Bob,
is a publisher who makes protected resources available to
authorized parties using IndieAuth for identification and Bearer
Token Usage [RFC6750].
* The third-party, formally the actor, also known as Carol, who can
perform different roles for the benefit of the Alice (first-party)
at the Bob (the second-party) who in this context is formally the
audience(for Carol's performance).
1.1.1. There is a feed that you can subscribe to
In this case, Carol is playing the role of Felicity who is a feed
reader.
Bob makes available feed-oriented resources which can be used by
Alice to read resources recently published on his site. Bob tells
Alice's authorization server the location of the feed, which then
tells Felicity to subscribe to it.
This to be achieved when:
1. The resource server (Bob) implements ticket deposit flow.
Somers Experimental [Page 3]
Ticketing April 2022
2. The subject's (Alice) authorization server implements ticket
deposit flow and optionally ticket grant flow.
3. The resource server (Bob) uses ticket deposit flow to inform the
subject (Alice) that there is a feed she might want to subscribe
to. When Bob informs Alice of the location of the feed is at the
discretion of the resource server.
4. If the subject's (Alice) authorization server implements ticket
grant flow it then performs it. This serves the important
purpose of confirming that the ticket originated from Bob (the
resource server) and not a nefarious actor. The secondary
purpose is to have a Bearer token that can be passed to a feed
reader to access private resources.
5. The subject's (Alice) authorization server requests the reader
(Felicity) to subscribe to Bob's feed using an appropriate
mechanism; how this is achieved is dependent on the authorization
server and the feed reader but would typically involve a WebSub
subscription request as specified in Section 5.1 of
[W3C.REC-websub-20180123].
Somers Experimental [Page 4]
Ticketing April 2022
┌───────────────────────┐ ┌───────────────────────┐ ┌───────────┐
│ "Alice" │ │ "Bob" │ │"Felicity" │
├───────────────────────┤ ├───────────────────────┤ ├───────────┤
│ subject │ │ resource server │ │ actor │
├───────────┬───────────┤ ├───────────┬───────────┤ ├───────────┤
│ profile │subject as │ │ metadata │audience as│ │ websubhub │
└───────────┴───────────┘ └───────────┴─────┬─────┘ └───────────┘
│ │ │ │ │
│ │ │discover │ │
│◀──────────┼────────────────┼─subject─ ┌┴┐ │
│ │ │metadata │D│ │
│ │ │ │ │ │
│ ┌┴┐◁───ticket─────┼──────────└┬┘ │
│ │D│ │ │ │
│ │ │ discover │ │ │
│ │┌┴┐──audience───▶│ │ │
│ ││ │ metadate │ │ │
│ ││ │ │ │ │
│ ││X│ ticket │ │ │
│ ││ │──grant───────┼─────────▷┌┴┐ │
│ ││ │ │ │X│ │
│ │└┬┘◀ ─ ac─ ─ ─ ─ ┼ ─ ─ ─ ─ ─└┬┘ │
│ │ │ │ │ subscribe │
│ └┬┘───────────────┼───────────┼──────to feed──▶│
▼ ▼ ▼ ▼ ▼
D: ticket deposit flow
X: ticket grant flow (exchange ticket for token)
S: subscribe to feed
Figure 1: Use case of ticketing for feed notification and
subscription
1.1.2. Reading private content on-behalf-of
In this case, Carol is playing the role of Rachel, an impersonator,
who only does so with a permissive and in a non-malicious manner.
Alice wants to have Rachel read private resources that Bob makes
available to her. Bob does not know Rachel but Rachel can
impersonate Alice so she can read things on-behalf-of Alice.
To achieve this the goal is the acquisition of an authorization code
(Bearer token) across the security boundary of three parties
(subject, audience, and actor/impersonator).
Somers Experimental [Page 5]
Ticketing April 2022
It should be stressed that this should happen without any action
needed by the subject (it is "hands-off"), who also retaining agency
over obtaining and passing token-based authorization codes to their
chosen actor and that no preexisting relationship is needed between
audience and actor.
This to be achieved when:
1. The subject's authorization server implements ticket deposit
flow, token grant flow, and authorization code on-behalf-of grant
flow.
2. The audience's authorization server implements ticket wanted
flow, ticket deposit flow, and ticket grant flow.
3. The actor implements authorization code on-behalf-of grant flow.
4. The actor attempts to read a protected resource from the
audience, receives a 403 Unauthorized response, then performs
authorization code on-behalf-of grant flow with the subject's
authorization server to obtain a Bearer token that can be used to
access the protected resource.
Somers Experimental [Page 6]
Ticketing April 2022
┌───────────────────────┐ ┌───────────────────────┐ ┌───────────┐
│ "Alice" │ │ "Bob" │ │ "Rachel" │
├───────────────────────┤ ├───────────────────────┤ ├───────────┤
│ subject │ │ resource server │ │ actor │
├───────────┬───────────┤ ├───────────┬───────────┤ ├───────────┤
│ profile │subject as │ │ metadata │audience as│ │ reader │
└───────────┴───────────┘ └───────────┴───────────┘ └───────────┘
│ │ │ │ │
│ │ │ │ discover │
│◀──────────┼────────────────┼───────────┼──────subject──┌┴┐
│ │ │ │ metadata │O│
│ │ │ │ │ │
│ ┌┴┐◀──────────────┼───────────┼───────ac-obo──│ │
│ │O│ discover │ │ │ │
│ │┌┴┐──audience───▶│ │ │ │
│ ││W│ metadata │ │ │ │
│ ││ │ │ │ │ │
│ ││ ├──want ticket─┼─────────▶┌┴┐ │ │
│ ││ │ │ │W│ │ │
│ │└┬┘◀─ ack ─ ─ ─ ─│─ ─ ─ ─ ─ │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │discover │ │ │ │
│◀─────────┤ ├───────────────┼─subject─┌┴┐│ │ │
│ │ │ │metadata │D││ │ │
│ │ │ │ │ ││ │ │
│ │┌┴┐◁──ticket─────┼─────────└┬┘│ │ │
│ ││D│ │ │ │ │ │
│ │└┬┘ discover │ │ │ │ │
│ │┌┴┐──audience───▶│ │ │ │ │
│ ││ │ metadate │ │ │ │ │
│ ││ │ │ │ │ │ │
│ ││X│ ticket │ │ │ │ │
│ ││ │──grant───────┼────────▷┌┴┐│ │ │
│ ││ │ │ │X││ │ │
│ │└┬┘ ◀ ─ac ─ ─ ─ ─│─ ─ ─ ─ ─└┬┘│ │ │
│ │ │ │ └┬┘ │ │
│ └┬┘─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ac─ ▶└┬┘
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
W: want ticket flow
D: ticket deposit flow
X: ticket grant flow (exchange ticket for token)
O: code obo grant flow (get token via ticketing between participants)
Figure 2: Use case of ticketing for acquiring an authorization
code for use by a third-party
Somers Experimental [Page 7]
Ticketing April 2022
1.1.3. Reading private feeds
In this case, Carol performs a dual role (she is Felicity-Rachel):
the ability to not only read feeds (the Felicity role), which
themselves may be a protect resource, but also any protected
resources in the feed, by impersonating Alice as necessary (the
Rachel role).
1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.3. Terminology
This specification uses the terms "as metadata" and "user profile
URL" defined by [IndieAuth], the terms "access token", "authorization
server", "authorization endpoint", "authorization request", "client",
"resource server", and "token endpoint" defined by The OAuth 2.0
Authorization Framework [RFC6749], the terms "delegation" and
"security token service" defined by [RFC8693] the term "bearer token"
defined by [RFC6750]
This specification defines the following terms:
Actor
A URL that represents the identity of the acting party.
Typically, this will be the party (the third-party) that is
authorized to use a token obtained by and to act on-behalf-of the
subject at another party (the second-party).
Audience
A URL that represents the second-party in a multi-participant
protocol.
Role
The activity (a scope) that an actor will perform on-behalf-of a
subject.
Subject
A person, the first-party in a multi-participant protocol.
Subject Identity
The identity of the subject as a URI, nominally an IndieAuth user
profile URL.
Somers Experimental [Page 8]
Ticketing April 2022
Ticket
A ticket is an opaque string, not intended to have any meaning to
clients using it.
Ticket Endpoint
The IndieAuth/OAuth 2.0 endpoint through which ticket deposit
operation is accomplished.
Ticket Wanted Endpoint
The IndieAuth/OAuth 2.0 endpoint through which ticket wanted
operation is accomplished.
Ticketing
The act of acquiring or using tickets as a utility to allow
information to be exchanged between two or more parties through
use of the network protocol defined in this document.
1.4. Example Formatting
Where examples of protocol messages are given, the payload has been
formatted for presentation and is not a true representation of what
is the wire data: for form-urlencoded payloads URL-encoding has not
been done and additional white-space and line-breaks are shown
between key-value pairs to aid readability; similarly for JSON
payloads.
2. Ticketing
This specification defines new protocol flows around the use of
tickets between participants in the IndieAuth universe:
Ticket Wanted
This is where somebody requests an authorization server to send a
ticket to the authorization server for a subject.
Ticket Deposit
This is where somebody issues a ticket to the authorization server
for a subject to indicate that it can be exchanged at the
authorization server for the audience to obtain an access code
(Bearer token) or to notify them simply of the presence of a feed
at the resource server that they may be interested in subscribing
to.
Ticket Grant
This is where a ticket is redeemed at the authorization server for
audience to grant a token assigned to the subject.
Somers Experimental [Page 9]
Ticketing April 2022
Authorization Code On-Behalf-Of (ac-obo) Grant
This is where an actor requests that the authorization server for
the subject for a bearer token to use at the audience on their
behalf. The authorization server validates that the request is
from the actor and then orchestrates wanted ticket flow with the
audience, waits for it to send a ticket using ticket deposit flow,
then exchanges the ticket with the authorization server for the
audience for a token, and finally returns the token to the caller.
2.1. Who implements what
The following table summarizes which participant/system is
responsible for implementing which side of each ticketing flow.
+====================+=============+=============+
| ticketing flow | client | server |
+====================+=============+=============+
| (W) ticket wanted | subject as | audience as |
+--------------------+-------------+-------------+
| (D) ticket deposit | audience as | subject as |
+--------------------+-------------+-------------+
| (X) ticket grant | subject as | audience as |
+--------------------+-------------+-------------+
| (O) ac-obo grant | actor | subject as |
+--------------------+-------------+-------------+
Table 1
2.2. An archetypal implementation
Each protocol flow follows an archetypal pattern, as illustrated in
Figure 3, between an initiator (the client-side of an HTTP request)
and a target (the sever-side of an HTTP response):
Client: Discovery (of the target endpoint)
The client discovers the target endpoint to where a request is to
be made under the doctrine of "distrust and verify" per Section 7.
Client: Make the request
The client makes a request to the target endpoint as an HTTP
"POST".
Server: Receive the request and work it
The endpoint receives the request, validates the parameters,
ensures that the request is valid, meets all policy and other
criteria of the authorization server, processes the request to
build response parameters, and returns the response.
Somers Experimental [Page 10]
Ticketing April 2022
Client: Receive the response and work it
The response is either a successful response or an error response.
┌─────────────┐ ┌─────────────┐
│ Initiator │ │ Target │
├─────────────┤ ├─────────────┤
│ Client │ │ Server │
└─────────────┘ └─────────────┘
│ │
┌┴┐──┐ │
│ │ │ Discover │
│ │ │ Target │
│ │ │ Endpoint │
│ │◀─┘ │
│ │ POST to target │
│ │────parameters are──────────────▶┌┴┐──┐validate parameters
│ │ x-www-form-urlencoded │ │ │meets criteria?
│ │ │ │◀─┘meets policy?
│ │ │ │
┌ALT─ ┤ ├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤ ├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
│ │ │ │──┐ work request │
│ │ │◀ ─ ─ ─ ─ ─ Successful Response ─│ │◀─┘ build response
─ ─ ─│ │─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│ │─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│ │ │ │ │
│ │◀─ ─ ─ ─ ─ ─ ─ ─ Error Response─ ┤ │ │
└ ─ ─ ┤ ├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┴┬┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
│ │──┐ │
│ │◀─┘work response │
└┬┘ │
▼ ▼
Figure 3: Archetypal flow
2.3. Target endpoint discovery
The client needs to discover the endpoint where the request needs to
be made.
2.3.1. Discover Subject AS Metadata
For "subject":
A subject is identified by a user profile URL which is their
canonical homepage in the world wide web at a domain which is unique
to them and accessible by either the http or https scheme as
specified in section 3.1 of [IndieAuth].
Somers Experimental [Page 11]
Ticketing April 2022
It is RECOMMENDED that a profile URL with a http scheme be considered
unacceptable due toSection 7.
The client undertakes discovery as specified in Section 4.1 of
[IndieAuth] against the user profile URL.
2.3.2. Discover Audience AS Metadata
For "audience":
Do discovery for "audience" as detailed in Section 4.1 of [IndieAuth]
2.4. Request
The client makes a request to the target endpoint using the HTTP
"POST" method. Parameters are included in the HTTP request entity-
body using the "application/x-www-form-urlencoded" format with a
character encoding of UTF-8 as described in Appendix B of [RFC6749].
The parameters are detailed for each flow in this specification.
2.5. Processing
When an server receives a request it performs the following steps:
1. Validate the parameters to ensure that all mandatory one are
present.
2. Ensure that the parameter values are semantically correct, for
example:
* The type matches that expected.
* If a URL is expected that the value can be parsed as a URL and
is normalized as required.
3. Ensures that it meets all policy and other criteria specific to
the implementation.
4. Works the request and construct the result parameters.
Somers Experimental [Page 12]
Ticketing April 2022
2.6. Successful Response
A successful response is constructed by adding the result parameters
to the entity-body of the HTTP response using the "application/json"
media type, as specified by [RFC8259], and an HTTP 202 status code or
other applicable code. The result parameters are serialized into a
JavaScript Object Notation (JSON) structure by adding each parameter
at the top level. Parameter names and string values are included as
JSON strings. Numerical values are included as JSON numbers. The
order of parameters does not matter and can vary.
The result parameters are detailed for each flow in this
specification.
2.7. Error Response
If the request is not valid or is unacceptable based on policy or
there is a problem when processing the request the authorization
server MUST construct an error response, as specified in Section 5.2
of [RFC6749]. The value of the "error" parameter MUST be the
"invalid_request" error code or other values as detailed for each
flow in this specification.
The authorization server MAY include additional information regarding
the reasons for the error using the "error_description" as discussed
in Section 5.2 of [RFC6749].
Other HTTP status codes may also be used as appropriate, for example:
405
If the request did not use the "POST" method, the authorization
server responds with an HTTP 405 (Method Not Allowed) status code.
413
If the request size was beyond the upper bound that the
authorization server allows, the authorization server responds
with an HTTP 413 (Payload Too Large) status code.
429
If the number of requests from a client during a particular time
period exceeds the number the authorization server allows, the
authorization server responds with an HTTP 429 (Too Many Requests)
status code.
2.8. The Ticket
The ticket is an opaque string. It MUST be at lest 16 characters in
length and no more than 512 characters.
Somers Experimental [Page 13]
Ticketing April 2022
When an authorization server generates a ticket it is HIGHLY
RECOMMENDED that it is a version 4 UUID generated as specified in
Section 4.4 of [RFC4122].
If an authorization server wants to generate a structured ticket it
MUST not be a JWT due to Section 7 and its content MUST respect
Section 8.
2.9. Authorization Server Metadata
The following authorization server metadata [RFC8414] parameters are
introduced to signal an authorization server's capability and policy
with respect to which aspects of ticketing it supports.
ticket_wanted_endpoint
If this endpoint is declared this indicates that the authorization
server implements the server-side of ticket wanted flow.
ticket_endpoint
If this endpoint is declared this indicates that the authorization
server explicitly implements the server-side of ticket deposit
flow. A client MAY use the "token_endpoint" as a fall-back target
as an implicit (and not guaranteed) signal and target endpoint.
grant_types_supported
If the authorization server supports authorization code on-behalf-
of grant flow this MUST include
"urn:indieweb.org:params:oauth:grant-type:on_behalf_of"; if it
supports ticket grant flow it MUST include
"urn:indieweb.org:params:oauth:grant-type:ticket".
2.10. Ticket Introspection
If an authorization server implements OAuth Introspection [RFC7662]
it MAY consider a ticket to be like a token and allow it to be
introspected with "token_type__hint=ticket" as per Section 1 of
[RFC7662].
Example token introspection request against a ticket:
POST /as/token_introspect HTTP/1.1
Host: https://bob.example.com
Content-type: application/x-www-form-urlencoded; charset=utf-8
Accept: application/json
token=TICKET1234
&token_type_hint=ticket
Somers Experimental [Page 14]
Ticketing April 2022
Example token introspection response against a ticket:
HTTP 1.1
Content-Type: application/json
Cache: no-cache, no-store
{
"active" : false,
"scope": "read",
"client_id": "https://bob.example"
"username": "rachel obo alice",
"token_type": "ticket",
"iat": "1648710000",
"exp": "1648992070",
"sub": "https://alice.example/",
"aud": "https://bob.example/".
"iss": "https://bob.example/as"
}
3. Ticket Wanted Flow
Somers Experimental [Page 15]
Ticketing April 2022
┌──────────────────────────────────────────────────────────────────────┐
│ ticket wanted flow - (subject, audience):nil │
└──────────────────────────────────────────────────────────────────────┘
┌───────────────────────────────┐
│ audience │
├───────────────────────────────┤
│ authorization server │
┌───────────────┐ ├───────────────┬───────────────┤
│ client │ │ /metadata │/ticket_wanted │
└───────────────┘ └───────────────┴───────────────┘
│ │ │
┌┴┐ │ │
│ │read audience metadata │ │
│ │want ticket_wanted_endpoint │ │
│ │────────────────────────────▶│ │
│ │send request: │ │
│ │send a ticket to "subject" │ │
│ │─────────────────────────────┼─────────────▶┌┴┐
│ │successful response: │ │ │
│ │request received │ │ │
│ │◀─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┼ ─ ─ ─ ─ ─ ─ ─│ │
└┬┘ │ └┬┘
┌OPT─ ─ ┼ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
│ │ ┌─REF───┴───────┐ │
│ │ │ │ticket deposit │
│ │ └───────┬───────┘ │
└ ─ ─ ─ ┼ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
▼ ▼ ▼
Figure 4: Sequence diagram for ticket wanted flow
3.1. Target Endpoint Discovery
1. Obtain the metadata for the authorization server for the subject
as detailed in Section 2.3.2.
2. Target endpoint is the "ticket_wanted_endpoint" property in the
metadata; if the property does not exist or has an empty value
fallback to the "token_endpoint" property.
The target endpoint MUST use the "https" scheme per Section 7.
3.2. Request
The client makes a request as specified in Section 2.4 to the target
endpoint with the following parameters:
Somers Experimental [Page 16]
Ticketing April 2022
action
REQUIRED. This MUST be "ticket". NOTE: if the ticket is received
on a "token_endpoint" this key-value combination can be used to
easily identify the request as one for ticket wanted.
subject
REQUIRED. The user profile URL of the subject.
Example ticket wanted request:
POST /as/ticket_wanted HTTP/1.1
Host: https://bob.example.com
Content-type: application/x-www-form-urlencoded; charset=utf-8
Accept: application/json
action=ticket
&subject=https://alice.example.com/
3.3. Processing
The request is processed as specified in Section 2.5 and the specific
work to be performed for ticket wanted flow is:
1. To decide to act on the wanted request or not.
2. If it decides to act it does Ticket Deposit Flow for the subject
in the request.
3.4. Successful Response
The response will be as specified in Section 2.6 and there are no
response parameters so the body of the response is at the discretion
of the authorization server.
It is RECOMMEND that http content negotiation as specified in section
5.3 of [RFC7231] is undertaken and the server responds to following
media types accordingly (defaulting to "application/json"):
application+json
An object with a single key of "subject" and value of the subject
in the request (which may be different due to normalization or
canonicalization).
Example ticket wanted response with content-negotiated JSON body:
Somers Experimental [Page 17]
Ticketing April 2022
HTTP 1.1
Content-Type: application/json
Cache: no-cache, no-store
{
"subject" : "https://alice.example.com/"
}
text/plain:
"Ticket Wanted Request Received for <subject>"
Example ticket wanted response with content negotiated text/plain
body:
HTTP 1.1
Content-Type: text/plain
Cache: no-cache, no-store
Received Ticket Wanted Request for https://alice.example.com/
3.5. Error Response
If an error response is warranted it MUST be as per Section 2.7.
An error response MUST only be returned if there is a problem with
the request parameters per se (for example missing or malformed).
The server MUST NOT return an error response if the subject is not
known because that would leak that the publisher does not have a
relationship with the subject, and conversely that it does (which
would be an issue if the request did not originate from the subject
but from a malicious client).
4. Ticket Deposit Flow